Post from the past: security fix after 8 years
Contributed by: Email on 12/04/12 11:20 am
[
Comments
]
The advisory from January 2005 was just one of hundreds of similar notices around then: a PHP application wasn't validating the parameters of a database query, which could have allowed an attacker with special URLs to inject database commands. The strange thing about this bug report for PHP Gift Registry, however, is that after more than seven years, the program's developer has finally decided to respond.
"All SQL queries have been replaced with parameterized statements in version 2.0.0" is all that is written in a message from Monday, 3 December 2012, that is apparently from the program's developer.
These kinds of SQL injection vulnerabilities are still widespread and are web applications' biggest security issues. Prepared statements are the easiest and most efficient way to protect against them; the developer prepares a database query, declaring which variable should be specified later, like the username:
$stmt = $dbh->prepare("SELECT user FROM users WHERE (user=:user)");
$stmt->bindParam(':user', $user);
When the program is run, the developer only has to specify the username and can then send the prepared database query:
$user = 'ju';
$stmt->execute();
The advantage with this method is that even if, for some strange reason, something like
ju';DROP TABLE users; --
ends up in the $user variable, it will always just be treated like a strange search criterion and will never lead to unwanted database commands like table deletion.
"All SQL queries have been replaced with parameterized statements in version 2.0.0" is all that is written in a message from Monday, 3 December 2012, that is apparently from the program's developer.
These kinds of SQL injection vulnerabilities are still widespread and are web applications' biggest security issues. Prepared statements are the easiest and most efficient way to protect against them; the developer prepares a database query, declaring which variable should be specified later, like the username:
$stmt = $dbh->prepare("SELECT user FROM users WHERE (user=:user)");
$stmt->bindParam(':user', $user);
When the program is run, the developer only has to specify the username and can then send the prepared database query:
$user = 'ju';
$stmt->execute();
The advantage with this method is that even if, for some strange reason, something like
ju';DROP TABLE users; --
ends up in the $user variable, it will always just be treated like a strange search criterion and will never lead to unwanted database commands like table deletion.
Comments
