Difference between revisions of "PHP Patching"

Revision as of 01:05, 16 May 2012

As far as common vulnerabilities, the most common that I have run across aside from the aforementioned server errors are web application vulnerabilities. Normally, the most common of these vulnerabilities are Cross Site Scripting XSS and SQL injection.

Generally speaking, these vulnerabilities arise from improper error handling, for example, say we are testing target.net and they have an articles.php page. We visit

 /article.php?id=23&title=Hello%20World

and we can see the 23rd article inside of the SQL backend. Now lets look over what a vulnerable PHP/SQL query would look like in this scenario:

<syntaxhighlight lang="php"> <?php

     $query="SELECT body FROM articles WHERE articleid=".mysql_real_escape_string($_GET['id']);

?> </syntaxhighlight>

This code is vulnerable because an attacker can change the url to :

 /article.php?id=23%20AND%201=1&title=Hello%20World

and the page will still display, however when the attacker changes the url to :

 /article.php?id=23%20AND%201=0&title=Hello%20World

The body of the article will no longer display. This is called "blind sql injection" because we are not being given an error from the SQL server. The SQL injection vector is considered "Improper Type Handling" or an "Integral Handling Error". Even though mysql_real_escape_string() is being used to sanitize user input, because we are dealing with an integer in the database and the $id variable is not being wrapped in quotes, the attacker does not need to use the %27 (') escape string to inject SQL code.

So in stead of the above scenario, staying with SQL injection, lets say that the code looked like :

<syntaxhighlight lang="php"> <?php

    $query="SELECT body FROM articles WHERE articleid='".$_GET['id']."'";

?> </syntaxhighlight>

The $id variable is being wrapped in quotes, however mysql_real_escape_string is not being used, so in stead of using the following URLs to verify the site's vulnerability:

 /articles.php?ID=23%20AND%201=0/*&title=Hello%20World
 /articles.php?ID=23%20AND%201=1/*

The attacker would use :

 /articles.php?ID=23%27%201=0/*&title=Hello%20World
 /articles.php?ID=23%27%201=1/*&title=Hello%20World

The /* comments out the rest of the query so that the additional ' to close the string is now a comment and does not cause a type mismatch.

Patched SQL/PHP code, or "safe" code, looks as follows :

<syntaxhighlight lang="php"> <?php

   $query="SELECT body FROM articles WHERE articleid='".mysql_real_escape_string($_GET['id'])."'";

?> </syntaxhighlight>

As well as :

<syntaxhighlight lang="php"> <?php

    $query="SELECT body FROM articles WHERE articleid=".intval($_GET['id']);

?> </syntaxhighlight>

Now, lets say the attacker or penetration tester, in this case, wants to find out if the site is vulnerable to XSS. Remembering the original URL :

 /article.php?id=23&title=Hello%20World

The penetration tester could visit :

 /article.php?id=23&title=Hello%20World%3CIFRAME%3E

If the IFRAME appears by the title, the penetration tester has found a cross-site scripting vulnerability. The %3c is the < sign or opening tag and the %3e is the > or the closing tag. Vulnerable PHP code would look like

<syntaxhighlight lang="php"> <?php

    echo($_GET['title']);

?> </syntaxhighlight>

whereas patched or "safe" code would look like:

<syntaxhighlight lang="php"> <?php

    echo(strip_tags($_GET['title']));

?> </syntaxhighlight>

Web Application Firewalls