H IDDEN F ORM I NPUTS

Although hidden form inputs have already technically been covered in the “Form Inputs” category, they deserve a brief special mention of their own. Just like cookies and headers, hidden form inputs have no graphical representation in the browser. They are, however, still implicitly specified by the user. Malicious users will explicitly set these inputs to different values in the hopes that the site programmers believed the inputs were unchangeable. Hacks like the client-side pricing attack are based on this fallacy.

Q

P

All of the data sent to the server in the query string portion of the URL is user input and must be considered part of the application’s attack surface. This data is usually not directly modified by users—at least, by legitimate users. A good example of this is a data- base driven news site whose news stories are served with URLs like news.jsp?storyid=1349

where 1349uniquely identifies the news story that the user wishes to read. A user never explicitly types this value into the application. Instead, the storyidparameter and value already exist in hyperlinks generated by the news site. While not explicitly set by the user, these query string parameters are almost always processed by the application and must be properly secured. In this example, the value of the storyidparameter may be used in a database query and consequently may be vulnerable to a SQL Injection attack.

CHAPTER4 AJAXATTACKSURFACE

Beyond the typical uses of query parameters to pass data to the server or between pages, query parameters can also be used to track session state without the use of a cookie. Actually, this action is just a specialized case of passing data between pages. As we stated earlier, many users are wary of cookies for privacy reasons and configure their browsers to not accept them. Unfortunately, doing this prevents the user from being able to use applications that store the session identifier in a cookie. With no way to identify the user or track her session state, the application will treat every request as the user’s first request. In order to accommodate these users, an application can be programmed to store the session token in the query string rather than in a cookie. To do so, the URL: http://server/app/page.php

could be rewritten as:

http://server/app/page.php?sessionid=12345

Every user would get a unique sessionidtoken, so one user might have sessionid=12345

appended to all of the hyperlinks on her page, but another user would have

sessionid=56789appended to all of his.

This URL rewriting technique is an effective way to solve the problem of tracking state without the use of cookies; but, it does rely on the user’s goodwill. If the user misbehaves by tampering with the session identifier in the query string, several unpleasant outcomes are possible. If an attacker is able to obtain another user’s valid session identifier—either by intercepting messages between the other user and the server or simply by brute force guessing—then it is a trivial matter for the attacker to use that identifier and imperson- ate the victim. All the attacker has to do is to type over his own session token in the browser URL with the newly stolen token. No special tools are necessary.

TRADITIONALWEBAPPLICATIONATTACKSURFACE

SECURITY NOTE

It is ironic that many users disable cookies in their browsers out of security fears, when, in fact, this action can actually make them more prone to attack! Many Web applications will attempt to store their session token in a cookie first. If that fails because the user rejects the cookie, the application then switches to a cookieless

URL rewriting technique. The problem with this is that it is much easier for an attacker to intercept data contained in the query string portion of the request than data contained in cookie values. The URLs, including the query string, are often

Another ill-advised, but unfortunately all too commonplace, use of query parameters is to program in a secret backdoor to the application. By appending a certain value to the URL, like debug=onor admin=true, the application provides additional information, such as usage statistics, in the response or grants the user additional access privileges. Many times these backdoors are created by programmers to help them debug the application while it is being developed. Sometimes the backdoor finds its way into the deployed pro- duction site because the developers forget to remove it; sometimes it is left there inten- tionally because it is just so useful when debugging problems with the application. Besides, no one outside the development team could ever find out about it, right?

The reality is, the odds are very good that someone will find that backdoor and exploit it. Simple backdoors like admin=trueare likely to be guessed by an attacker. This approach is like hiding your door key under the mat. Everyone looks there. Longer or less obvious choices, such as enableAdminPrivileges=onor abcxyz=1234are really only slightly better. No attacker would randomly guess a backdoor value like either of those, but there still are ways that she could find out about them. The most obvious is simple word-of-mouth. The developer who added in the backdoor told his friend in the Quality Assurance department, who then told her friend in the Sales department, who then told one of his customers, who then posted it on the Internet for the whole world to see.

Another possibility that would result in the exposure of the backdoor is if the applica- tion’s source code were to be accidentally released to the public. This is not as rare of an occurrence as you might think. It happens mainly due to inappropriate source control practices. For example, let’s say that the main page for Simon’s Sprockets is default.php. One of the programmers needs to make a change to this page, but wants to keep a backup of the original in case the change breaks the code. So, he makes a backup copy of the file called default.php.bak. Unfortunately, he neglects to move this backup file out of the Web application directory, which makes it accessible to anyone. Anyone who requests this file will see the complete source code of the original default.phppage, because the Web server will not know to interpret .bakfiles as active content and will simply serve up the text of the file to the user.

CHAPTER4 AJAXATTACKSURFACE

stored in request log files. If these files were compromised, the attacker would have clear access to any session using cookieless session tracking. There may be legal reasons to avoid developing applications that rely on cookies—for instance, United States Federal government Web sites are prohibited by law from using persistent cookies—but in terms of security, keeping a session token in a cookie is better than keeping it in the query string.

The bottom line is, regardless of how obscure you make your backdoor, it’s still possible that a malicious user could find out about it and penetrate it.