Questions about this topic? Sign up to ask in the talk tab.
Delete after length check
From NetSec
Revision as of 10:55, 2 December 2012 by JtRIPper (Talk | contribs) (Created page with " Delete after length-check (Empty Where Clauses) Proof of concept: ------------------------ While the example here is based on SQL injection, it can apply to other scena...")
Delete after length-check (Empty Where Clauses)
Proof of concept:
------------------------
While the example here is based on SQL injection, it can apply to other scenarios as well. Suppose the following php code:
<?php
# pwreset.php
if (strlen($_GET['reset']) == 16) {
$pwreset_code = preg_replace_all('/([^\w]+)/',,$_GET['reset']); #alphanumeric only.
$user_query = "SELECT * FROM user WHERE pwreset_code= '" . $pwresetcode ."' LIMIT 1";
$user_data = @mysql_query($user_query);
...
}
-----------------------
pwreset.php?reset='''''''''''
The generated sql statement:
SELECT * FROM user WHERE pwreset_code= LIMIT 1;
As reset codes are generated on reset request (forgot password form), this will leave the first user (usually the admin) of the web app exposed to arbitrary password overwrite.
Mitigation:
Instead of checking length before replacement, verify after deletion.
* PHP:
<?php
# pwreset.php
$pwreset_code = preg_replace_all('/([^\w]+)/',,$_GET['reset']); #alphanumeric only.
if (strlen($pwreset) == 16) {
$user_query = "SELECT * FROM user WHERE pwreset_code= '" . $pwresetcode ."' LIMIT 1";
$user_data = @mysql_query($user_query);
...
}
In the wild:
A Joomla! framework exploit leveraged this weakness for an administrative password reset (2008).
CVE 2008-3861 http://www.exploit-db.com/exploits/6234/
Auditing:
Follow the same auditing steps as listed for unsafe deletion, with an eye towards where clauses or other empty type comparisons that could lead to problematic outcomes.