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 >> <[email protected]> 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. 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 > -- > 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.
