Web Security : Attacking AJAX - Intercepting and Modifying AJAX Requests

1. Problem

You need to test the security of your server-side AJAX APIs. One of the easiest ways to do this is to intercept one that is already well-formatted and modify it in strategic ways.

2. Solution

Configure your web browser to use WebScarab. In this case, start up WebScarab and click on the Proxy tab. Choose the Manual Edit pane and look for the check box labeled Intercept requests, as shown in Figure 1.

Figure 1. Enabling request interception in WebScarab

Note the Include Paths matching option. You could, for example, put .*.php in that box to limit it to only URLs that end in .php. If your AJAX APIs have even more specific names, you can be very targeted with your interceptions by specifying strict patterns to match. When your web browser makes a request, a window will pop up, such as the one shown in Figure 2.

Figure 2. Intercepted request in WebScarab

Notice that every field in the request is available for editing. Just click on a field (header, value, or content) and change it to be what you want. Click Accept Changes and your request goes to the server, with your modifications.

3. Discussion

The application we used for this example is WordPress, a popular blogging platform. The particular AJAX event shown is the automatic save feature. After a certain amount of time or text, WordPress will save your post automatically. If your Internet connection is interrupted, your session times out, or your computer crashes, you will still have some part of your post saved. This is a great example of AJAX because it is truly asynchronous. It just happens.

There are several useful things you can do here. You can insert some of our test values for attacks like cross-site scripting, SQL injection, or cross-site reference forging. You can also tamper with cookie values. You can do standard testing, too, like boundary values and equivalence classes.

Notice the Content-length header. If you make significant changes to the request that change the overall length of the message, you’ll need to update this value. Unfortunately, WebScarab will not calculate the new value for you. If the Proxy-Connection or Connection header are present and say keep-alive, most servers will take the Content-length header literally and will wait for the right amount of data. Set it too low or too high and you can get weird behavior. The best thing to do is keep track of your changes (plus or minus bytes) and then do the addition to update the Content-length to the right value. An alternative is to set the Proxy-Connection or Connection header to the value close. Most servers will ignore a bad Content-length if they’re instructed to close the connection.