12.1. Cross-Site Scripting
Cross-site scripting (XSS) is an attack method whereby a malicious user inserts specially crafted HTML or JavaScript into your page. The goal of such an attack is to trick a visitor into providing his sensitive information to the attacker while he thinks he is really providing it just to your site (phishing) or to outright steal the login credentials with which the attacker can later log in and legitimately retrieve the information. Identity theft in any form is a serious concern, but doubly so when personally identifiable or financial information is stolen.
The primary defense in protecting yourself, your applications and your users from XSS attacks is to properly escape user input and never display it unescaped in a web page. Consider the following example, exploit_01.php:
<html>
<?php
if (isset($_POST['submitted']))
{
echo '<p>Hello, ' . $_POST['name'] . '</p>';
}
else
{
?>
<form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="post">
<div>
Enter your name: <input type="text" name="name"/>
<input type="submit" value="Submit"/>
<input type="hidden" name="submitted" value="true"/>
</div>
</form>
<?php
}
?>
</html>The code displays a form to collect the user's name and posts the value back to the same page. The second viewing detects the form submission and displays a greeting. The code may look straight forward, but there are a couple of security vulnerabilities which a malicious user can take advantage of.
First, the input accepted from the form is inserted directly into the output HTML without any form of filtering. If an attacker were able to trick a user into putting HTML or JavaScript in the field, then the browser would parse the code when it processes the page. Suppose for a moment the following input was entered into the field:
<script>alert('Cracked!')</script>The browser would detect the script tags and process the JavaScript code. Here the code does nothing more innocuous than display a message dialog as illustrated in Figure 12-1, but a malicious individual would be capable of crafting something more devious such as redirecting the user, changing the location the form posts its information to and more.
Figure 12-1. Figure 12-1
A good defense against the attack is to filter the input with htmlentities(), htmlspecialchars(), or strip_tags(). The htmlentities() and htmlspecialchars() functions will replace the special < and > characters with their respective entity definitions resulting in the browser displaying the input as plain text. strip_tags() will remove the <script> tags and any other HTML and PHP tags as well.
The second vulnerability which may not be as obvious is the unescaped use of $_SERVER['PHP_SELF']. Despite being a member of the $_SERVER array, the PHP_SELF value is considered user input because it reflects what was entered as the calling URL. Consider the following address:
www.example.com/exploit_01.php/%22%3E%3Cscript%3Ealert('Cracked!')%3C/script%3EApache will resolve the page request to exploit_01.php and pass the trailing fragment to the script for use as a parameter. The %xx values are actually URL encoded characters, which form the following:
"><script>alert('Cracked!')</script>As PHP dutifully outputs the value of $_SERVER['PHP_SELF'] the trailing attack vector is also included. The initial quote and closing angle bracket terminate the form tag. The browser then detects the script element and executes the JavaScript code.
To protect your application from this method of attack you should filter the value with htmlspecialchars(). Never trust user input no matter what the source.
Here is the same code but corrected to prevent these XSS attacks:
<html>
<?php
if (isset($_POST['submitted']))
{
echo '<p>Hello, ' . htmlspecialchars($_POST['name']) . '</p>';
}
else
{
?>
<form action="<?php echo htmlspecialchars($_SERVER['PHP_SELF']); ?>"
method="post">
<div>
Enter your name: <input type="text" name="name"/>
<input type="submit" value="Submit"/>
<input type="hidden" name="submitted" value="true"/>
</div>
</form>
<?php
}
?>
</html>