.Security challenges of AJAX:
The benefits of AJAX are undisputed, in particular the techniques that empowered the Web 2.0 experience. This helped make AJAX very popular among mainstream webprogramming because it offered a richer web UI and more fluid page transitions. Today, approximately 60% of all newly built websites use some AJAX components. 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.
Analysts believe that one of the main reasons for the low penetration rates into enterprise applications is the security complications that traditional AJAX creates. A traditional Web 2.0 AJAX application creates scatter calls to the server instead of the centralized one of Web 1.0. “Not only does this scattering of AJAX calls make it difficult for developers to handle, but also tends to induce sloppy coding practices because these calls are hidden and not easily obvious,” noted Shreeraj Shah in Top 10 Ajax Security Holes and Driving Factors. The increase in the application’s endpoints also naturally raises the application’s vulnerability, as more services between the client and the server open up.
So where does that leave us? Using today’s technologies and, more specifically, .NET, we are offered many great solutions and methodologies to help us understand how and with which tools we can secure our applications. The most painful security challenges aren’t in using standard protective solutions to secure our server’s farm or in securing 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 challenges today, which worsen when it comes to thick clients such as traditional AJAX clients, Flash/Flex or Silverlight based clients, is that the more broad and accessible the system becomes the less we can control or even know who are our clients. We should never forget that thick clients hold sensitive data which is potentially accessible to those clients. Furthermore, in many cases the clients contain logics and abilities that can change the flow of the application; if the clients are hacked, the application is completely exposed to fraud access.
The Empty Client Alternative:
The Empty Client presents a paradigm shift that entirely clears-up the security issues of traditional AJAX clients due to the fact that nothing except for UI commands and one static kernel is downloaded to the client. Therefore it is impossible to hack into or manipulate to get access into the server via the client.
This means that:
- 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.
- The server exclusively handles interaction with data and other services.
- The client is responsible to render UI and send events to the server; in any case it can never control the server’s behavior.
- Each client request is validated by the single layer server code which constitutes a single point access control center.
Traditional AJAX performs direct calls to the server from multiple controls independently. This means that each control can communicate with a server component directly, multiplying the chance to find a vulnerable behavior in client – server communication and increasing the difficulty to protect the channel. Furthermore, in most of the cases web-services are open at the server end since traditional AJAX perform most of its UI-logics on the client and retrieves only data from the server, making it even more difficult to fully protect all of those exposed ends.
The Empty Client model has a single communication channel; all of the communication is performed through this single, highly protectable router mechanism which by-protocol will not allow false requests to go through and activate no-permission event handlers to occur.
Understanding Empty Client Security:
Without delving into details, the security of the Empty Client model should be quite obvious from the introduction. The only issue that needs further clarification is a key claim which was specified above, regarding the fact that the client cannot change the server behavior whatsoever. The following flow, which describes a typical Empty Client application, explains why this 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:
- 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
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 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.
- 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.