On Fri, 5 Apr 2002, Chris Boget wrote:
>> You can never assume that submitted data is benign or untampered.
>
> Ok, then how do you go about checking to make sure that submitted
> data is, in fact, benign and acceptable for your use?
I use two general principles:
1) Rather than trying to rule out bad stuff, instead rule in good stuff.
For instance, people often sanitize data with regular expressions that
filter out some selected boogeyman characters (quotes, backslashes,
semicolons, whatever, depending on context). I prefer to always approach
it the other way, thinking of the minimum range of characters that are
actually useful in the context, and allow ONLY those.
$str = ereg_replace ('[^a-zA-Z]', '', $str);
That way it's much less likely that some unanticipated attack will catch
me by surprise.
Another way of saying this would be to never assume anything about your
inputs, and to explicitly mold each input to your program's needs.
2) If you already have a piece of data, try not to get it from the
browser. Instead, just get the browser to send you a relative pointer to
the appropriate item within your set.
If someone is selecting an item from a list you already have in your
database, make sure that the 'select' form element sends in the numerical
ID of that item rather than its name - you already know the names. The ID
can immediately be validated or discarded as bogus, and being a number,
it's much safer to work with.
In an example that came up today, someone needed to select a file stored
on the server, and specify a path. There's no need to specify a full path
in a case like that; it should always be relative to the top of the area
in which web visitors are able to view files. In this case, you already
know the first part of the path and there's no need to have the browser
tell you. All you need to know is which subpath the user's selected.
Probably all common sense but you never know...
miguel
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
