I have a site which will show sensitive information. I am using Anti Forgery Tokens etc to protect against XSRF in POSTS. However I am worried about someone being able to view sensitive info from a GET. What is the recommended practice for protecting read only data sent via a GET in .Net MVC 2?
A:
The XSRF protection on POST data (using tokens like you said) should work on GET data as well. From a hacker's point of view a GET forgery is much easier than POST forgery (at the first you only post a link, at the second you need to point to a malware website with hidden iframe and autosubmit forms), but both of them fail if tokens are checked.
Example: posting a link like this:
www.domain.tld/page.aspx?get=data&token=token_given_to_hacker
shouldn't return anything, or just an error for those who got other tokens. This way no sensitive action is made for the wrong people.
This is xsrf, with this you can't steal information, but make others submit forms and take action which result only the hackers know. For example: Changing email, on an email form, to the email of the hacker. Let's assume you have a GET form, with 1 field: the new email (for the sake of simplicity). When submitted the URL looks like this:
www.domain.tld/[email protected]
Now, if a hacker posts a link on your forum with the URL:
www.domain.tld/[email protected]
Everyone who clicks on it, will get a new email, of the hackers. But if you put a token there, and you'll check it every time, the action will be taken only for those who's the same token was given on page request, in this case the link will work only for the user who posted it, and no one else.
You could also protect sensitive forms, like changing email, password and so on with a password field. Note, that captcha is not much of a help here.
SinistraD
2010-09-13 14:51:45
+1
A:
If you are sure that GET requests are read-only, then you have nothing to worry from XSRF. Its not possible to steal information from another website using just XSRF, and so you don't need to protect urls via a token. In fact, using tokens in the URL is going to make it impossible to use bookmarks.
Having said that, you should be 100% sure there are no XSS vulnerabilities in your app. If there are, an attacker doesn't need to bother with XSRF and unpredictable tokens.
sri
2010-09-13 15:24:17
sensitive form submits should be impossible to bookmark
SinistraD
2010-09-13 16:46:52
If its a form submit that modifies data, then it ought to be a POST, followed by a redirect to a GET url. If its a form submit that only acts as a sort of a filter, it can still be a GET, and there is no reason to sacrifice bookmarkable urls.
sri
2010-09-13 16:55:02
I am worried about the following scenario. Another site is vunerable to XSS (or is a malicious site accessed via social engineering). A user is logged into my site and goes to the malicious site, this makes a javascript GET request to eg accounts/Index and now has a copy of the list of accounts which he can invisibly post back to another web server.
Matthew Hood
2010-09-14 07:32:53
The attacker can always make a GET request from his site, but he **cannot** read the response thanks to browsers Same Origin Policy. This holds true no matter what client technology he uses - XmlHttpRequest, Form tag, Flash, Silverlight,or any of the several other ways to make a GET request. Unless you are building a banking application, you don't need to do anything for GET requests that are side-effect-free.
sri
2010-09-14 07:53:21
Thanks for clearing this up, will do more reading on Same Origin Policy. Seem to be panicking for nothing :D
Matthew Hood
2010-09-14 08:23:55