Thursday, March 20, 2008

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:


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:


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=

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=

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.


ted said...

However, we don't know the table structor in their SQL server...

PortSwigger said...

@ted - Well, we may or may not know (or be able to deduce) the table structure in either case. But the point is that, other things being equal, the XSRF vector applies to both vulnerablities, and so they should be assigned the same threat rating.

kuza55 said...

If we know enough about the application to try and conduct a csrf-based sql injection attack, I'm sure we know the table structure; but if we don't (or we're trying to exploit the application only to see data for a proprietary app or something since a generic xp_cmdshell or similar approach won't work) we can always leverage the sql injection to get us some xss and then use xsstunnel to tunnel our sql injection attaempts over an xss channel/

pazi said...

hi all,

i wanna ask something related with XSRF.With using php-curl or java we may auto submit a form to another domain(XSRF site) when victim come my site .. however i am not sure we can set referrer header on this request if we can then referrer control may useless...

PortSwigger said...

@pazi - Historically, ways have existed of spoofing or masking the Referer header, and it is likely that further ways will be discovered in future. In general, the Referer header is not a reliable foundation on which to build any security defences within web applications.

pazi said...

yes right, then referrer check in XSRF may bypass in POST method, actually i will try to simulated in some the way your book was really a master piece in web application thanks for that..

Jim said...

One further problem with "Referer" validation is that there are cases where both admin and non-admin users are accessing the same web app. If an attacker can gain a non-admin account, and inject the appropriate code into a page on the web app, "Referer" validation could be seriously compromised (if not defeated outright).

There are popular web content management systems out there with this kind of vulnerability - all it takes is inserting an appropriate blog post/blog comment/wiki entry with a carefully crafted <img> tag to break it. Given that right under the text box where I'm writing this I see the message "You can use some HTML tags", I'm guessing may also be vulnerable...