Yes, you should not use the % operator or string.format() for building SQL 
queries.

webpy is importing the modules psycopg2 for postgres and MySQLdb for mysql as
database drivers, and is using escaping methods provided by them. These seem to
be solid modules. It depends on your level of paranoia if you trust them, but I
for sure do :)






Am 10.08.2013 16:29, schrieb Steven Brown:
> 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?
>>>
> 

-- 
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.

Reply via email to