I've sql injected using web.py's built-in DB operations. I would double check the code/implementation and do some validation on your end to be safe.
On Sat, Aug 10, 2013 at 12:42 PM, Dragan Espenschied <[email protected]>wrote: > 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. > -- 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.
