3 ms·

[ repost from below ] I just read on CSRF and its mitigation with Synchronized Tokens on [1] and there's one thing I don't seem to understand. What does preven

[ repost from below ] I just read on CSRF and its mitigation with Synchronized Tokens on [1] and there's one thing I don't seem to understand. What does prevent an attacker from open an original site's page in an iframe and then have a script fill in and submit the form on it? In other words, say I am logged in into my bank's site. I then open a malicious page that has an iframe pointing at http://bank/move-funds http://bank/move-funds that contains a fund transfer form. Wouldn't this page include a correct CSRFToken, making the form readily submittable by a malicious script? Can anyone comment? It damn sure looks like a big gaping hole that is virtually impossible to plug. [1] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%...

nbpoole 15y ago
Because a script (I assume you're referring to JavaScript) can't fill in a form on or read the contents of a third-party website. That's a violation of the same-origin policy. CSRF tokens are a well-understood solution to this issue. In order to submit a valid request, you must include what is essentially a secret token that is on the page (although the secret token can just be your session ID). For an attacker to get that token, they would need to be able to do at least one of the following: A. Guess it, by having you make multiple requests. (so you make the token long enough that it's infeasible to guess) B. Be able to read it by intercepting the HTTP response or reading it in some way, in which case you have much larger security issues. C. Be able to read the token in the HTTP request that the browser makes. Again, if an attacker can do this, your session is already compromised.
- huhtenberg 15y ago
  Right, the same-origin policy, thanks. Just found it after a minute of jsfiddling. Now, let's say my script is not loading bank's page into an iframe, but rather fetches it with an ajax call. Wouldn't that page (again) include a valid CSRF token? Or is this mitigated by checking a referrer on the bank's side?
  - nbpoole 15y ago
    You can make but CAN NOT view the result of a cross-domain request via XMLHttpRequest unless the site specifically opts in to it. Same-origin policy again.
shimon 15y ago
Doesn't work, because of cross-domain security policies. Javascript running in http://malicious-site http://malicious-site wouldn't be able to read the CSRF protection token in the fund transfer form on http://bank http://bank. So the submission wouldn't have the correct token value and the bank would reject the attempt.
deleted 15y ago
[deleted]

nbpoole 15y ago

Because a script (I assume you're referring to JavaScript) can't fill in a form on or read the contents of a third-party website. That's a violation of the same-origin policy. CSRF tokens are a well-understood solution to this issue. In order to submit a valid request, you must include what is essentially a secret token that is on the page (although the secret token can just be your session ID). For an attacker to get that token, they would need to be able to do at least one of the following: A. Guess it, by having you make multiple requests. (so you make the token long enough that it's infeasible to guess) B. Be able to read it by intercepting the HTTP response or reading it in some way, in which case you have much larger security issues. C. Be able to read the token in the HTTP request that the browser makes. Again, if an attacker can do this, your session is already compromised.

huhtenberg 15y ago
Right, the same-origin policy, thanks. Just found it after a minute of jsfiddling. Now, let's say my script is not loading bank's page into an iframe, but rather fetches it with an ajax call. Wouldn't that page (again) include a valid CSRF token? Or is this mitigated by checking a referrer on the bank's side?
- nbpoole 15y ago
  You can make but CAN NOT view the result of a cross-domain request via XMLHttpRequest unless the site specifically opts in to it. Same-origin policy again.

shimon 15y ago

Doesn't work, because of cross-domain security policies. Javascript running in http://malicious-site http://malicious-site wouldn't be able to read the CSRF protection token in the fund transfer form on http://bank http://bank. So the submission wouldn't have the correct token value and the bank would reject the attempt.

deleted 15y ago

[deleted]