Web Pages Requesting External Data | Hunting Security Bugs

Web pages are designed to access external data. Most Web pages on the Internet request external data. For example, pages that contain graphics make external data requests to display them. The security model of Web browsers should not allow a Web page on one domain to read content on another domain (this is discussed in Chapter 10, HTML Scripting Attacks ). However, the browser s security model does not prevent it from making requests to other domains for most types of data. (The Web browser security model allows one domain to force the browser request data from another domain but does not allow different domains to read the response of such requests .)

As discussed in the previous document format example, if an attacker can coerce a target into making certain requests, the requests themselves can be harmful. Unlike document formats discussed earlier in which the application mitigates the risk by not allowing harmful requests, in the Web page case the server receiving the request must protect against the repurposing attack. An attack that allows an adversary to get a victim to perform specific actions against a Web application by forcing the victim s machine to make Web requests specified by the attacker is known as a cross-site request forgery (CSRF) attack. This type of attack is commonly referred to by Microsoft as a one-click attack, with a variation called a zero-click attack. Microsoft used these terms internally before the term CSRF was used externally. For this reason, you might see these terms used instead of CSRF in some documentation produced by Microsoft. Because CSRF better describes the attack, we use this term in this text.

Important

Many Web applications are vulnerable to CSRF attacks. This type of vulnerability is often mistakenly overlooked when doing security testing, making this a fruitful area to test.

CSRF Through Query String URLs

In Chapter 4, Becoming a Malicious Client, you learned how some Web applications take input through the query string (a GET request). Imagine a Web mail application that has a button to delete the current e-mail message. When the button is clicked, the browser is redirected to http://server/delete.cgi?msgId=1 . When this URL is requested , the Web application verifies the request comes from an authorized user and, if successful, deletes the first message from the user s inbox (signified by the msgId parameter). If an attacker coerces a victim to load this URL, the first message from the victim s inbox will be deleted. Although an attacker could create a Web page or send an e-mail message that contains a link and hope the victim clicks it, the attacker could also use the following HTML normally used to display an image instead:

 <IMG SRC="http://server/delete.cgi?msgId=1">

Without the use of script, this HTML will automatically load the SRC URL to retrieve a picture. Because delete.cgi doesn t return a picture, one will not be displayed, but the first e-mail message on the server will be deleted unknowingly by the target.

Important

The same techniques used to coerce a target into sending an attacker s data in cross-site scripting attacks are used for CSRF attacks.

Whereas query string data is commonly used to modify settings and data, the HTTP specification states that only data retrieval should be done with GET requests. The first step in circumventingthis problem is to prevent the server from accepting GET requests but instead allow it to accept only POST requests for anything except data retrieval. However, this alone does not solve the problem.

Note

How does an attacker get a victim to authenticate against the vulnerable Web site? In a CSRF attack, the attacker wants the Web application to perceive the forged request as coming from the victim. The victim must be logged on to the Web application for this to occur. Some Web applications use cookies or Windows Integrated authentication to log on users automatically. Automatic logon makes CSRF attacks easier. If automatic logon isn t possible, attackers might be able to attack targets after the targets have already logged on, or attackers might even use social engineering techniques to trick the target into logging on.

CSRF Through POST Data

The same general problem that allows CSRF attacks to occur with query string data exists with POST data. The only difference is that the data cannot be contained only in the URL. Chapter 10 discusses a way an attacker could exploit cross-site scripting (XSS) flaws in applications that accept POST data that involves an attacker creating a form prepopulated with the data the attacker wants the target to POST and where the attacker wants it POSTed. This same technique applies to CSRF attacks in which the Web application accepts POST data.

For example, the following HTML is used to create a new user account on a Web site and contains three input fields: user name for the new account, password, and confirmation of the new password.

 <form name="createForm" id="myForm" method=POST action="http://server/createUser.cgi"> <table border="0" width="39%">    <tr>       <td width="123">Username:</td>       <td><input type="text" name="username"></td>    </tr>    <tr>       <td width="123">Password:</td>       <td><input type="password" name="passwd1"></td>    </tr>    <tr>       <td width="123">Confirm Password:</td>       <td><input type="password" name="passwd2"></td>    </tr>    <tr>       <td width="123">&nbsp;</td>       <td><INPUT type="submit" value="Create Account"></td>    </tr> </table> </form>

This HTML form submits to createUser.cgi, which processes the form and creates the new user account. An attacker could host a copy of this form prepopulated with a user name, password, and confirm password of the attacker s choice. The attacker-hosted copy could also include JavaScript to automatically submit the form. If a user who has access to create accounts through createUser.cgi views the attacker s copy of the form, the new account will be created.

Common Ways to Prevent CSRF Attacks

