MySQL Injection Auditing
Posted: Thu Sep 18, 2008 8:35 pm
I am auditing a PHP/MySQL/Fedora Linux/Apache (latest versions) webpapp for injection vulnerabilities. I am the "second set of eyes" for my boss, who wrote it. I have the code base as it is something the company I work for built.
A line-by-line review of the code indicates that every time a variable is used in a query, it is always surrounded with the proper quotes such as `` or ''
Additionally, mysql_real_escape_string() is being called on every variable allowed into a query, in every instance.
All of the query-related logic looks like this:
$username=mysql_real_escape_string($submitted['username']);
$table=mysql_real_escape_string($app['table_name']['users']);
$query="SELECT * FROM `$table` WHERE `username`='$username' LIMIT 1;";
(Please note that there is a check on $submitted['username'] several lines up ensuring that its length is less than that of the `username` field on the `users` table, followed by a trim(), rendering truncation attacks useless)
This appears to be by the book, and I can't seem to find any way to break out and get anything by. Is this correct, or is there a more obscure vulnerability that I am missing?
Part Two: I noticed a DB method that takes an array of mixed clean/unclean data, and inserts it to a table. The function iterates through every key/value pair, adding `` around the field name, and '' around the value, after both field name and value have been run through mysql_real_escape_string().
The app as a whole uses some fairly aggressive anti-hack measures. He hard coded every include as a static file, and is even HMAC'ing the fields that injections might seek to update. Even if I could break out and run an UPDATE on a password in the user table, I could never log in because the checksum would be off. Short of a remote code exec or a dump of the HMAC keys, I don't see any way to get around the fact that sensitive fields can only be updated with the help of application logic, not simply SQL alone.
I guess he is my boss for a reason.
A line-by-line review of the code indicates that every time a variable is used in a query, it is always surrounded with the proper quotes such as `` or ''
Additionally, mysql_real_escape_string() is being called on every variable allowed into a query, in every instance.
All of the query-related logic looks like this:
$username=mysql_real_escape_string($submitted['username']);
$table=mysql_real_escape_string($app['table_name']['users']);
$query="SELECT * FROM `$table` WHERE `username`='$username' LIMIT 1;";
(Please note that there is a check on $submitted['username'] several lines up ensuring that its length is less than that of the `username` field on the `users` table, followed by a trim(), rendering truncation attacks useless)
This appears to be by the book, and I can't seem to find any way to break out and get anything by. Is this correct, or is there a more obscure vulnerability that I am missing?
Part Two: I noticed a DB method that takes an array of mixed clean/unclean data, and inserts it to a table. The function iterates through every key/value pair, adding `` around the field name, and '' around the value, after both field name and value have been run through mysql_real_escape_string().
The app as a whole uses some fairly aggressive anti-hack measures. He hard coded every include as a static file, and is even HMAC'ing the fields that injections might seek to update. Even if I could break out and run an UPDATE on a password in the user table, I could never log in because the checksum would be off. Short of a remote code exec or a dump of the HMAC keys, I don't see any way to get around the fact that sensitive fields can only be updated with the help of application logic, not simply SQL alone.
I guess he is my boss for a reason.