This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Talk:PDF Attack Filter for Java EE

Revision as of 15:24, 26 May 2009 by Jeff Williams (talk | contribs) (Reverted edits by BocgeTlaca (Talk) to last version by Jeremy Ferragamo)

Jump to: navigation, search

Should this page be in the Countermeasures category and have a link off of

Absolutely - fixed

It seems there's a much simpler approach to preventing this vulnerability on the server-side that Adobe released back on January 9th (in addition to their browser plug-in patches).

The concept is you can prevent the JavaScript from executing in the browser all together and force the file to be sent to the local application (or at least get the Save/Run dialog as opposed to auto-execution).

1. Simply configure server to change MIME type header to "application/octet-stream" for pdf exetensions


2. Simply add a Content-Disposition Header with a value of "attachment; filename=yourfile.pdf"

There's a 3rd option with a custom code solution, but it seems like it would still require the 1st solution to truly work so it’s a viable alternative by itself but would be good in adding a layer of indirection to the physical resources (similar to dynamic indirect object referencing).

All of the details on how to configure this on a per-server basis (at least IIS 6.0, Apache 2.2.3) can be found here:

"Server-side workarounds to prevent potential cross-site scripting vulnerability in versions 7.0.8 and earlier of Adobe Reader and Acrobat"