Thanks for the response; I would love anyone else to give additional
perspectives/opinions.
I realize the difference between security and validation, but in some
cases I think doing one can indeed completely include the other. I
guess the big example is numerical inputs; validating means only digits
are allowed, period. If there are only digits in a string, that string
is *also* secured.
Now another question I have is, what if the validation changes based on
other form inputs? I have a dropdown whose value is a number, and
depending one what number is selected, the allowable numbers for a text
field changes. Same goes for one dropdown depending on another. And to
keep things interesting, deciding what values are allowable depends on a
dB lookup.
TBH, right now I am just skipping the built-in form validation stuff and
doing it in python directly, because I know how to do that, and there is
already so much stuff I don't know and am learning, I don't really
prioritize doing form validation with web.py when there is no compelling
reason to do so, given that I don't know how at the moment, and that
figuring out how from the documentation is a small side-project on its
own. It's probably something I'd try to improve on the next revision,
unless there is a very good reason to make it a priority, or if there is
some better guides/examples/documentation that I can learn how to from
better, that I haven't found yet.
On 08/23/2013 09:14 AM, zbouboutchi wrote:
Another thing (little off topic with db), I think you are putting data
validation and data security in the same bag ....
Data security consists in transporting data with maximum safety and
totally control the execution of the content.
Data validation consists in the execution of a set of rules to verify
that the provided data fits the requirements.
Do these tasks in seperate time and space ! They're not dependent.
You must trust your data validation routines, so get them in a secure
room !
Postgres provides huge things to validate your data, because it is a
database management system, and it is its job to provide you your data
validated as you wanted it to be !
For simple data validation, domains should do the trick. If your
looking for something more refined, take a look to constraints and
triggers.
Have a good day.
free tip: In postgres, you can use regexp with the ~ operator.
Le 23/08/2013 14:58, zbouboutchi a écrit :
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.
