6

I've been implementing ASP ARF tokens in my MVC3 web application and read into the workings of the CSRF exploit and how ARF tokens defend against it. Now I was wondering if 'hackers' couldn't bypass the ARF check by using an extra step. The normal CSRF scenario is like:

  1. Create a site (we call it HackerSite) that posts to the target website BankingSite
  2. Use social engineering (or XSS in ads etc.) so that a user will visit site HackerSite
  3. A script on HackerSite will post to the BankingSite using the users cookies/credentials thus posting under his/her name

Because of our ARF token, the BankingSite knows to ignore the POST coming from site HackerSite. Because it's missing the right AFR token. Could anyone tell me why the hacker couldn't just get the token by doing a GET request first on the BankingSite? Like this:

  1. Create a site (we call it HackerSite) that posts to the target website BankingSite
  2. Use social engineering (or XSS in ads etc.) so that a user will visit site HackerSite
  3. A script on HackerSite will do a GET request and grabs the ARF token from the HTML in the response, this request will also set the ARF token in the user's cookie
  4. A second script on HackerSite will post to the BankingSite using the grabbed ARF token + the users cookies/credentials thus posting under his/her name

Does anyone know what I'm missing here, and how ARF is secured against such an attack?

Rob
  • 2,466
  • 3
  • 22
  • 40
  • 3
    I think that this link explain well the issue and the solution http://www.asp.net/web-api/overview/security/preventing-cross-site-request-forgery-(csrf)-attacks Point to `Anti-forgery tokens work because the malicious page cannot read the user’s tokens, due to same-origin policies. ` – Aristos Sep 24 '14 at 09:59
  • AFAIK same origin protects the cookie from being read/manipulated by javascript + protects against IFrames. In my example I made the assumption that a hacker can easily do cross site ajax requests (by using JSONP for example). I think I might be wrong there thus making this attack method invalid. Can anyone verify that you can't possibly do cross site request ajax requests (without the users browser being compromised). – Rob Sep 24 '14 at 10:21
  • Please show us how a script on HackerSite.com can get HTML from BankingSite.com in a user's browser – Neil McGuigan Mar 12 '15 at 23:44

2 Answers2

1

Attacker doesn't know cookies of victim. Token generating based on it. If your site has another XSS's holes, this method can't help from CSRF vulnerability.

If you send AJAX referer header would be HackerSite, not BankSite. So you haven't access to closed part of site (can't access to CSRF Token). It's Http-Only so you can't just take it by javascript. Your plan will fail on part when you want to send get request to victim site.

devheart
  • 92
  • 4
  • 1
    If I understand CSRF right, then the hacker doesn't have to know to cookies of the victim, right? By doing a GET request the ARF token will be set into the users cookies and when doing the POST request to the bankingsite, the user's cookies used (thus the right ARF token cookie is being sent) – Rob Sep 24 '14 at 09:38
  • Auth cookie is HttpOnly. It can't pass by javascript; – devheart Sep 24 '14 at 10:19
  • 2
    When doing a request (normal or via AJAX) all cookies are automaticly passed, HttpOnly or not. – Rob Sep 24 '14 at 10:22
  • 1
    If you send AJAX referer header would be HackerSite, not BankSite. So you haven't access to closed part of site (can't access to CSRF Token). It's Http-Only so you can't just take it by javascript. Your plan will fail on part when you want to send get request to victim site. – devheart Sep 24 '14 at 10:58
  • You're right, I didn't know that :). For more info I found http://stackoverflow.com/a/5422323/755949 . Could you edit your original answer so with the details you gave in your last comment so I can accept it? – Rob Sep 24 '14 at 13:46
1

Good question. CORS prevents sending your credentials to the site they belong, from another site that you are visiting. So the GET request on your behalf fails.

Some details:

Sending credentials results in headers that are not on the safelist. see: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

So this triggers the browser to do a CORS preflight check (an OPTIONS request), on the site that the credentials belong to, before it sends the actual request.

The site receiving the OPTIONS request would have to respond with the headers:

  • Access-Control-Allow-Origin: containing the domain you are visiting
  • Access-Control-Allow-Credentials: set to true

Otherwise the browser won't send the request.

symbiont
  • 1,428
  • 3
  • 21
  • 27