If you use webpy's built-in database functions, all incoming variables will be escaped before writing them into the database. Check the cookbook. So if a user thinks their name is DROP TABLE, or even ''DROP TABLE or whatever, webpy will apply the correct escaping.
Putting base64 encoded strings into a database makes no sense, because you can't use most of the db's functions on the actual user input then. Am 08.08.2013 17:49, schrieb Steven Brown: > web.py has a mechanism to prevent cross-site scripting attacks, and for my > application doesn't have arbitrary executables as a thing. So that leaves SQL > injection to guard against. My question is, how should one go about this? I > am > thinking do validation on any non-general text web form fields, both in the > form > object and in the python code itself. For any unrestricted text fields, like > passwords or comments, that can't really be validated, can't I just base-64 > encode it in the python code, and store only the base-64 encoding in the db? > This will increase my space requirements, but it seems pretty bulletproof to > me, > so I think I'm ok with that. Actually, I'd hash the passwords in the python > code, so I shouldn't need to worry about password fields. The only way it > might > be a problem is if someone figured out a password whose hash value was an > attack. That seems unlikely. > > Also, are there any other major attack vectors I should guard against? > -- http://1x-upon.com/~despens/ >NEW!< http://noobz.cc/ http://contemporary-home-computing.org/1tb/ -- You received this message because you are subscribed to the Google Groups "web.py" 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/webpy. For more options, visit https://groups.google.com/groups/opt_out.
