The Security of the Empty Client Model: In contract with AJAX - Page 3

The benefits of AJAX are undisputed, in particular the techniques that empowered the Web 2.0 experience. AJAX, however, has not achieved a penetration rate that is even close to that of the enterprises. In fact, only 1% of newly built enterprise web applications utilize major AJAX infrastructures

WEBINAR:On-Demand

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 element Ids and the actions which performed.

Security aspects: events are reflecting UI behavior and never applicative logic which is uniquely handled by the server. Furthermore, the client cannot affect the server's business logics and application run as the server is uniquely responsible for that.

Flow Step 4: The server executes the event handler and sends back highly optimized UI instructions to the client. The instructions are reflecting the minimal 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, it 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.

Conclusion:

Security concerns are essentially eliminated because many of the common client security holes (created by either applicative or sensitive data which is kept on the client or even simply sent to the client) are impossible by design Moreover, 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.

Another reason this is a secure option is because 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.). And finally, although the Empty Client approach does not attempt to present an ultimate solution for all the security issues, developers do know that it is impossible to hack a web application through its communication protocol. 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, the Empty Client application is thoroughly safe.

The major question raised about Empty Client is why it isn't more popular; after all, it seems to offer a serious solution. Unfortunately, problems with technological security have created a paranoia that renders us apprehensive to try something new. But developers by nature need to be pioneers, willing to forge ahead with something new. And because of that, it is likely that this will become the alternative to living in a technological world of security compromises.