Difference between revisions of "PHP Patching"
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | {{ | + | {{cleanup}} {{WrongPerson}} |
| + | |||
| + | |||
| + | |||
| + | |||
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]]. | 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]]. | ||
| Line 7: | Line 11: | ||
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: | 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: | ||
| − | + | '''''Warning:'''This code is vulnerable. Don't use it anywhere.'' | |
| − | <syntaxhighlight lang="php"> | + | {{code|text=<syntaxhighlight lang="php"> |
<?php | <?php | ||
$query="SELECT body FROM articles WHERE articleid=".mysql_real_escape_string($_GET['id']); | $query="SELECT body FROM articles WHERE articleid=".mysql_real_escape_string($_GET['id']); | ||
?> | ?> | ||
| − | </syntaxhighlight> | + | </syntaxhighlight>}} |
This code is vulnerable because an attacker can change the url to : | This code is vulnerable because an attacker can change the url to : | ||
| Line 85: | Line 89: | ||
Web Application Firewalls | Web Application Firewalls | ||
| − | + | ||
| + | {{countermeasures}} | ||
Latest revision as of 03:10, 22 October 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: Warning:This code is vulnerable. Don't use it anywhere.
|
<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
