|
|
Posted by ZeldorBlat on 11/18/05 05:10
>I have an idea for preventing sql injection attacks, however it would
>have to be implemented by the database vendor. Let me know if I am on
>the right track, this totally off base, or already implemented
>somewhere...
Ok.
>Lets say you could have a format string such as in printf
>
>$format=" SELECT %s FROM %s WHERE id='%s' ";
>$fieldname="last_name";
>$tablename="personel";
>$id="425";
>
>and you could execute a query like
>
>mysql_query_formatted($format, $fieldname, $tablename, $id);
What about more elaborate queries that involve multiple tables, compted
columns, subqueries, updates, deletes, etc. ?
>now, the key is that instead of just adding the $fieldname, $tablename,
>$id to the $format string and passing it to mysql_query, it would be
>passed to the parser as separate strings. The parser should know how
>to handle that format. That way, the parser would always know where
>the different tables names, field names, and other strings start and
>end. So, the problem of injection attacks caused by some one confusing
>the parser by entering things like ' and " is gone.
>
>It would be easier on the programmer. There would be no need to worry
>about escape characters when passing to this function, the strings
>would not have to be escaped.. The parser would no longer have to
>guess where the boundaries are. No more worrying about injection
>attacks.
>
>does that make sense?
I hate to break it to you, but this is what stored procedures were made
for. I realize that procs are new to MySQL in v5.0, but if you have
access to them you should use them. They'll only accept a specific
list of required (and optional) parameters and the type checking and
conversions are handled automatically (most of the time). All you need
then is to make sure to escape text and close it in quotes and you can
build a query to execute the proc -- which follows a very simply
pattern no matter what the query ultimately does.
Navigation:
[Reply to this message]
|