Am Donnerstag, 3. Juli 2014 01:15:41 UTC+2 schrieb Randall Leeds: > > On Wed, Jul 2, 2014 at 2:01 PM, Torsten Irländer <[email protected] > <javascript:>> 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? >> > > I don't think it's a common one. > > The webmail would have to execute scripts inside the email. That seems > problematic to start. >
Hmm... I was thinking of a simple HTML mail with some JS code which gets executed in Alice browser when opening the Mail. Is this problematic to start because the webmailer hopefully escapes and strips such malicious code? > > Even if it did, any request to the application would be cross domain > unless the webmail is on the same domain. > Is it? The request is triggered in Alice browser window when opening the email. Maybe I need to read more about the cross domain policy? That means that, unless you explicitly set CORS headers, that request won't > include cookies. So, there's no session available through which to receive > private data. > Ok, that seems to be clear. 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]. 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.
