|
|
Posted by kenoli on 04/09/07 21:34
Steve -- thanks so much for your suggestions. I had earlier
considered array_walk and your reasoning for using it makes sense.
Also thanks for your suggestion about being more discriminating about
what string functions I apply to what. Your insight into the way the
the $$key approach invisibly creates a lof of variables that might not
be evident to someone, even me, returning to the script at a later
date is a good insight. It has stumped me in the past.
I have been thinking about creating a class for form processing of the
sort you describe as an exercise in understanding OOP since I find
myself re-inventing the wheel with forms and queries so often. I
suppose s sophisticaed class script could even check out what database
columns are being used and match them to the form imputs to generate
various kinds of queries. I have yet to actually utilize a class or
object, though I have read up on it; I still feel a bit intimidated.
I guess I need to jump in. I haven't come across a class that does
this sort of thing related to forms, which surprises me as, in my
coding, it is one of the things I end up coding and re-coding most
often.
--Kenoli
On Apr 8, 6:53 pm, "Steve" <no....@example.com> wrote:
> ken...
>
> have you thought of using array_walk?
>
> function escapeData(&$value)
> {
> if (ini_get('magic_quotes_gpc'))
> {
> $value = stripslashes($value);
> }
> $value = mysql_real_escape_string(strip_tags(trim(urldecode($value))));
>
> }
>
> array_walk($_POST, escapeData);
>
> since the function is compiled into php, it will run natively and is
> therefore much faster than using your own 'for' loop to iterate the post
> array. that may be something for you to think about.
>
> as for escapeData, you can cause yourself headaches by assuming all data is
> passed as urlencoded. it is not needed as far as i'm concerned...i only
> urlencode when i'm dynamically creating a hyperlink for html. php typically
> presents you with the decoded version of data (so to speak). you would be
> forcing user input that had a space character to be encoded as a plus sign
> (+) from the client to the server, and then force the server to translate it
> back to a space. i'm not sure why you'd do this.
>
> oh, and also, you can run into problems casting escaped data into things
> like dates and currency. better to allow a less broad stroke to handle
> things...that means, be more delicate.
>
> another issue would be stripping tags as some sort of default (with no
> option to override it). i may be asked on your form to enter my email
> address. if i put:
>
> Joe Blow <j...@example.com>
>
> my address would be valid, but you're code would be potentially stripping
> out the portion of it that is the actual valid piece of data...and again,
> you provide no means to override that functionality.
>
> as for doing $$key as a global from the post array...BAD IDEA !!! most
> obvious is the introduction of an opportunity for a hacker to overright
> predicted variables (userName, isValid, isSecure, etc.). the not-so-obvious
> downfall is that your variables are not explicitly set, transparent to other
> developers...including yourself when you come back to edit later. they'd be
> saying, 'where does this variable come from? from an included file, from a
> post, get, or other means? has it been set already, or is this where it is
> being defined?' that list goes on...and really pisses people off. be
> explicit at all times so that no one has to guess an how things work.
>
> your last idea is probably a good compromise. again though, you may want to
> simplify your code and speed it up using array_walk. also reuse namelist to
> help build your forms. namelist should not only define the variable name but
> what data-type it is supposed to be, what validation applies to it,
> max-length, input-type (text, hidden, select, etc.), and value. what you
> have now is the criterion for a class object. your namelist is an array of
> those objects and instead of just escaping data, you can set the value
> either to a default when empty or to the actual posted data. further, you
> can apply the validation and generate errors for the end-user. even more
> than that, you can walk the namelist array to generate your form with less
> lines of code...which means changes (enhancements, bug-fixes, etc.) are
> isolated to one section of code. AND, you've now been *very* explicit as to
> what the data means, where it comes from, and how it fits in to the
> application as a whole. no one being left confused. and, do you also see
> that this would allow you to now catch that the data is a date, currency,
> float, or other where you could now not just escape the string but use
> set_type() on the value to avoid problems later?
>
> one final remark...NEVER, EVER use $global. until you've learned the
> condition(s) under which it is a good idea, 'never' is literal...otherwise,
> you'll know that i really mean, 'only when it is absolutely
> necessary...which is almost never'.
>
> ;^)
>
> hth,
>
> me
>
> "kenoli" <kenol...@gmail.com> wrote in message
>
> news:1176078404.793386.307530@w1g2000hsg.googlegroups.com...
> | In addition to validating post input to see if it has been entered or
> | confroms to a regular expression, I am interested in secure ways to
> | efficiently process incomiing form data.
> |
> | I use a function to process this data, namely:
> |
> | function escape_data ($data) {
> |
> | if (ini_get('magic_quotes_gpc')) {
> | $data = stripslashes($data);
> | }
> | return mysql_real_escape_string(strip_tags(trim(urldecode($data))));
> | }
> |
> | It's tempting to apply it to all incoming data at once, like this:
> |
> | foreach($_POST as $key => $value) {
> | global $$key;
> | $$key = escape_data($value);
> |
> | }
> |
> | Of course this introduces the well known vulnerability of putting the
> | data into variables that can be modified.
> |
> | Another way to do this is to put the data in an array, like this:
> |
> | foreach($_POST as $key => $value) {
> | global $input;
> | $input[$key] = escape_data($value);
> |
> | }
> |
> | This has the advantage that I can use implode() to create strings that
> | can be applied to a database query.
> |
> | However, it includes all post variables, including data I dont' intend
> | to insert in my database so I can be selective about what form
> | elements I include like this:
> |
> | function ($namelist) {
> |
> | for each ($namelist as $formdata) {
> | if (!empty($_POST[$formdata]) {
> | global $formdata;
> | $formdata[] = escape_data($_POST[$formdata]);
> | }
> | }
> | }
> |
> | $namelist being an array of the names of the form elements I want to
> | extract for my query.
> |
> | I'm interested on people's reflections on the security of these
> | methods as well as other comments and suggestions for other
> | approaches.
> |
> | Thanks.
> |
> | --Kenoli
> |
Navigation:
[Reply to this message]
|