Logic in the Client

Beefing up the client side of your application to make it more interactive and responsive often requires you to simply do more work in the client. The client either has to perform more business logic that you traditionally have been performing on the server, or has to decide when something is important enough to go to the server. The AJAX approach encourages you to make your client code perform more of these calculations and decisions in the browser, potentially enticing you to do sensitive things in an insecure manner within the browser. This manifests itself in a couple of ways.

First, you should remember that everything you do in client code is easily readable and understood by a user. No matter how you try to obscure your markup or client-side scripting, it is absolutely vulnerable to reverse engineering and manipulation—without exception. There is no way to effectively prevent this. By using the handy "View Source" feature of every browser, an attacker can easily read all of the source code of the client side of your application. If you link to script libraries in your page but they do not appear in the View Source for the page, these files are still readily downloadable from the server. Attackers can use all of this information to reconstruct the logic of your application, and increasingly they are simply stealing it to make malicious copies of your Web applications for use in phishing schemes.

Second, an attacker can fairly easily modify the behavior of all of the client code that you send to the browser. For many applications, modifying the source is harmless and only allows users to change the way the application looks or behaves in their browsers. On the other hand, everything that is sent to the browser, including all of the look and feel and JavaScript functions, is stored in the browser DOM. Attackers then have a variety of ways to manipulate every bit of information in the DOM to change the way the application behaves or to inject malicious behavior. Using the cross-site scripting techniques discussed later, attackers can essentially inject bad scripts into your pages and persist them as long as you allow and modify things in the DOM of your browser.

Let's again look at the simple ASP.NET AJAX stock quote example. If I am viewing this page in Internet Explorer, I can choose to View Source and see all of the local source code that was sent to me. I can use this source view to understand everything that the page is doing and even what the server might be expecting. If the page is using client-side validation, I can reverse engineer the JavaScript to understand what the developer considers to be valid input. From this I can tell whether the developer has missed something in his validation scheme, such as negative numbers, extremely large strings, and numbers that might allow me to crash the Web service. I can probe the server to see if the same validation exists there. The code in the browser gives me an excellent view of the application attack surface without much trouble at all.

I can also see what local variables were declared in the page to see if there is anything I can change locally to alter the behavior of the application. The source also tells me a little about the Web service that the page is communicating with. The ASP.NET AJAX client script code for communicating with the Web service is downloaded to the browser, some of which looks like this:

<script src="StockQuote.asmx/js" type="text/javascript">
</script>

From this script code, I can see the name and location of the Web service and how to get to the JavaScript proxy for the Web service. All of this is valuable information to a hacker that would not have been available had my server code been taking care of the communications with the Web service. Because it is necessary to put so much more information and logic in the client code that your application sends to the user's browser, you carry more of a burden to take security precautions in the server side of your application.

Bypassing Client Validation

The most frequent cause of all Web application vulnerabilities is a lack of input validation of information sent to your application by a user. And the second most dangerous thing to a Web application is relying on client-side validation to protect you from malicious input. As pointed out in the last section, every bit of code that you send to the browser can be easily viewed and modified by an attacker. Not only can the attacker change what your client code is doing, but he also can skip it altogether and circumvent any client-side validation (see Figure 2-3).

Here is how easy it is to bypass client validation. Download and install a client-side HTTP debugging proxy such as <a href="http://www.fiddlertool.com">Fiddler</a>. Configure your browser to use this local proxy for Web requests, or in the case of Fiddler, just start up the tool and it auto-configures the proxy for you. Visit a Web page that accepts input from the user and submits it to the server. For an example, you can use the security testing FreeBank site available at <a href="http://zero.webappsecurity.com">http://zero.webappsecurity.com</a>. (Note: Do not be fooled by the warning messages on the FreeBank site. The site is designed and maintained by a security vendor to appear like a real, hackable banking site for demo purposes.) Enter valid information for all of the required fields on the page and submit the page. Now turn to Fiddler and view the request that you sent by selecting the login1.asp session in the View Session window. Switch to the Request Builder tab in Fiddler and drag your session from the View Session window into the Request Builder window. From this window, you can now modify anything you want in the request and send it to the server, bypassing any validation that existed in the client code.

Figure 2-4 shows a request modified to include a SQL injection attack attempt. See the login parameter in the Request Body section for the malicious data going directly to the server.

From this example, you can see how easy it is to use proxy tools to bypass client validation, rendering it useless as a security countermeasure. With AJAX applications, you are increasing the number of inputs in your applications and you are using user-entered data to communicate directly with the server and Web services. Even if you are a diligent ASP.NET developer and are using validation server controls to validate all of your page inputs on the client and the server, you are still vulnerable with AJAX. If your application is taking data from a user and sending it directly to a Web service, exactly as we did in the stock quote ASP.NET AJAX example, you are opening up the possibility of completely bypassing validation if you are not validating every input into your Web service. ASP.NET validator server controls do not help you here. Validating the stock symbol in the client will save a trip to the server only if the data is invalid; it does nothing to protect the server from tainted data and potentially malicious commands.