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

From OWASP
Jump to: navigation, search
m (Is this a Countermeasure?)
 
 
(5 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
Should this page be in the Countermeasures category and have a link off of https://www.owasp.org/index.php/Category:Countermeasure?
 
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 released back on January 9th (in addition to their browser plug-in patches).
 +
 +
This filter does both of these things already, but only as a
 +
fallback. The first attempt is to get it to work in-browser
 +
by requiring a simple token.
 +
 +
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 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"
 +
http://www.adobe.com/support/security/advisories/apsa07-02.html

Latest revision as of 10:35, 26 May 2009

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 released back on January 9th (in addition to their browser plug-in patches).

This filter does both of these things already, but only as a
fallback. The first attempt is to get it to work in-browser
by requiring a simple token.

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