Questions about this topic? Sign up to ask in the talk tab.
Delete after length check
From NetSec
Revision as of 06:29, 6 December 2012 by LashawnSeccombe (Talk | contribs)
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.