Today's Rich Internet Applications (RIAs) bear about as much resemblance to the early Web sites of the 1990s as today's cars bear to a Model T. While the principle may be the same, the underlying technology is radically different. While safety testing for automobiles has improved significantly in the past hundred years, though, Web-application testing remains stuck in a 1990s mindset. In this week's column, Bryan Sullivan explains that QA must change its testing approach in order to maintain the security of the code.
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. This can be done without forcing the user to wait through potentially lengthy round-trip calls to a server. The end result is an improved user experience that rivals 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. All of the real logic processing took place on the server; now, though, 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. The important question, though, is: Just because you can push logic to the client, does that mean you should? Processing code on the server eats up performance time. Additionally, 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. There is, however, one serious problem with this approach: security.
Code that runs on the client tier is beyond the control of developer 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. This allows anyone to 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 and left the 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) and 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 business logic on the client tier is unacceptably dangerous. Every RIA's quality-assurance test plan should ensure that the client-side code contains only presentation logic. What this means is that QA professionals can no longer rely on a Web browser as their sole testing tool for RIAs. QA teams have to examine the details of the RIAs' client-side components in order to ensure that no business logic has crept into the client code (either accidentally or intentionally). For Flash and Silverlight applications, this requires decompilation of the downloaded SWF or DLL files. For JavaScript, it may require downloading external script source files.
QA professionals should not consider looking at source code or using disassemblers out of the scope of their responsibilities. While it is true that, previously, they never had to perform these actions when testing traditional Web applications, RIAs have expanded the scope of the QA's responsibilities. Simple, manual, black box testing of the application through a Web browser is no longer sufficient. In order to ensure security, the QA arsenal must expand to include new tools and processes in order to thoroughly test all aspects of RIAs.
