thedod added a cookbook page about CSRF to the wiki:
https://github.com/webpy/webpy.github.com/commit/33f34aedc82e040950ca6a92e08fa5bf8f18ede5

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.

Reply via email to