Hi,
your dbms is higly capable to recognize bad inputs himself, I think you
should'nt try to interfere with this.
Instead of this, usually SQL injection is prevented by escaping
dangerous things like ' or ;...
Web.py already provides this method. An example is given here:
http://webpy.org/cookbook/query
BTW, you can go on your own with your prefered strategy. ;)
For SQL, I usually use some functions of mine who use base64 to
«transport» the parameters encoded in base64 inside the query. I use
postgres' native decoding to get the human readable data into the tables.
For js/html/etc, I use mako's functions to escape naughty strings came
from another world ;). I think all «templators» have this possibility
and you should'nt worry about this, use one of them.
Regards,
Christophe.
Le 23/08/2013 11:11, Steven Brown a écrit :
I have been busy scrubbing and validating my inputs, and trying to
read up on how to avoid SQLI attacks, but I am being confounded by
incomplete information, possibly due to my own lack of experience and
knowing what/how to search on this topic. web.py's lack of usable
documentation doesn't help either.
For numeric inputs, I can and do validate aggressively; if a field
should be a number and has non-numerics, I just strip them out. I
have a couple of dropdowns and just make sure that the input exactly
matches one of the options. But my application has several fields
that simply cannot be validated, except maybe by stripping out
non-printables; though that presents its own issues, because I have no
idea how to allow for foreign characters if I whitelist. Anyway,
examples of such fields are:
comments
a URL
username
password
The URL field presents its own challenges; I think there is a
URL-encoding function, somewhere, in a different python library maybe,
that I should be using. But my big question is, the SQL, and then
when I want to display these things on a webpage, how exactly to make
sure nothing screws up the webpage.
For the SQLI attacks, it seems to me that if I strip out
non-printables and escape single quotes, that should be enough.....but
that seems too easy, and it seems the consensus is not to do that
(roll your own blacklist/escaping scheme). In fact, the consensus
seems to be to use these "prepared statements," but I cannot figure
out what web.py can provide me regarding this. The last time I
brought this up, Dragan mentioned that I should use web.py's built-in
dB functions, which I would love to do.....but I don't know what that
necessarily means. I've been using db.insert('tablename',
column1=column1_python,....), is this enough? What about select
statements? Those are the ones that I have been using just string
concatenation, which is, according to what I have been able to find
out, the Most Horrible Thing Ever, but if you know what is being
concatenated, I don't see what the big deal is. I'm perfectly willing
to do things the Right Way, I'd just like to know what that is. I
tried looking into psycopg2, which is what web.py seems to use (I'm
using PostGres), but their examples all use cursors, which I don't
think I am, at least not directly, and rather than just forge ahead
blindly, I wanted to ask if there was something I was missing.
Then there is displaying these things. I'm mostly worried about the
comments field, but anytime I am displaying arbitrary data, I imagine
there is potential to do terrible things in HTML/with JavaScript.
ATM, I am anticipating always putting things *between* tags, and never
inside them. For example, if I am displaying comments, I would just
put <div class='comments'> $comment_from_database </div> . Do I need
to do anything other than escape < and >, or does web.py actually just
take care of everything for me, since I'm not using $: ?
--
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.
