What is the best practice to protect GET request against CSRF attacks?

[Torsten Irländer]

Hi,

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.

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?

While writing this I am wondering if it would be possible (maybe it is already i did not have tried it) if the route methods can automatically add the current csrf token to the URL in case the related view has set the check_csrf parameter.

[0]  https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL

Torsten

[Bert JW Regeer]

On Jul 2, 2014, at 7:29, Torsten Irländer <tor...@irlaender.de> wrote:

> Hi,
>
> 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. GET requests are (SHOULD be) idempotent and don’t allow an attacker to insert data into your site, nor modify data.

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.

>
> 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.

>
> While writing this I am wondering if it would be possible (maybe it is already i did not have tried it) if the route methods can automatically add the current csrf token to the URL in case the related view has set the check_csrf parameter.
>
> [0] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL
>
> Torsten

Bert JW Regeer

[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 <tor...@irlaender.de> 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

[Cornelius Kölbel]

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 <tor...@irlaender.de> 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 pylons-discus...@googlegroups.com.
To post to this group, send email to pylons-...@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

[Randall Leeds]

On Wed, Jul 2, 2014 at 2:01 PM, Torsten Irländer <tor...@irlaender.de> 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 <tor...@irlaender.de> 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.

Even if it did, any request to the application would be cross domain unless the webmail is on the same domain.

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.

Of course, we could assume that Bob has crafted a special URL that doesn't require a session, but then we're assuming Bob has already executed an attack and we're reasoning in circles.

More common scenarios involve forms, which won't render or return a response to the attacker on GET but could cause side effects on POST.

[Bert JW Regeer]

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

[Torsten Irländer]

Am Donnerstag, 3. Juli 2014 00:32:15 UTC+2 schrieb cornelius:

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 <tor...@irlaender.de> wrote:

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)

That's the point. If those addresses are not public and considered to be only visible to authenticated users, than such a GET request is a large security issue ( if such a request is realistic at all )

Nevertheless I absolutely recommend to also protect GET requests against CSRF!

Ok, and how would you do it in pyramid?

Torsten

[Bert JW Regeer]

With the current cross domain policies that browsers have, how is an attacker going to read the data when they issue a GET request? There is no way for an attacker to currently read data from an external site unless you go out of your way to make it possible (such as CORS/JSONP).

If an attacker IS ABLE to somehow read content from your website by having someone issue a GET request, they can also an issue an GET request for http://example.com/, which will include links in the HTML to those pages that would include the CSRF token:

http://example.com/ links to http://example.com/some/super/duper/secret/address?csrf_token=79dDe4F627882c9E

So if this is an actual thread model, you can’t provide any links at all from your main page when a user is logged in, unless they manually concatenate the csrf_token to the URL (but where are they getting it at that point?)

There is no reason to add a CSRF token to GET requests. POST, yes, DELETE, no, PUT, no, OPTIONS, no, GET, no, HEAD, no, TRACE, no. POST is the only HTTP verb that can be sent from current browsers with abandon, there are no restrictions from either JavaScript or from within a page itself. You can POST all over the world. The way to stop that is to add a CSRF token to your forms so only forms your server has generated are actually acted upon when receiving a POST.

Bert JW Regeer

[Torsten Irländer]

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 <tor...@irlaender.de> 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 <tor...@irlaender.de> 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

[Bert JW Regeer]

On Jul 3, 2014, at 00:57 , Torsten Irländer <tor...@irlaender.de> wrote:

> 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 with JS code in an HTML mail within a browser, cross domain policies are still enforced.

>
> 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?

I would recommend reading up on cross domain policies, it is going to be a lot more helpful than you trying to guess what is going to happen when someone receives an email. There are very specific requirements that have to be met for a cross domain GET request to fetch data and allow the page it is being loaded into to use said data.

>
> Ok, that seems to be clear.
>

Cool.

> Torsten

Bert

[Torsten Irländer]

Thanks Bert for your clarification. I will stick my head into the cross domain policy documentation for a while.

Torsten

[Cornelius Kölbel]

Hi Torsten,
i am not sure, if I would rely my web application security completely on the client/browser side.
I think your example with the email was a bit to complicated.
The much simpler and thus better example is directly at wikipedia:
    https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

And it is not necessarily important to read any action but to trigger an event.
Imagine your companies web application to configure the firewall.
You could easily "guess" the URL to disable the You**** blocking and make your administrator click this URL.
If you are lucky and the administrator is logged in in the bad firewall UI and he clicks the image/link - bingo.

OWASP recommends using a token in addition to the cookie, that is verified on the server side.
Thus you (the attacker) are not able to construct the link with the token, which you can not guess.

I did it in pylons once using repoze.who, which issued an authenticating token.
@Bert: admitted, maybe there were many unlucky side effect, but CSRF was possible in this case.

As I did not wanted to keep track on synchronizer tokens on the server side, the original web application read the session cookie from the browser and added the this token as parameter for the further requests. Thus the server only needs to compare the cookie and the parameter.
Admitted again: At this point I rely on that a rogue website is not able to access the cookies from my web application. But I assume this to be robust.

