MySQL Injection Auditing

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Post Reply
tony14
Forum Newbie
Posts: 1
Joined: Thu Sep 18, 2008 8:33 pm

MySQL Injection Auditing

Post by tony14 »

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.
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Re: MySQL Injection Auditing

Post by Mordred »

This is wrong:

Code: Select all

$table=mysql_real_escape_string($app['table_name']['users']);
$table is not a SQL value, but a SQL name. If some of these names come from user input, escaping is incorrect, they should be whitelisted. I don't imagine this will happen with a table name, so look for column names and sorting directives in code dealing with searching, ordering columns of data, pagination, etc.
http://www.logris.org/security/the-unex ... -injection

HMAC-ing (if done properly; there are some ways to get it wrong) would only help to detect malicious modification, it will not protect against read-only access, like stealing the admin password.
Post Reply