Rich Internet Applications (RIAs) differ from traditional Web applications in that they offer more elegant and desktop-like user interfaces. With frameworks that include Ajax (Asynchronous JavaScript and XML), Adobe Flash/Flex, Microsoft Silverlight, and Sun JavaFX among others, RIAs allow the developer to create applications that can respond immediately to user input without forcing the user to wait through potentially lengthy round-trip calls to a server. The end result is an improved user experience rivaling a desktop application and with the zero-size footprint of a Web application.
RIAs are also different from traditional Web applications in that a significant amount of application processing can take place on the client machine, which is the source of the RIAs' performance improvements over traditional Web applications. RIAs are faster because much of their code is executed directly on the user's machine. This is a dramatic difference from the early days of the Web when browsers basically behaved like dumb terminals. Their only real purpose was to accept user input, send it to the server, and display the response. Back then, all the real logic processing took place on the server. Now, however, the capabilities of the Web browser have greatly expanded.
Virtually every modern browser has inherent support for JavaScript and, through browser add-ins, can run ActionScript (Flash), Java, and even .NET languages like C#. These full-fledged programming languages are capable of performing many of the same tasks as their counterpart code running on the server. Even Flash, which is sometimes thought of as being useful only to provide some graphical "eye candy," can easily execute business-logic routines such as compilation of bills of materials or sales tax calculations.
However, this begs the question: Just because you can push logic to the client, does that mean you should? Processing code on the server eats up performance time; also, network bandwidth is required to accept the request and to send the response. If all of this logic could be handled by the client, then the server would be faster and more scalable. But there is one serious problem with this approach: security.
Code that runs on the client tier is beyond the control of the developers and other teams within the organization who own the code. An attacker can attach one of the many, freely downloadable, debugging utilities to the RIAs component that exists in the Web browser and infiltrate the source code of the application as it executes. Any secrets in the client code will be plainly visible.
There was a recent case in which a high-profile computer conference's discount code was discovered embedded in the registration application. Unfortunately, the logic for checking and applying the discount code was implemented on the client. Before long, hackers found and used the secret code leaving conference organizers wondering how so many people were getting discounted passes to the show.
Even worse, attackers can use these same debugging tools to change the client-side logic entirely. Code statements can be executed out of order (e.g., first transfer the funds, then check authorization) or skipped entirely (e.g., just transfer the funds). Variable values can be altered (e.g., instead of a 50 percent discount, give a 100 percent discount). Input limitations can be removed (e.g., the phone number field will now accept values sixteen megabytes long). Again, code that is executed on the client is outside the control of its owners. There is simply no way to ensure that the code is executed as it was intended, or even that it is executed at all.
It is clear that, as tempting as it is from a performance standpoint, executing
About the author
Bryan Sullivan is a security program manager on the Security Development Lifecycle (SDL) team at Microsoft. He is a frequent speaker at industry events, including Black Hat, BlueHat, and RSA Conference. Bryan is also a published author on Web application security topics. His first book, Ajax Security was published by Addison-Wesley in 2007.
