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.
MySQL Injection Auditing
Moderator: General Moderators
Re: MySQL Injection Auditing
This is wrong:
$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.
Code: Select all
$table=mysql_real_escape_string($app['table_name']['users']);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.