White Paper: Visual WebGui 'Empty Client' Security Concept

Introduction
The following document is a Visual WebGui security concept summary that explores the Visual WebGui unique pipeline protocol and will shade light on the reasons why Visual WebGui is secure 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.

The result: no data / logic reside on the client-side, which typical AJAX-enabled websites are vulnerable to.
Having data/logic stored on the client-side creates vulnerabilities in other software development frameworks because hackers can alter the logic / data within the client and request information from the server that they should not have access to.

Figure 1

A highly optimized protocol by Visual WebGui is responsible to send events to the server and instructions to the client. Visual WebGui uses the ”Empty Client" architecture - every action the client wishes to take is first authorized by the server before being performed. Not only does this significantly increase Security, but this design also allows events to be raised on the server for every client action.

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:

• JavaScript– responsible for the client behaviors and communication with the server.
• XSLT – responsible for the UI layout including the HTML rendering of the entire set of controls.
• 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 to the 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 cannot are impossible by design (as described in figures 3 and 4).

   Standard web applications:

   
   Figure 3

    With Visual WebGui:

   
   Figure 4

2. By design, client scripting cannot control the server behavior simply because the responsibilities of the client are limited to:
   • Render client UI.
   • 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)
   • Accept server instructions and re-render UI parts
3. The server-based, event-driven design results in an enterprise-level Security & very high level of fine-grained control over precisely what the user is seeing - all using one programming language - standard .NET (C#, VB, etc.)
4. Visual WebGui does not imply that it provides a solution for all the security issues of the world; however, through the Visual WebGui communication protocol it is impossible to hack a web application. This means that assuming https and/or any other secured communication solution (i.e. WCF) is used to secure the HTTP communication and that the OS and DB are safe on the server side, Visual WebGui applications are thoroughly and completely safe.