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. :-)
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
