deep inside: security and tools

PHP, Variable variables, Oh my!

I was just looking at some PHP code for one of our clients, and found a case I haven't seen many times before. I thought I should share it here.

The code I was looking at looks like this:

// Init the PHP array with some SQL code to start the query
$declareSQLArray = InitializedArray('stuff');
// Use a strong enough validation routine for do the input
// validation of POST variables
while(list($name, $value) = each($_POST)) {
    $$name = StrongValidation($value);
    $$name = $value;
// Do something with my variables and always do a proper
// validation when I use the data
// Eventually, build my SQL command, and send this to the DB
$sql_command = join(' ', $declareSQLArray);

The code, even if horribly constructed, does not seem to show importantweaknesses, but the usual case of submitting a POST variable as an array, and bypassing the StrongValidation. Then, in that case, it would havefailed every other validation routines in the code.

Even if experienced with PHP, you might not have encountered variable variables before. In short, this allows to dynamically declare named variables. Here is a simple example:

$ php -r '$name="foo"; $$name="Hello World!"; echo $foo;'
>>> Hello World!

Here, the variable $foo gets declared, and assigned using PHP variable variables capabilities.

Getting back to our code example, I'm sure the reader will spot the issue,and what an attacker can do to exploit such scenario to trigger, in that case,a SQL injection. Since the variable $declareSQLArray is definedand initialized before the POST variables lookup, it is possible to reassign itusing the variable variables. In that case, no validation is performed when wesubmit an array, and this is exactly what we want to do!

To exploit the SQL injection, you only need to submit POST variables tooverwrite the $declareSQLArray, and add the content that we want in it!

POST /code_example.php HTTP/1.1


Job done! The resulting SQL query will start with the payload that wassubmitted as part of $declareSQLArray. You've got your SQL injection.

Update: While driving back home, I was wondering if I couldoverwrite values from the SESSION using this technique. A couple of lines of code, and POST request after the answer is short: YES.

Imagine that you have an isadmin variable as part of thesession (which is an associative array). This variable would be set in a code like this:

if ($user->isNotAdmin())        
  $_SESSION['isadmin'] = 0;
  $_SESSION['isadmin'] = 1;

Exploiting the previous weakness of the code example, we are able tooverwrite the $_SESSION['isadmin'] content, only by supplying what will be interpreted as an associative array by PHP:

POST /code_example.php HTTP/1.1


I'm sure you're thinking, as I do, that this is getting moreinteresting!

Anyways, this issue is not new at all, it is known as Dynamic Variable Evaluation (thanks to Steve Christey).

The interesting part of it is that DAST won't be able to detect it (or maybeif you are lucky enough), and it is very hard for a SAST to deal with it (actually, I doubt any SAST vendor who supports PHP handles this case, but it'snot impossible since they have all they need to solve the problem).

Update 2: Based on the comments, I did some testing and observed that even if we can overwrite data from the session, this data doesnot get persisted in the session. This means that you can still control a valuefrom a super global for the remaining execution of the script, but cannot persist the data.

All entries

  1. February 2013 — RSA 2013 speaking session
  2. February 2013 — HTML5 tokenization visualization
  3. September 2011 — PHP, Variable variables, Oh my!
  4. July 2011 — Dissection of a SQL injection challenge
  5. January 2010 — Yes, we need a standard to evaluate SAST, but it ain't easy...
  6. November 2009 — Data driven factory: I give you data, you give me an object...
  7. June 2009 — NIST Static Analysis Tool Exposition special publication released
  8. December 2008 — Every-day's CSRF: Sorry, I turned off your christmas tree lights
  9. August 2008 — Why the "line of code" is indeed a good metric
  10. May 2008 — Accelerate the convergence to the bug: Running the test in 16-bit
  11. February 2008 — Code review tools: the missing link (so far)
  12. January 2008 — Talk: Problems and solutions for testing web application security scanners
  13. October 2007 — IE6 And IE7 don't have compatible CSS tricks
  14. September 2007 — Source Code Obfuscation
  15. February 2007 — The return of the SVG XSS
  16. February 2007 — How you should design a test suite for Web Apps Scanners
  17. January 2007 — Test Suites for Web Application Scanners
  18. December 2006 — SVG Files: XSS attacks