Ajax Attack Surface
F ORM I NPUTS
Contrary to popular belief, most Web sites are not hacked through secret backdoors hid- den inside the applications; rather, they are attacked through the plainest, most obvious entry points possible: the applications’ form inputs. Any dynamic Web application, Ajax- based or not, uses some type of form input to accept data from the user and responds to data. Examples of form inputs include:
•
Text boxes:<input type="text">•
Password boxes:<input type="password">•
Check boxes:<input type="checkbox">•
Radio buttons:<input type="radio">•
Push buttons:<input type="button">•
Hidden fields:<input type="hidden">•
Text areas (multiline text boxes):<textarea>•
Drop-down lists:<select>There are three major factors that contribute to a hacker’s attraction to form inputs: They are easy to find; easy to attack; and there is a high probability that their values are actually processed by the Web page’s logic.
With the exception of hidden form fields, every form input on a page can be seen just by viewing the page in a browser window. Even the hidden form fields can be easily
found by viewing the page source from the browser. Technically, every entry point into an application is considered part of the application’s attack surface, regardless of whether it is highly visible or highly obscure. That being said, highly visible entry points like form fields are the first things attackers will notice, so it is that much more important to secure them.
CHAPTER4 AJAXATTACKSURFACE
SECURITY NOTE
An alternative way to look at this is that, due to their relative lack of importance, the highly obscure entry points probably do not receive as much attention from the developers and testers as the highly visible ones. This may lead an attacker to seek out these obscure inputs because the odds are greater that they were not thor- oughly tested or properly secured before the application went into production.
Form inputs are also very easy to attack. A hacker can simply type his attack text into the Web form and submit it. No special programs or tools are required, only a Web browser. This presents a very low (in fact, almost nonexistent) barrier to entry for a would-be hacker.
Finally, there is an excellent chance that every form input is used and processed by the application. In contrast to cookies and headers, form inputs, in general, are intentionally added to a page for the express purpose of collecting data from a user. The page logic may never process the User-Agent header or a cookie value, but it will almost certainly process the value of the Email Address text input in some way.
C
OOKIESThe Web cookie is one of the most frequently misunderstood concepts in Internet com- puting. Many users regard cookies with suspicion, equating them with spyware and viruses. It is true that some sites have abused cookies and violated their users’ privacy, but to date, no spyware or virus has been transmitted through a cookie. Users may be a little overly wary of cookies, but programmers have their own misconceptions about cookie security that usually falls too far to the other extreme.
In a nutshell, the intended use of a Web cookie is for the Web application to create it and for the user’s Web browser to store it and return it to the Web application as is. Developers sometimes assume this is the only possible use of a cookie. However, unless the cookie data is encrypted, there is nothing to prevent an attacker from tampering with it. In this case, by encrypted, we mean that the actual cookie datamust be encrypted—
and not simply that the request be submitted over an SSL connection. SSL will prevent third parties (neither the user nor the server) from eavesdropping on the transmission; however, once the server response reaches the client, it is unencrypted and any cookie values are set in plaintext on the user’s machine. There is a difference between encrypt- ing data while it is in transitand while it is at rest. SSL is an excellent solution for the for- mer, but an alternative must be found for the latter.
Cookies are often used to store session identifiers or authentication tokens1. Large,
enterprise-scale Web applications that are deployed across several load-balanced servers often store their session state in a SQL database because the session data will be main- tained in the event of a system crash. In addition, they store the session state in a SQL database because server farms cannot easily access session state stored in-process. Of course, as we know from Chapter 3, “Web Attacks,” any time user input is used as a parameter in a SQL database query, there is a possibility for a SQL Injection vulnerabil- ity. Regardless of whether a cookie is used for session identification, site personalization, search preferences, or any other use, it is important to recognize it as user-defined input and treat it as such. If the application programmers are vigilant about locking down the form inputs but neglect the cookie values, they will likely find themselves the victims of a parameter manipulation attack.
H
EADERSIt may not be immediately obvious, but HTTP request header values are user input— and therefore potentially vulnerable to attack—just like form input values. The only dif- ference between the two is that form input values are provided directly by the user, whereas header values are provided indirectly, by the user’s browser. To the Web server processing the request, this is really no difference at all. As we’ve said before, successful hackers don’t limit themselves to using only Web browsers to make their attacks. There are dozens of utilities that allow an attacker to send raw HTTP requests, from graphic programs like Eve’s HTTP Editor (see Chapter 2) to command-line tools like wget or even telnet, which are installed by default on most major operating systems today.
TRADITIONALWEBAPPLICATIONATTACKSURFACE
1 Cookies can also be used as a form of client-side storage, as we will discuss in depth in Chapter 8, “Attacking Client-Side Storage.”
SECURITY NOTE
Always remember: Just because an attack cannot be made with a Web browser, it does not follow that the attack cannot be made at all.
It is less common for Web applications to act on the values of the incoming request headers than it is for them to act on other parts of the request, such as the form input values or the cookie values. However,less commondoes not mean never. There are some headers that are more frequently used than others. The HTTP header Referer2specifies
the URL from which the current page was linked; or, in other words, the page you were on before you came to the current page. When this header value is processed by the server, it is usually for statistical tracking purposes. Tracking the referrers can be a good way to find out who is sending you traffic. Again, if the Referervalue, or the User-Agent
value—or any other header value—is being stored in a database, the header may be vul- nerable to SQL Injection. If the values are displayed in an administrative statistics page, they may be vulnerable to an XSS attack—and an especially effective one, considering that only users with administrative privileges should be viewing the data.