View source for PHP Patching

{{Cleanup}}
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|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 

{{countermeasures}}