Why not just set a custom cookie, and use that in the form instead of a session id? Seems a lot less hacky than browser fingerprints, and avoids sessions.
On Mar 14, 6:50 am, Aaron Swartz <[email protected]> wrote: > thedod added a cookbook page about CSRF to the > wiki:https://github.com/webpy/webpy.github.com/commit/33f34aedc82e040950ca... > > My feelings on this are: > > 1. If code blocks are generally useful, it should be in web.py and not > a cookbook page > 2. CSRF is generally useful -- web.py should have CSRF protection > 3. The right way to add CSRF to web.py is to write up a spec and run > it by me and a web security expert > > web.py's policy on security is generally "secure by default" but it'd > be extremely backwards-incompatible to start requiring CSRF on all > forms. I'm not sure what to do about this. One idea is to have a flag > on web.application that specifies CSRF or not and then have an opt-out > on...I guess web.input? And maybe eventually the flag could be made > default, after enough warning. Another is to just add a new name for > web.input (web.inputs?) and encourage people to use that instead. > That's probably the best idea. > > Then there should be two functions built into templetor, one that > returns a hidden input with the token and one that just returns the > token itself. > > The main security question is: what's the token? The cookbook page > uses a random number stored in the session. I hate sessions so I of > course I don't like this. I'd prefer some sort of HMAC of the browser > fingerprint, but I don't know if that's secure. This is where the > security expert comes in. I'll ask around about this. -- You received this message because you are subscribed to the Google Groups "web.py" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/webpy?hl=en.
