When it comes to cross-site scripting, we want to find those script injection points that are frequently overlooked.  A common source of stored cross-site scripting vulnerabilities is the file upload.  Not only can we store a script in the application, but this script may be downloaded by other users.  When we first explorer our application, file uploads should be a huge red flag for any web application penetration tester.

There are several factors that may affect whether the application is vulnerable to uploaded file attacks:

• The application may restrict file extensions.
• The application may inspect the file’s contents to ensure that it complies with an expected format.
• The application might check the file Content-Type header.

Some of these checks can be bypassed using the right files.  When examining the upload’s functionality, we should first upload a simple HTML file containing a proof-of-concept script.  If it’s accepted, try downloading the file.  If your script executes, we know that the application is vulnerable.

In most cases, the application will block the file upload or download, either because the file extension is not correct or the Content-Type header is not what is expected.  We can try bypassing these checks in a few different ways:

• Change the file’s extension.  For example, if we had a file named “test.txt” and the application only accepts files with the .jpg file extension, try renaming the file to “test.txt.jpg” or simply “test.jpg”.
• Use and intercepting proxy to change the Content-Type header.  Some applications will expect a specific Content-Type header.  Change it to the specific header that matches the file type expected.
• Insert the script after clicking the upload button using an intercepting proxy.