the-web-application-hackers-handbook

484 Chapter 12 n Attacking Users: Cross-Site Scripting
The following is an example of a raw e-mail file. As well as testing various
XSS payloads and filter bypasses in the message body, you can also try specifying
a different Content-Type and charset:
MIME-Version: 1.0
From: test@example.org
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: XSS test
.
Testing for XSS in Uploaded Files
One common, but frequently overlooked, source of stored XSS vulnerabilities
arises where an application allows users to upload files that can be downloaded
and viewed by other users. This kind of functionality arises frequently in today’s
applications. In addition to traditional work flow functions designed for file
sharing, files can be sent as e-mail attachments to web mail users. Image files
can be attached to blog entries and can be used as custom profile pictures or
shared via photo albums.
Various factors may affect whether an application is vulnerable to uploaded
file attacks:
n During file upload, the application may restrict the file extensions that
can be used.
n During file upload, the application may inspect the file’s contents to confirm
that this complies with an expected format, such as JPEG.
n During file download, the application may return a Content-Type header
specifying the type of content that the application believes the file contains,
such as image/jpeg.
n During file download, the application may return a Content-Disposition
header that specifies the browser should save the file to disk. Otherwise,
for relevant content types, the application processes and renders the file
within the user’s browser.
When examining this functionality, the first thing you should do is try to
upload a simple HTML file containing a proof-of-concept script. If the file is
accepted, try to download the file in the usual way. If the original file is returned
unmodified, and your script executes, the application is certainly vulnerable.