Oh.....so, that's why they say to always always always use the execute
function's variable substitution, and not Python's? I thought that
there were ways around escaping schemes.
On 08/09/2013 05:37 PM, Dragan Espenschied wrote:
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?
--
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.
