Introduction

The following document is a Visual WebGui security concept summary. Exploring the Visual WebGui unique pipeline protocol will shade light on the reasons why Visual WebGui is secured by design.

Abstract

Visual WebGui is a server based architecture executing the application business logics on the server and projecting the UI to the client (as describes in figure 1 below). Utilizing IIS and ASP.NET session, a metadata of the relevant UI objects tree is kept on the server.

Figure 1

A highly optimized protocol by Visual WebGui is responsible to send events to the server and instructions to the client.

Empty Client: the client is using a small, plain and static JavaScript kernel to communicate with the server and render the UI.
Security concept highlight: Visual WebGui client script cannot control the server behavior by definition!

Architecture

Client/Server state balance protocol scenario (as further described in figure 2):

Flow Step 1: The first time the client approaches the server it downloads a small amount of kernel code which is constructed of:

a.    JavaScript- responsible for the client behaviors and communication with the server.
b.    XSLT - responsible for the UI layout including the HTML rendering of the entire set of controls.
c.    CSS  - responsible for UI styling

The kernel is sent in a compressed mode and weights about 200kb. Furthermore, it is cached on the client and on the server statically and will never change from this point on.

Security aspects: no code generation at runtime, the kernel is well known and static.

Flow Step 2: The client renders the basic HTML to the screen and from that point on it acts like a smart AJAX client which consumes a UI service from the server only.
Security aspects: only UI essential data is sent to the client, no applicative or sensitive data.

Flow Step 3: Highly optimized events are sent tothe server whenever a client performs a set of action that should result in executing server code. Events metadata are constructed of UI object Id and the action performed.

Security aspects: events are reflecting UI behavior and never applicative logic which is
uniquely handled by the server.

Flow Step 4: The server executes the event handler and sends back highly optimized UI instructions to the client. The instructions are reflecting the deltas of changes between the last balanced state and the new state.

Security aspects: server instructions are reflecting UI changes and presented data changes, however, will never contain hidden applicative logic or data which is uniquely kept and handled by the server.

Flow Step 5: The client accepts the UI changes instructions and re-renders the parts which have changed according to the last server execution of logics.
Security aspects: the client is responsible to render UI and that is the only aspect which is affected by application logics.

Figure 2

Process conclusions:

1.    Client security-holes which are created by either applicative or sensitive data which is kept on the client or even simply sent to the client are impossible by design (as described in figures 3 and 4).

Standard web applications:

Figure 3

With Visual WebGui:

Figure 4

2.    Client scripting cannot control the server behavior as by design, simply because the responsibilities of the client are limited to:

1. Render client UI.
2. Send client events to the server (yet the server has the freedom to decide which are valid events and parameters according to the current user's  credentials)
3. Accept server instructions and re-render UI parts

3.    Visual WebGui does not imply to present an ultimate solution for all the security issues of the world, however, through the Visual WebGui communication protocol it will be impossible to hack a web application. This means that assuming https and/or any other incredible secured communication solutions (i.e. WCF) are used to secure the HTTP communication and that the OS and DB are safe on the server side, Visual WebGui application is thoroughly safe.