Difference between revisions of "Delete after length check"

Revision as of 12:05, 2 December 2012

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.