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