Darren New wrote:
> James G. Sack (jim) wrote:
>> The "direct from form" phrase suggests to me that the example variable
>> above, "$sql" (maybe) comes from form post data.
>
> Well, the text of the arguments and columns does, yes.
>
>> Post data can, of
>> course, be spoofed, so there is no certainty that the data returned with
>> your form's action is the data that was intended by virtue of your own
>> html.
>
> Correct.
>
> The form data is the names and values in (for example) a select or
> insert. Not the SQL itself.
>
> It's really most useful to take the data *directly* from the form only
> for trusted sources, like administration pages, RPC calls between
> different parts of your systems, etc. I did more B2B than B2C pages, so
> it's less of a problem if someone messing up the form results in an
> error message.
>
>> It raises an especially big reaction from me since it is a completely
>> unnecessary risk, easy to avoid:
>>
>> => There is no reason to have post data provide anything resembling sql.
>
> No. The code would be something like
> $sql = build_insert('customer', $_POST);
> was the point. Then executing that SQL, everything is properly quoted by
> the build_insert(), anything the customer left blank gets defaults, and
> if the customer supplies fields not in the table (and not munged out of
> $_POST by earlier code), the SQL engine throws an error which comes back
> to the customer.
>
> But that was mainly when some other business' server was coming into our
> server to build a customer record, not direct from a human being we
> hadn't touched lawyers with already.
>
> You can also do things like grope around in $_POST and $_GET directly,
> adjusting as needed, and then call build_insert() again.
>
> In any case, the point was it's far easier to write a library where you
> give the table and name->value mappings and have it build the SQL for
> you than it is to manually concatenate everything each time.
>
>> The sql could even be further buried in class member code, or some such,
>> but the big point is that post (or query) data may not be what your form
>> was expected to return -- and you shouldn't assume so.
>
> Correct. Indeed, that's exactly why you need to quote anything you're
> going to display via HTML or evaluate with MySQL, which is why PHP and
> MySQL give you tools to quote things correctly. :-)
>
Thanks for the clarifications.
..and for tolerating my rant. I'm not usually allowed to do that. ;-)
Regards,
..jim
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
