Gizmox > Solutions > Visual WebGui > The VWG Concept > Security
         
 

VWG Security 

 

 

Using today’s technologies and more specifically .NET, there are many great solutions and methodologies which help us to understand how and using which tools we can secure our applications.

The most painful security issues aren’t in using standard security solutions to secure our server’s farm or to secure the messages sent between the client and the server. Those security tasks can be quickly and efficiently achieved by using today’s firewall capabilities and other secured server’s farm solutions and by securing the transferred data using HTTPS, WCF and other great solutions.

The most problematic issues today which gets worst when it comes to thick clients as fat AJAX clients, Flash/Flex and Silverlight based clients are that the more broad and accessible the system becomes the less we can control or even know who are our clients whereas thick clients hold sensitive data which is accessible to those clients.

Visual WebGui and Security

Being a paradigm shift in form of Empty Client, Visual WebGui clears-up entirely those issues due to the fact that nothing except for UI commands and one static kernel is downloaded to the client. This means that:

  1. No sensitive/hidden data is sent to the client. Neither the infrastructure nor the developers can perform security violations by sending sensitive data to client machines.
  2. The server exclusively handles interaction with data and other services.
  3. The client is responsible to render UI and send events to the server; in any case it can never control the server’s behavior.
  4. Each client request is validated by the single layer server code which constitutes a single point access control center.

Standard web applications:

 Conventional AJAX web applications security

With Visual WebGui:

Visual WebGui AJAX Security

Without diving into details, the Visual WebGui security model should be quite clear from the introduction part alone. The only issue that needs further clarification is a key claim which was specified above the fact that Visual WebGui client cannot change the server behavior whatsoever.

Visual WebGui Secured Pipeline

The following flow which describes a Visual WebGui application explains why the key-claim is true: 

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.

Visual WebGui Security Model

Conclusion

  1. Client security-holes which are commonly created by either applicative or sensitive data which is kept on the client or even simply sent to the client are impossible by design. 
     
  2. Client scripting cannot control the server behavior as "by design", simply because the responsibilities of the client are limited to:
     
    • Render the UI at the control level – meaning that utilizing the XSLT, the client kernel can render:
      • The entire screen – this happens only when the UI is entirely replaced.
      • Specific control (thoroughly) – this happens when the control cannot be partially drawn to adjust to its new given state.
      • Control Part – this is the most common scenario, in this case only the part of the control which has changed is drawn.
      This responsibility is pure client side and cannot affect any server behavior. The only server’s requests which can be caused by such client action are when the rendering of whatever is rendered items require resources (i.e. images, or dynamic data). Those requests are uniquely controlled by the server code.
       
    • 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)
      • Those are predefined events which are exclusively handled by predefined handlers and can never affect other parts of the code or change the server behaviors.
      • Any non-formatted data which will be added to those requests will be filtered by the server and might invalidate the entire request.
      • Replaying requests does not affect the server behavior due to a unique timestamp mechanism.
         
  3. The server centric , 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 to present an ultimate solution for all the security issues, 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. 

Next >>