This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Talk:Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet"
(→Is this statement really correct?) |
David Ohsie (talk | contribs) |
||
| Line 12: | Line 12: | ||
Jim July 27, 2014: What about "''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker would be unable to modify or read the value stored in the cookie other than via cross site scripting. (And cross site scripting resistance is a requirement for good CSRF defense to begin with." | Jim July 27, 2014: What about "''This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker would be unable to modify or read the value stored in the cookie other than via cross site scripting. (And cross site scripting resistance is a requirement for good CSRF defense to begin with." | ||
| + | |||
| + | --[[User:David Ohsie|David Ohsie]] ([[User talk:David Ohsie|talk]]) 09:47, 30 July 2014 (CDT) I don't think that this is 100% accurate either. Cookies can be written via CSS in a sibling domain, so that even if the application in not vulnerable to CSS, if the sibling domain application is vulnerable to CSS, or is simply not trustworthy, cookies can be written. Cookies can also be written via MITM attacks on http. So the application in question can be completely "secure", but it's cookies can be tampered with anyhow. That is why the paper referenced above suggests that the CSRF token must in some way be tied to the user's session or identity and the "naive" double submit method is vulnerable. At the very least, with naive double submit, the application should check to make sure that there is only one CSRF token cookie value as this will mitigate some attempts to write the cookie from another domain. | ||
Revision as of 14:47, 30 July 2014
Don't post theoretical attacks, or "here say" on any OWASP page.
If you edit this page, please provide a rational. If you make a mindless edit without rationalization, it maybe reverted.
A referer check is a valid form of protection and is currently being used to stop the most dangerous CSRF vulnerability ever discovered (according to the DHS: http://www.kb.cert.org/vuls/id/643049). If you think it be exploited, PROVE IT. Stop spreading clearly false information on OWASP.
Is this statement really correct?
This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie.
This seems incorrect. An attacker can modify cookies from a sibling domain. See https://media.blackhat.com/eu-13/briefings/Lundeen/bh-eu-13-deputies-still-confused-lundeen-wp.pdf for examples. Thus double-submit csrf cookie should also be checked for some tie to the logged in session so that it can't just be pushed in.
Jim July 27, 2014: What about "This means that while an attacker can send any value he wants with a malicious CSRF request, the attacker would be unable to modify or read the value stored in the cookie other than via cross site scripting. (And cross site scripting resistance is a requirement for good CSRF defense to begin with."
--David Ohsie (talk) 09:47, 30 July 2014 (CDT) I don't think that this is 100% accurate either. Cookies can be written via CSS in a sibling domain, so that even if the application in not vulnerable to CSS, if the sibling domain application is vulnerable to CSS, or is simply not trustworthy, cookies can be written. Cookies can also be written via MITM attacks on http. So the application in question can be completely "secure", but it's cookies can be tampered with anyhow. That is why the paper referenced above suggests that the CSRF token must in some way be tied to the user's session or identity and the "naive" double submit method is vulnerable. At the very least, with naive double submit, the application should check to make sure that there is only one CSRF token cookie value as this will mitigate some attempts to write the cookie from another domain.
