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

Difference between revisions of "Talk:PDF Attack Filter for Java EE"

From OWASP
Jump to: navigation, search
m
Line 2: Line 2:
  
 
  Absolutely - fixed
 
  Absolutely - fixed
 +
 +
 +
It seems there's a much simpler approach to preventing this vulnerability on the server-side that Adobe supposedly 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 OR 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 I don't think it’s a viable solution.
 +
 +
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"
 +
http://www.adobe.com/support/security/advisories/apsa07-02.html

Revision as of 15:49, 24 April 2007

Should this page be in the Countermeasures category and have a link off of https://www.owasp.org/index.php/Category:Countermeasure?

Absolutely - fixed


It seems there's a much simpler approach to preventing this vulnerability on the server-side that Adobe supposedly 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 OR 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 I don't think it’s a viable solution.

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" http://www.adobe.com/support/security/advisories/apsa07-02.html