Kind regards
Cornelius

[Bert JW Regeer]

On Jul 3, 2014, at 02:48 , Cornelius Kölbel <corneliu...@netknights.it> wrote:

>
> Am 03.07.2014 08:43, schrieb Torsten Irländer:
>>
>>
>> Am Donnerstag, 3. Juli 2014 00:32:15 UTC+2 schrieb cornelius:
>> 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 <tor...@irlaender.de> wrote:
>>>
>> 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)
>>
>> That's the point. If those addresses are not public and considered to be only visible to authenticated users, than such a GET request is a large security issue ( if such a request is realistic at all )
>>
>>
>> Nevertheless I absolutely recommend to also protect GET requests against CSRF!
>>
>> Ok, and how would you do it in pyramid?
>>
>> Torsten
> Hi Torsten,
> i am not sure, if I would rely my web application security completely on the client/browser side.
> I think your example with the email was a bit to complicated.
> The much simpler and thus better example is directly at wikipedia:
> https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics
>
> And it is not necessarily important to read any action but to trigger an event.
> Imagine your companies web application to configure the firewall.
> You could easily "guess" the URL to disable the You**** blocking and make your administrator click this URL.
> If you are lucky and the administrator is logged in in the bad firewall UI and he clicks the image/link - bingo.

If your GET requests are not idempotent (i.e. They will always return the exact same response, and don’t modify any state) there is no cross site request forgery that can happen.

[Torsten Irländer]

Am Donnerstag, 3. Juli 2014 10:48:24 UTC+2 schrieb cornelius:

Am 03.07.2014 08:43, schrieb Torsten Irländer:

Am Donnerstag, 3. Juli 2014 00:32:15 UTC+2 schrieb cornelius:

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 <tor...@irlaender.de> wrote:

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)

That's the point. If those addresses are not public and considered to be only visible to authenticated users, than such a GET request is a large security issue ( if such a request is realistic at all )

Nevertheless I absolutely recommend to also protect GET requests against CSRF!

Ok, and how would you do it in pyramid?

Torsten

Hi Cornelius,

Hi Torsten,
i am not sure, if I would rely my web application security completely on the client/browser side.
I think your example with the email was a bit to complicated.
The much simpler and thus better example is directly at wikipedia:
    https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

And it is not necessarily important to read any action but to trigger an event.
Imagine your companies web application to configure the firewall.
You could easily "guess" the URL to disable the You**** blocking and make your administrator click this URL.
If you are lucky and the administrator is logged in in the bad firewall UI and he clicks the image/link - bingo.

Thanks for pointing me to this example. But this example only works because the webapplication does not follow RFC 2616 and implements a sensitive action in a GET request. My example attack was aimed to send the result of a GET request to Bob. I think this is only possible by using JS, which is, if I understand Bert correct, impossible because of the cross domain policy of the browser.

OWASP recommends using a token in addition to the cookie, that is verified on the server side.
Thus you (the attacker) are not able to construct the link with the token, which you can not guess.

I did it in pylons once using repoze.who, which issued an authenticating token.
@Bert: admitted, maybe there were many unlucky side effect, but CSRF was possible in this case.

As I did not wanted to keep track on synchronizer tokens on the server side, the original web application read the session cookie from the browser and added the this token as parameter for the further requests. Thus the server only needs to compare the cookie and the parameter.

Ok, and how did you add this token as parameter the further requests? Did you enhance the url generation in Pyramid?

Admitted again: At this point I rely on that a rogue website is not able to access the cookies from my web application. But I assume this to be robust.

Torsten

[Cornelius Kölbel]

Am 04.07.2014 10:21, schrieb Torsten Irländer:

As I did not wanted to keep track on synchronizer tokens on the server side, the original web application read the session cookie from the browser and added the this token as parameter for the further requests. Thus the server only needs to compare the cookie and the parameter.

Ok, and how did you add this token as parameter the further requests? Did you enhance the url generation in Pyramid?

Hi Torsten,

this might all be rather unorthodox: This was handled by javascript stuff, that reads the cookie. My web application had a bunch of javascript!
Of course this would not work in a web application, that does not use javascript.
Then you might need to track the synchronizer token on the server side... (see https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#General_Recommendation:_Synchronizer_Token_Pattern)

Hm, my solution is really an old, expanded web app, that needs some code cleaning ;-)

Kind regards
Cornelius

[Torsten Irländer]

 
Hi Cornelius,

Thanks for the reply. JS might be an option for me as my application requires JS to work properly anyway. However I would like to implement this at the time of the URL generation on the server side. Maybe I will try my first idea using some kind of wrapper around pyramids url generation methods... if i finally decide to implement CSRF protection on GET request :)
 

[Torsten Irländer]

Am Donnerstag, 3. Juli 2014 15:30:09 UTC+2 schrieb Bert JW Regeer:

 
Hello Bert,

If your GET requests are not idempotent (i.e. They will always return the exact same response, and don’t modify any state) there is no cross site request forgery that can happen.

