Am 02.07.2014 23:01, schrieb Torsten Irländer: > > > Am Mittwoch, 2. Juli 2014 17:00:02 UTC+2 schrieb Bert JW Regeer: > > > On Jul 2, 2014, at 7:29, Torsten Irländer <[email protected] > <javascript:>> wrote: > > > I need to protect some of my GET requests in the application > against CSRF attacks. > > AFAIKS many (if not all) resources writing about CSRF protection > say that this is usually only need to be done for POST requests > which will change data or the state of the application. However I > feel the need to protect some GET requests because they return > sensitive information which must be prevented because of e.g data > privacy. I think i need to provide the token within the GET > parameters of the request. I am using per request CSRF-Tokens, so > the issue of disclosure the tokens in the URL as described on > OWASP [0] should be not a big deal. > > The reason you use CSRF tokens is to protect a web form from being > submitted from a 3rd party site, and thus invalid data being > inserted into your site, since JavaScript can make POST requests, > this is generally a good idea to stop a web spammer from spamming > your site with invalid data or spam. > > > I think this is totally clear to me. > > > GET requests are (SHOULD be) idempotent and don’t allow an > attacker to insert data into your site, nor modify data. > > > Well but inserting or modifying data is only one option for an > attacker. In many cases retrieving data is much more valuable for an > attacker. This is the reason why I thought I should also prevent > CSRF-Attacks on GET requests... > > > > Even if you were to use CSRF tokens, it wouldn’t add any extra > protection to your site. You should be checking permission for the > current logged in user, setting appropriate cache values and > everything along those lines before you return the page to the > user, if the user doesn’t have access because of permissions, > don’t display the data. > > > I suppose you are right, but I don't get it... Maybe someone could > explain it to me. > > Imagine the following scenario: > > Alice has access to web application with super secret data. The > application is secure, permissions are checked properly etc. Alice is > allowed to read the secret data. > Now Bob sends Alice a malicious Email with some XSS Code included. > This code calls a URL which retrieves the super secret data in the > application and sends this data back to Bob. > Alice usually reads her Mail in a webmailer in the same browser where > she already has logged in in the application. She opens Bobs Mail and > triggers the execution of the malicious code. > > Isn't this a realistic CSRF attack? Hi to my knowledge a CSRF would trigger a valid request and not execute new, malicious code. I.e. image a web application where you can handle your contact addresses. This web application could have a web call, that deletes all your contacts. You usually would not call this. But if you get a forged mail or a forged web site with this hidden request, your browser - when logged in to the web application - would trigger this request and the data would be deleted without your knowledge. bummer.
Now POST and GET. I guess that most people only talk about protecting post request since they _think_ that the web application would be programmed this way, that all actions (like deleting all contacts) would only be accessable via a POST request. So they THINK there is no need in protecting GET requests. But I know web applications that also change data via GET requests. Buttriggering a GET request that only _reads_ your addresses, would display the addresses and not change them. (Well, Maybe some code can also steal the addresses) Nevertheless I absolutely recommend to also protect GET requests against CSRF! Kind regards Cornelius > > > > > Now I am thinking about the best way to do this in pyramid. > > > > Currently i am thinking about implementing the following simple > idea: > > > > 1. Write a wrapper method for the various "route" methods in > pyramid.request which adds the current csrf token to the GET > parameters. > > 2. Check the token by providing the check_csrf parameter to the > add_view methood. > > > > Do you think this is a good approach, or what would be your advice? > > I don’t think adding CSRF tokens to a GET request makes sense from > a security stand-point. > > > If the scenario above is realistic, I see the absolute need for adding > them. > But again: As almost everyone is only talking about POST requests in > connection with CSRF I think its me who is missing some important > point here. > > But a really like to understand this. So please bring some light in here > > Torsten > -- > You received this message because you are subscribed to the Google > Groups "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at http://groups.google.com/group/pylons-discuss. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/d/optout.
