Observations and insights from the Security PS Team.

Cross-Site Scripting in Adobe Plug-In

You may have seen the recent flurry of news stories surrounding a cross-site scripting (XSS) vulnerability in Adobe's PDF browser plug-in. In case you missed it, here are a few articles that provide an overview of the problem:

Washington Post
USA Today
Information Week

Essentially, the vulnerability provides yet another way for an attacker to execute JavaScript in another user's browser when the user follows a specially crafted URL to a PDF file. By adding JavaScript commands to parameters in the URL, attackers can steal cookies and sensitive data, change the appearance or behavior of the site, and redirect users off-site in phishing attacks. To make matters worse, the attack string (the part that does the damage) in the URL is never even sent to the web server, so the attack can't be stopped by having the server look for dangerous JavaScript in requests for PDF files.

So, what can an organization do to protect its users from being attacked through PDF files stored on its web site? There is no foolproof solution, but the best approach is trying to prevent the vulnerable Adobe browser plug-in from running, which can be accomplished in some browsers by changing HTTP headers in the web server response. There are two relevant headers that could be changed:
  Content-Type: application/octet
Content-Disposition: Attachment

Both of these headers instruct the browser to download the file instead of opening it in the vulnerable Adobe plugin. We have followed this approach on our own servers and it prevents the attack in most cases. This morning, Google and Yahoo followed suit with a similar fix.

Here are instructions for adding these headers to the server response for PDF documents in Apache and IIS.


Add these lines to the httpd.conf file inside the <Directory> tags.
  AddType application/octet .pdf
<Files *.pdf>
Header add Content-Disposition "Attachment"

IIS (tested in 6.0, these instructions may vary some for older versions of IIS):

Change MIME type to "application/octet":
  1. Start > Run > Enter compmgmt.msc. The Computer Management console appears.
  2. Right click on the Services and Applications > Internet Information Services (IIS Manager)
  3. Select Properties > MIME Types
  4. Scroll down to ".pdf". The MIME type should be "application/pdf". Change this to "application/octet".
  5. Click OK twice.

Add Content-Disposition header (this must be done by directory or for each PDF file individually):
  1. In the IIS Management tool (not in Windows Explorer), select a directory with PDF content or an individual PDF file.
  2. Right-click on the directory or file.
  3. Select Properties.
  4. Click the HTTP Headers tab.
  5. In the Custom HTTP Headers section, click Add.
  6. A dialog appears. In the "Custom-header name" field enter "Content-disposition". In the "Custom-header value field, enter "Attachment".
  7. Click OK twice.
  8. Restart IIS (command line: iisreset).
  9. Check that PDF content from the browser now prompts the user to "download" rather than simply opening the content.

This is not a 100% solution, but changing the HTTP response headers will go a long way toward reducing the risk to users of your site. Although this works in current versions of the more popular browsers, it is possible that some browsers could ignore these headers and open the PDF with the Adobe plugin anyway.

It may also be possible to address the vulnerability programmatically. Some examples have been published for Java and .Net. These examples have not been tested by Security PS, but they have been proposed as a way to help prevent attackers from exploiting the Adobe plug-in vulnerability.

If you implement these or other changes, please let us know about your experience.
    Blogger Comment
    Facebook Comment


  1. I set the properties on my local web server following your articles instructions. However, I found that by adding the Content-Disposition header (step 6) causes the browser to want to download the .aspx file as well.

  2. Brad,

    Thanks for bringing this up. These headers should only be set for PDF files. Setting the header on other file types will cause those to be downloaded as well. In IIS, I don't know of a way to set the Content-Disposition header for all PDF files globally. You can only set the header on a per-directory or per-file basis.

    Also, these instructions are only applicable to PDF files that are served directly by the web server. If your PDFs are generated by the application or fetched from the filesystem by a dynamic page, you can't set the Content-Disposition header in the web server configuration; it must be set in the application code. In ASP.NET, setting these headers might look like this:

    Response.ContentType = "application/octet";
    Response.AddHeader("Content-Disposition", "attachment");