XSRF and threat ratings

Readers who are relatively long in the tooth will remember the sweet, carefree days before the web was blighted by cross-site request forgery (XSRF). Like or loathe these vulnerabilities, they are here to stay, and as penetration testers we need to look for and report them.

One often overlooked aspect of the arrival of XSRF is that it obliges us to reassess the threat ratings associated with some other types of vulnerability. Here is one example.

Consider an application which contains a function for administrators to view a user's details:

https://myapp/admin/ViewUser.asp?UID=123

The UID parameter is inserted into a dynamic SQL query, which is passed to MS-SQL Server, and so the application is vulnerable to SQL injection. However, the ViewUser function is protected by robust access controls which prevent lower privileged users from accessing it. Only administrators, who are fully trusted in any case, can exploit the bug. In days gone by, we would have called this a low risk issue, probably worth fixing from a defence-in-depth perspective, but nothing to get excited about.

Enter XSRF. Consider a different application which implements a function for administrators to issue SQL queries directly to the database. This is done using URLs like the following:

https://otherapp/admin/doSQL.php?query=
SELECT+*+FROM+ORDERS

This function is wide open to XSRF. An attacker can create a malicious web page which, if viewed by a logged-in administrator, will perform arbitrary queries on the database. For example:

<img src="https://otherapp/admin/doSQL.php?query=
INSERT+INTO+USERS+(username,password,isAdmin)+
VALUES+('jlo','secrets',true)">

We might classify this XSRF vulnerability as a medium or (if we are feeling excited) high risk issue.

Now, each of the functions described enables a crafted request to perform arbitrary actions on the database - the only difference is that this is the intended purpose of the second function, and is the consequence of bad coding in the previous example. But from an attacker's perspective, it doesn't matter whether the application's behaviour was intended or not - a vulnerability is simply a condition that can be exploited for some illicit purpose. And the first vulnerability can be exploited via XSRF just as easily as the second:

<img src="https://myapp/admin/ViewUser.asp?UID=
123;+INSERT+INTO+USERS+(username,password,isAdmin)+
VALUES+('wade','congrats',true)">

Hence, regardless of the access controls protecting direct exploitation of the SQL injection vulnerability, the threat rating we assign to this issue should be at least as serious as that which we assign to the second vulnerability. The arrival of XSRF as a recognised attack vector obliges us to identify ways of exploiting some other bugs that we may previously have overlooked.

When good XSRF defence turns bad

Talk about cross-site request forgery bugs seems to be in vogue, with various explanations of what the vulnerability is, and how to avoid it. As awareness has increased, and more developers attempt to defend against XSRF, it is not uncommon to find cases where someone has followed a standard piece of advice, but achieves nothing in terms of preventing attacks.

An application is vulnerable to XSRF if an "important" user action is performed using requests all of whose non-cookie parameters can be determined in advance by an attacker. For example, in a banking application a user might perform a funds transfer using the following request:

POST /TransferFunds.asp HTTP/1.0
Host: mybank.com
Content-Length: 48
Cookie: sessid=191r309ru13d10219029r31r90f1re029e

FromAccount=current&ToSortCode=123456&
ToAccountNumber=12345678&Amount=1000.00&When=now

An attacker wishing to induce a victim to transfer funds to his account can forge a request containing all of the necessary parameters with the exception of the cookie containing the session token. If this request is initiated from a web site the attacker controls, at a time when the user is logged in to the banking application, then the user's browser will automatically add the cookie parameter, and so the funds transfer will be carried out.

Now, a common recommendation for preventing XSRF attacks is that "important" actions like funds transfers should be implemented in two steps. In response to the first request, the application sends a nonce (an unpredictable value) to the client, which is submitted as a parameter in the second request. The application verifies the nonce in the second request, and only performs the action if this is valid.

The thought behind this defence is that the two-step approach confirms that the action originated from an authentic user, and not from a third-party web site. Although code running in an attacker's web page can initiate requests to the bank, the browser's same origin policy prevents it from accessing the bank's responses, and so the attacker's code will be unable to retrieve the nonce required for the second request. However, given the vague way in which the defence is often characterised, a developer who isn't thinking for themselves may be forgiven for getting it wrong.

