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