4

I need to add CSRF protection to a web application.

Problem is in the fact that the app relies heavily on links (GET requests that is) to make changes in the database.

Links are generated using a class, so I could easily add an extra parameter for CSRF token to each link.

However, I understand that CSRF token in a GET request might not be a good enough protection.

Note that app is only available over HTTPS, so GET params can not be exposed/stolen during client/server communication (but history stealing issue remains).

Could GET CSRF token param be considered "safe enough" in this setting?

If not, what is the best way to solve this problem? Only thing that comes to my mind is to wrap each of my links into a form (ether explicitly, or creating form onSubmit using JavaScript).

h9lpq0u
  • 225
  • 3
  • 5

1 Answers1

4

To be able to read the response to a CSRF attack’s request, an attacker would need to get the victim to execute his JavaScript code. So, CSRF for a "GET" request is almost not useful. This is assuming you have followed the standards that "GET" requests should not modify any data and any modifications need to be done only using "POST"

  1. Using cookie based authentication and SSL should keep you away from a guy who is trying to change the parameters
  2. You may want to introduce some signing based on timestamp to avoid replay attacks

That said, if you have any POST requests, you should consider the CSRF protection.

ddb
  • 1,416
  • 11
  • 17
  • 5
    GET requests *are* used to modify data, that is the point of my question. Refactoring to stop using GET requests for data modification is not an option, so my question is whether GET + csrf token + https is "safe enough", or should I (and how exactly) change GET requests to POST requests "on the fly". – h9lpq0u Sep 12 '12 at 13:32
  • It may be ok until you refactor to have that level of protection. But it is not completely secure. You see, the csrf token found in cookie can be pulled out using javascript code and that could be used for wrong execution from within the user's session. I am not 100% confident about this..But check these two links to decide - http://stackoverflow.com/questions/2769992/replay-attacks-for-https-requests and https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL. I dont know of any way of converting GET to POST "on the fly". – ddb Sep 13 '12 at 05:11
  • Thanks for your comment. About converting GET to POST, since I use class Link to create links, so I can on one place change format of all links. Two approaches come to my mind. For example, I could add onclick javascript code that dinamically create form, add all params from GET link, and submit the form. Or I could wrap link in a form element, add hidden params and change link behaviour so that it just submits that form. – h9lpq0u Sep 13 '12 at 14:06
  • @ddb I have thought about the issue of the CSRF token being read by JavaScript, and came to the realization that it should not be a concern to CSRF as having JavaScript reading the cookie is actually a separate XSS problem. Not to say ignore the issue of XSS, but that it's actually two problems you need to solve. – Matthew Mar 14 '14 at 18:34
  • @ddb You can set a cookie that it is not possible for javascript to read it (the browser prevents it, most modern do). But your link to owasp pretty much sums up the possible downsides; the token ends up in the browser history and such, it's just something you should prevent -- but like it also says; if there is no easy way to do so, go ahead. – Arie Jul 23 '14 at 15:45