Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I was reading this question about using Synchronizer Token Pattern to protect against CSRF and the comments of the answer intrigued me. Of course, as the last comment says, if your site has an XSS vulnerability, then CSRF is not your biggest concern. But what happens if the other site as a XSS vulnerability?

Let me set the stage.

  • fakebank.com = your bank which has a funds transfer page that requires you to use a unique token you get on a get page that must be included in a post. You are currently logged into it.
  • insecurefun.com = a site you are currently visiting. Has numerous issues, including XSS vulnerability.
  • malicioussite.com = a nasty site that you never want to visit, but it happens to have put up a few adds on insecurefun.com.

So you load up insecurefun.com and happen to get an add from malicioussite.com. The add redirects a get to fakebank.com using your session data, causing fakebank.com to send your browser the confirm transfer page which happens to include the unique token. Then, the add exploits the XSS vulnerability of insecurefun.com to run javascript to get the token and finally performs a post with, causing your bank to transfer funds.

Now, I'm pretty sure this can't work, because if the Synchronizer Token Pattern could be so easily exploited, it wouldn't be recommended as protection against CSRF attacks. But, what I don't get is why this cannot be exploited.

My only guess is that the malicious script cannot get a hold of the unique token to use it due to same domain policy. But if you do something like this, it seems the malicious script could launch the GET have have the HTML returned as a string, parse the data for the unique token, and then launch the POST without the user being informed. What am I missing that would prevent this from working?

share|improve this question
add comment

2 Answers

Then, the add exploits the XSS vulnerability of insecurefun.com to run javascript to get the token and finally performs a post with, causing your bank to transfer funds.

Nope. XSS vulnerabilities work the other way. If insecurefun.com has an XSS vulnerability, insecurefun.com (and all sites that have insecurefun.com in their Access-Control-Allow-Origin) are open to a CSRF attack. However, insecurefun.com's XSS vulnerability does not permit any attacker to touch fakebank.com.

An XSS vulnerability in a site means that that site is vulnerable to attack by a third party; not that code on that site has free rein on your browser. If fakebank.com had an XSS vulnerability, then there would be an issue. Otherwise not.

Think about it; if having an XSS vulnerability was all that was needed to run CSRFs, then attackers would be introducing intentional XSS vulnerabilities into their pages, enabling them to attack other sites.

share|improve this answer
    
My understanding of CSRFs is that you don't even need to have an XSS vulnerability. If I have a link <img src="www.fakebank.com?transfer=100&target=Lawtonfogle" /> and you are logged into fakebank and fakebank doesn't protect against CSRFs, every time you view that 'image', I get 100 richer. (Unless I misunderstand CSRFs.) –  Lawtonfogle Oct 8 '13 at 19:49
    
@Lawtonfogle I'm assuming the site has implemented CSRF tokens as mentioned in the question. –  Manishearth Oct 8 '13 at 19:55
add comment

The add redirects a get to fakebank.com using your session data, causing fakebank.com to send your browser the confirm transfer page which happens to include the unique token.

This cannot happen if fakebank.com is using a CSRF token correctly.

A CSRF attack is basically just making a request to a target site from a malicious site. The purpose of the CSRF token is to require that all requests made to the site include this secret token. The malicious site has no way of knowing what this token is as long as the CSRF protection is setup correctly.

So without a CSRF token required a request could just do a post with the "transfer to account" and the amount. When a CSRF token is required the request must also include a CSRF token that a malicious site will not know.

I tried the method described in the link you provided and it doesn't seem to work against a properly configured site.

If you were in fact able to pull the page of an authenticated user from a domain you do not control (as the link is suggesting) and that page contained the CSRF token, then yes, you could bypass the protection provided by a CSRF token.

If fakebank.com has an XSS vulnerability then all bets are off.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.