A common way to prevent CSRF attacks is to add to each form a validation form field that contains data that should not be determinable by the attacker and that is unique for the user requesting the form. When the form is submitted, the validation form field is checked to be valid for the current user. If the validation field is correct for the user submitting the form, the request is accepted. Otherwise, the request is considered to be a CSRF attempt and is immediately rejected.

The following HTML is an example of a validation form field included as part of an HTML form with CSRF protection:

 <input type="hidden" name="__REQUESTDIGEST" value="0x499F221FF714785447B7213E765D4914,12 Apr 2006 05:47:14 -0000" />

Important

One cross-site scripting or script injection bug anywhere on the Web site enables an attacker to bypass the CSRF prevention validation form field. This is because the attacker can use the XSS bug to automatically navigate the client browser through the series of steps necessary or can obtain the value of the validation field of the targeted user.

When brainstorming ways to prevent CSRF attacks, people often suggest keeping state on the server to verify the form was loaded immediately before the POST request is received. Another common suggestion is issuing a cookie when visiting the form and verifying the cookie before processing an HTTP POST. These do not prevent the problem! Can you think how an attacker might bypass these techniques without another bug in the site? With JavaScript, an attacker can get the victim s browser to load any URL. An attacker can force the Web browser of the target to visit the HTML form and then load the attacker s form, which does an HTTP POST to the vulnerable Web application. This defeats both the suggested server-maintained state and the cookie mitigations. This approach to defeating server maintained state and cookie mitigations does not foil the hidden form field mitigation previously described. For this reason, the hidden form field is the recommended mitigation.

Tip

ASP.NET 1.1 and later can manage the validation field for Web applications by using the Page.ViewStateUserKey property. This property stores the undeterminable user-unique validation data in the _VIEWSTATE form field. For more information, see http://msdn.microsoft.com/library/en-us/cpref/html/frlrfsystemwebuipageclassviewstateuserkeytopic.asp .

CSRF Through SOAP Data

As discussed in Chapter 11, XML Issues, SOAP allows a client to call into functions on the server. Similar to HTML forms that use POST, SOAP uses HTTP POST to send its XML requests to the server. Unlike typical HTML forms sending POST requests, a form isn t displayed prior to making a SOAP request, so the validation form field mitigation wouldn t work as easily in this situation. Instead of adding mitigation to the Web application, the mitigation is in the client making the SOAP request. This is similar to what happens in the document format case first discussed at the beginning of this chapter.

In Microsoft Internet Explorer, a Web page that attempts to make a SOAP request to a different server causes the XMLHTTP object to display a security dialog box that asks the user whether to allow the cross-domain SOAP request. This dialog box is shown in Figure 19-2.

Figure 19-2: A warning dialog box that appears when a page on one domain attempts to call a SOAP method in another domain

As long as every client blocks or warns in places where a target can be coerced to make a SOAP request to an arbitrary server, CSRF isn t possible through SOAP, right? Maybe. It turns out that SOAP messages also can be sent using HTML forms using either GET or POST. SOAP through GET and POST isn t always supported by the server. If these types of requests are supported and the SOAP method can do harmful actions or receive sensitive data, they are great targets for a CSRF attack.

The following URL uses GET to request a call to the SOAP method called bid with the id parameter set to 5089 and the amount parameter of 1000:

http://server/auction.asmx/bid?id=5089&amount=1000

Alternatively, if the server accepts SOAP requests through form POST requests, the following HTML form could call the bid SOAP method:

 <FORM name="myForm" action="http://server/auction.asmx/bid" method="POST"> <INPUT type="hidden" name="id" value="5089"> <INPUT type="hidden" name="amount" value="1000"> <INPUT type="submit"> </FORM>

In ASP.NET, SOAP GET and POST requests can be configured on the server. To ensure HttpGet and HttpPost are not enabled check the machine.config and web.config files. For more information about this configuration, see http://msdn.microsoft.com/library/en-us/cpguide/html/cpconConfigurationOptionsForASPNETWebServices.asp .

Testing for CSRF Attacks

The following tips can be used to help you find identify CSRF bugs :

Use the techniques discussed in Chapter 4 and Chapter 11 to identify GET, POST, and SOAP requests the server accepts.
Verify that no GET requests can modify settings and data.
Verify that all POST requests that can modify settings and data contain a validation field that cannot be determined by another user.
To verify that the validation form field used to prevent CSRF attacks cannot be used by a different user than the one who requested the form, try loading an HTML form as one user and submitting it as a different user. If the requested action succeeds, you ve found a bug.
When testing SOAP Web services, ensure HTTP GET and POST are disabled for requests that could modify or retrieve settings and data.
When testing an application that allows an attacker to specify that the victim make a SOAP request, make sure the application doesn t support or warns when SOAP requests are made to arbitrary domains.