Kinds of Injection Attacks
row in a table by injecting a condition like 1=1 into the WHERE clause, with something like this (the injection is in bold):
SELECT * FROM wines WHERE variety = 'lagrein' OR 1=1;'
properties into the SET clause, an attacker can modify any of the fields in the record being
updated, with something like this (the injection is in bold type):
UPDATE wines SET type='red','vintage'='9999' WHERE variety = 'lagrein'
And by adding an always-true condition like 1=1 into the WHERE clause of an UPDATE instruction, that modification can be extended to every record, with something like this (the injection is in bold type):
UPDATE wines SET type='red','vintage'='9999 WHERE variety = 'lagrein' OR 1=1;'
buried and therefore overlooked change might in the long run be more destructive than a
wholesale deletion, which is likely to be immediately obvious. The injection technique is the
same as what we have already seen, extending the range of affected records by modifying the
WHERE clause, with something like this (the injection is in bold type):
DELETE FROM wines WHERE variety = 'lagrein' OR 1=1;'
more than one destructive instruction to be included in a query. The attacker sets this up by introducing an unexpected termination of the query. This is easily done with MySQL, where first an injected quotation mark (either single or double; a moment’s experimentation will quickly reveal which) marks the end of the expected variable; and then a semicolon terminates that instruction. Now an additional attacking instruction may be added onto the end of the now-terminated original instruction. The resulting destructive query might look something like this (again, the injection, running over two lines, is in bold type):
SELECT * FROM wines WHERE variety = 'lagrein'; GRANT ALL ON *.* TO '[email protected]%' IDENTIFIED BY 'gotcha';'
leges on all tables, and a facetious but sinister password, onto what had been a simple SELECT
statement. If you took our advice in Chapter 10 to restrict severely the privileges of process
users, this should not work, because the webserver daemon no longer has the GRANT privilege
that you revoked. But theoretically, such an exploit could give BadGuy free rein to do anything he wants to with your database.
by the MySQL server. Some of this variability may be due to different versions of MySQL, but
most is due to the way in which the multiple query is presented. MySQL’s monitor program
allows such a query without any problem. The common MySQL GUI, phpMyAdmin, simply
dumps everything before the final query, and processes that only.
But most if not all multiple queries in an injection context are managed by PHP’s mysql
extension. This, we are happy to report, by default does not permit more than one instruction to be executed in a query; an attempt to execute two instructions (like the injection exploit just shown) simply fails, with no error being set and no output being generated. It appears that this behavior is impossible to circumvent. In this case, then, PHP, despite its default hands-off behavior, does indeed protect you from the most obvious kinds of attempted injection.
that is bundled with PHP 5 (see http://sqlite.org/ and http://php.net/sqlite), and that has
attracted much attention recently for its ease of use. SQLite defaults to allowing such multiple-instruction queries in some cases, because the database can optimize batches of queries, particularly batches of INSERT statements, very effectively. The sqlite_query() function will not, however, allow multiple queries to be executed if the result of the queries is to be used by your script, as in the case of a SELECT to retrieve records (see the warning at ttp://php.net/ for more information).