I think you mean if the GET requests _are_ idempotent.
After talking about this with some other people I understand the fact that idempotent GET request are not vulnerable for CSRF attacks in general. But there are some corner cases (I am sure there are more):

1. Bob knows a combination of GET params in the request which causes Alice application to crash.
2. Bob knows that a certain GET triggers some expensive calculation. This could be used for a DOS attack.

Of course, someone can argue that those problems are not CSRF related as 1 exists because of  missing input validation and that 2 can be seen as a sensitive method and should be put into a POST request instead. I can understand this and I am totally fine with it. But this is only true if people implements their software correct . The two examples above could be prevented by adding CSRF protection on GET requests at relative low costs.

I think the general conclusion that GET request are not vulnerable is only true under certain circumstances. And I as a implementer do not want to think about every GET request if it might get a threat in some situations or future scenarios. So I would welcome a solution in a webframework which offers me the option to add such CSRF protection in GET requests if I want it - regardless if it is really needed for the request.

Torsten

[Chris Rossi]

On Tue, Jul 8, 2014 at 2:27 AM, Torsten Irländer <tor...@irlaender.de> wrote:

I think the general conclusion that GET request are not vulnerable is only true under certain circumstances. And I as a implementer do not want to think about every GET request if it might get a threat in some situations or future scenarios. So I would welcome a solution in a webframework which offers me the option to add such CSRF protection in GET requests if I want it - regardless if it is really needed for the request.

There's no way to do that without breaking HTTP, basically.  Since there is no POST data, the only place you could add a CSRF token is in the URI itself.  Obviously, no one would be able to save a bookmark to such a page, or just navigate to it by knowing the URI.  Once you're adding random-ish data to the URI for this purpose, you've broken it's design as a resource identifier--it's not a universal identifier, it's a secret token.  If a GET request is modifying state in any meaningful way that needs protection, then it shouldn't be a GET request.  Not there's any technical hurdle to doing what you want, but you're fighting the basic concepts underlying HTTP at that point.  If you can get on board with using HTTP verbs for what they are designed for, there is a lot beautiful simplification that falls out.  Be a Zen programmer and go with the flow.  Make your GET requests idempotent and safe.  Protect your POST form submissions using a CSRF token.  Relax in the evening knowing you're probably not going to get attacked tonight, because you used good design.

Chris

[Torsten Irländer]

Am Dienstag, 8. Juli 2014 15:23:47 UTC+2 schrieb Chris Rossi:

On Tue, Jul 8, 2014 at 2:27 AM, Torsten Irländer <tor...@irlaender.de> wrote:

I think the general conclusion that GET request are not vulnerable is only true under certain circumstances. And I as a implementer do not want to think about every GET request if it might get a threat in some situations or future scenarios. So I would welcome a solution in a webframework which offers me the option to add such CSRF protection in GET requests if I want it - regardless if it is really needed for the request.

Hi Cris,
 

There's no way to do that without breaking HTTP, basically.  Since there is no POST data, the only place you could add a CSRF token is in the URI itself.  Obviously, no one would be able to save a bookmark to such a page, or just navigate to it by knowing the URI.  

Your are right and I was aware of this.  OWASP mentioned some other drawbacks of putting such a token into the GET requests [0]

Once you're adding random-ish data to the URI for this purpose, you've broken it's design as a resource identifier--it's not a universal identifier, it's a secret token.  

Right. Altough I prefer seeing it as an URI it can also be seen as a security feature if I do not want people to store deep links into the application in their bookmarks...
 

If a GET request is modifying state in any meaningful way that needs protection, then it shouldn't be a GET request.  

Correct, I totally agree. But this can become hard to consider in every corner case.

Not there's any technical hurdle to doing what you want, but you're fighting the basic concepts underlying HTTP at that point.  If you can get on board with using HTTP verbs for what they are designed for, there is a lot beautiful simplification that falls out. Be a Zen programmer and go with the flow.  Make your GET requests idempotent and safe.  Protect your POST form submissions using a CSRF token.  Relax in the evening knowing you're probably not going to get attacked tonight, because you used good design

I basically agree with you in this. But I think this needs some weighing up the risk and depends on the concrete use case. If the harm of an attack is large enough I can not sleep well  if i rely on the hope that everybody implements the things correct. Then I am maybe glad to have some extra protection. But in almost all cases I would tend to focus on a good design with idempotent and safe GET request instead of protecting them with all the drawbacks :)

Well, thanks to all of you who respond here. Even if the discussion was more about the question if protecting GET request is reasonable at all than about how would i do it, it was very enlightened :)

[0]  https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL

[Jonathan Vanasco]

If you have expensive calculations, you can just lock them down onto a POST page under HTTPS with a CSRF token.  That will eliminate most issues.

You can also segment expensive routes to run in their own application instance , and throttle users (based on session, ip, etc ) so that general server resources aren't impacted by overactivity in select routes.

There are a lot of popular application design approaches that will solve your issues, and are way more simple than trying to re-imagine the HTTP protocol.