I recently came across an application which had previously been full of XSRF flaws. Developers had reimplemented numerous functions using two steps, by issuing and validating a nonce. However, to enhance usability, the second step was implemented as an HTTP redirect. So the preceding request returned a response like the following:

HTTP/1.0 302 Object Moved
Location: /TransferFunds2.asp?nonce=120491746317280

The user's browser follows the redirect, thereby submitting the nonce (together with the user's session cookie), which is validated by the server. But the defence achieves nothing, because the user's browser behaves in just the same way if the first request originated from a third-party web site. The fact that the same origin policy prevents the attacker's code from accessing the bank's responses is irrelevant because it does not need to - it just relies upon the browser to process and resubmit the nonce in the normal way. A lot of development time had been wasted.

For the nonce-based defence to be effective, the request in which the nonce is resubmitted must result from some informed user interaction. For example, instead of performing a redirect, the first response could display the details of the proposed transfer, with the nonce in a hidden form field, which is submitted using "confirm" or "cancel" buttons. Because code on the attacker's web page cannot access this response, it cannot parse out the nonce and resubmit it. If performing actions over two stages is undesirable for usability reasons, then the nonce can be placed into the original form used to initiate the action. Provided the application properly ties the nonce to the session in which it was issued, then (in the absence of another vulnerability) an attacker will be unable to determine all of the necessary parameters to the original request, and so the main prerequisite for an XSRF attack to get going is not fulfilled.

DNS pinning and web proxies

DNS-based attacks against browsers have been known about for years. These attacks have received increased attention recently, following the discovery of defects within browser-based DNS pinning defences.

So far, discussion has focused on browser issues. However, the same attacks can also be performed against web proxies. Browser-based DNS pinning does not apply when a web proxy is being used, because the DNS look-ups occur on the proxy, not the browser. Hence, even if DNS-based attacks are completely addressed within browsers, the problem is not going to go away altogether.

The most significant opportunities for DNS-based attacks are against web users on internal corporate networks, as a means of gaining unauthorised access to sensitive information and web applications on internal intranets. Given that a large proportion of these users access the Internet via a proxy server, attacks against web proxies may represent at least as significant a threat as those against browsers.

I've written a short paper which explains the problem, examines possible software-based solutions, and describes the defences that organisations and individuals can use to prevent attacks against them. In summary:

• DNS-based attacks affect web proxies as well as browsers.

• Today's proxies are vulnerable.

• The problem is not straightforward to fix in software.

• You can protect your own infrastructure against these attacks.

On-site request forgery

Request forgery is a familiar attack payload for exploiting stored XSS vulnerabilities. In the MySpace worm, Samy placed a script within his profile which caused any user viewing the profile to perform various unwitting actions, including adding Samy as a friend and copying his script into their own profile. In many XSS scenarios, when you simply wish to perform a particular action with different privileges, on-site request forgery is easier and more reliable than attempting to hijack a victim’s session.

What is less well appreciated is that stored on-site request forgery bugs can exist when XSS is not possible. Consider a message board application which lets users submit items that are viewed by other users. Messages are submitted using a request like the following:

POST /submit.php
Content-Length: 34

type=question&name=daf&message=foo

which results in the following being added to the messages page:

<tr>
  <td><img src="/images/question.gif"></td>
  <td>daf</td>
  <td>foo</td>
</tr>

In this situation, you would of course test for XSS. However, it turns out that the application is properly HTML-encoding any " < and > characters which it inserts into the page. Having satisfied yourself that this defence cannot be bypassed in any way, you might move on to the next test.

But look again. We control part of the target of the <img> tag. Although we can’t break out of the quoted string, we can modify the URL to cause any user who views our message to make an arbitrary on-site GET request. For example, submitting the following value in the type parameter will cause anyone viewing our message to make a request which attempts to add a new administrative user:

../admin/newUser.php?username=daf2&password=0wned &role=admin#

When an ordinary user is induced to issue our crafted request, it will of course fail. But when an administrator views our message, our backdoor account gets created. We have performed a successful on-site request forgery attack even though XSS is not possible. And of course, the attack will succeed even if administrators take the precaution of disabling JavaScript.

(In the above attack string, note the # character which effectively terminates the URL before the .gif suffix. We could just as easily use & to incorporate the suffix as a further request parameter.)