On Jul 2, 2014, at 15:01 , Torsten Irländer <[email protected]> wrote:
> > > 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]> 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? > > > > > 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 The above scenario is not realistic, lets drop the email aspect of it since most email clients won’t let you execute code in the first place, and assume I can get Alice to visit a page that I have specially crafted. The worst I can do is load the content into an iframe, however I can’t read/modify or anything inside that iframe/frame (disallow iframe entirely by setting some headers if you’d prefer) because of browser cross domain policies. Even if I have JavaScript on my page, I can’t access into the iframe. Even if I were to load the page directly using JavaScript with an XHR request for example, browser cross domain policies disallow sending of cookies unless the domain I am currently on is whitelisted using CORS. There is no way unless the browser is severely broken (in which case why can’t Bob go to the main page, and walk all the links he finds in your main page, considering they will all contain the CSRF token in <a href=“{…}”> and steal all the content anyway) for Bob to retrieve data from your website in an attack using GET. The reason you protect POST is because if you can trick someone into visiting your site stuff can be done automatically (like spamming). Bert JW Regeer
smime.p7s
Description: S/MIME cryptographic signature
