Questions about this topic? Sign up to ask in the talk tab.

Difference between revisions of "Delete after length check"

From NetSec
Jump to: navigation, search
(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...")
 
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Delete after length-check (Empty Where Clauses)
+
=Proof of concept=
  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:
 
+
 
  ------------------------
+
{{code|text=<source lang="php">
  While the example here is based on SQL injection, it can apply to other scenarios as well.  Suppose the following php code:
+
<?php
  <?php
+
  # pwreset.php
  # pwreset.php
+
  if (strlen($_GET['reset']) == 16) {
  if (strlen($_GET['reset']) == 16) {
+
    $pwreset_code = preg_replace_all('/([^\w]+)/','',$_GET['reset']); #alphanumeric only.
    $pwreset_code = preg_replace_all('/([^\w]+)/','',$_GET['reset']); #alphanumeric only.
+
    $user_query  = "SELECT * FROM user WHERE pwreset_code= '" . $pwresetcode ."' LIMIT 1";
    $user_query  = "SELECT * FROM user WHERE pwreset_code= '" . $pwresetcode ."' LIMIT 1";
+
    $user_data    = @mysql_query($user_query);
    $user_data    = @mysql_query($user_query);
+
    ...
    ...
+
  }
  }
+
 
  -----------------------
+
 
  pwreset.php?reset=''''''''''''''''
+
  // pwreset.php?reset=''''''''''''''''
  The generated sql statement:
+
  //  The generated sql statement:
    SELECT * FROM user WHERE pwreset_code='' LIMIT 1;
+
  //  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.
+
</source>}}
  Mitigation:
+
  Instead of checking length before replacement, verify after deletion.
+
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.
  * PHP:
+
    <?php
+
=Mitigation=
    # pwreset.php
+
Instead of checking length before replacement, verify after deletion.
    $pwreset_code = preg_replace_all('/([^\w]+)/','',$_GET['reset']); #alphanumeric only.
+
 
    if (strlen($pwreset) == 16) {
+
==PHP==
      $user_query  = "SELECT * FROM user WHERE pwreset_code= '" . $pwresetcode ."' LIMIT 1";
+
 
      $user_data    = @mysql_query($user_query);
+
{{code|text=<source lang="php">
      ...
+
<?php
    }
+
  # pwreset.php
  In the wild:
+
  $pwreset_code = preg_replace_all('/([^\w]+)/','',$_GET['reset']); #alphanumeric only.
    A Joomla! framework exploit leveraged this weakness for an administrative password reset (2008).  
+
  if (strlen($pwreset) == 16) {
    CVE 2008-3861 http://www.exploit-db.com/exploits/6234/  
+
    $user_query  = "SELECT * FROM user WHERE pwreset_code= '" . $pwresetcode ."' LIMIT 1";
 
+
    $user_data    = @mysql_query($user_query);
  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.
+
  }
 +
</source>}}
 +
 +
=In the wild=
 +
A Joomla! framework exploit leveraged this weakness for an administrative password reset (2008). [http://www.exploit-db.com/exploits/6234/ CVE 2008-3861]
 +
 +
=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.

Latest revision as of 02:40, 12 May 2013

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

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.