On Jul 3, 2014, at 02:48 , Cornelius Kölbel <cornelius.koel...@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. > > 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 pylons-discuss+unsubscr...@googlegroups.com. >> To post to this group, send email to pylons-discuss@googlegroups.com. >> 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 pylons-discuss+unsubscr...@googlegroups.com. > To post to this group, send email to pylons-discuss@googlegroups.com. > Visit this group at http://groups.google.com/group/pylons-discuss. > For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME cryptographic signature
