A server can't discern between a request coming from a user's deliberate action (such as clicking submit) or from a browser request not stemming from a user's action (loading an image). Also, any cookie associated with a site is sent with a request, regardless of a user's action.
Exploit:
For example let's take Gmail as an example. Say Gmail has a button on its website that deletes your account when clicked. If the url for the delete button is:
https://mail.google.com/deleteaccount.do?accountId=ACCOUNTID
A clever attacker can take advantage of this fact by embedding a piece of code in an arbitrary website (www.malicious-website.com) that contains the url of Gmail's delete button.
<img src="https://mail.google.com/deleteaccount.do?accountId=ACCOUNTID">
When you access the malicious website, your Gmail account will be deleted without your knowledge and without you having any idea what happened. You do not need to log in to Gmail for this to happen because the cookie associated with your Gmail login is automatically passed on to and validated by the server.
Fix:
One common misconception is using POST instead of GET requests will alleviate the threat of CSRF. According to OWASP, there are still ways for hackers to trick a victim into submitting a forged POST request.
One surefire way to eliminate the threat of CSRF is to use tokens in the following manner:
- Generate a new CSRF token on user login, and add it to the current http session.
- On any form that need be protected add a parameter/hidden field that calls for the token.
- On the server side check that the token is from the current session and is legitimate.
- On logout and session timeout delete the CSRF token from the current http session.
Source:
http://www.jtmelton.com/2010/05/16/the-owasp-top-ten-and-esapi-part-6-cross-site-request-forgery-csrf/
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
http://google-gruyere.appspot.com/part3#3__cross_site_request_forgery
No comments:
Post a Comment