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