On Tue, Jul 8, 2014 at 2:27 AM, Torsten Irländer <[email protected]> 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. > > 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. 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. If a GET request is modifying state in any meaningful way that needs protection, then it shouldn't be a GET request. 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. Chris -- 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.
