This is a filter to block XSS attacks on PDF files served by Java EE applications. The details of the attack are discussed [http://www.gnucitizen.org/blog/danger-danger-danger/ elsewhere]. This filter implements a simple algorithm suggested by Amit Klein.

+

This is a filter to block XSS attacks on PDF files served by Java EE applications. The details of the attack are discussed [http://www.gnucitizen.org/blog/danger-danger-danger/ elsewhere]. This filter implements a simple algorithm suggested by Amit Klein. We've placed this software in the public domain to make it easy for anyone to use for any purpose. Please let us know if you're using it!

+

+

If you have static PDF files, you may not need this filter. Instead, you could change MIME type or the Content-Disposition Header as [http://www.adobe.com/support/security/advisories/apsa07-02.html Adobe security advisory]. This will force the user to save the document rather than render it in the browser window.

==Approach==

==Approach==

Line 7:

Line 12:

This attack relies on having some javascript in an anchor after the url like this: http://www.site.com/file.pdf#blah=javascript:alert(document.cookie);

This attack relies on having some javascript in an anchor after the url like this: http://www.site.com/file.pdf#blah=javascript:alert(document.cookie);

−

We're going to use a Java EE filter to intercept requests before they reach our application. We could have just stripped off the anchor part of the URL, but that's not how HTTP works. The anchor isn't actually sent to the application, so we have to get much trickier.

+

So the idea is to strip off the anchor. Unfortunately for us, the browser doesn't send the anchor along with the HTTP request. So we can't just strip it off.

+

+

Therefore, we're going to use a redirect to steer the browser to a link without the anchor containing the attack. Well, actually it turns out that we have to overwrite the anchor with something else, so we're going to use "#a".

+

+

But there's one last problem to overcome. Since the browser doesn't send the anchor, the new request will look exactly like the request generated by the redirect. With no way of telling the original request from the one generated by our redirect, we'll create an infinite loop.

+

+

So to differentiate them, we're going to add a temporary token to the URL in the redirect, which we'll verify when it arrives. We don't want an attacker forging this token, so we're going to encrypt the user's source IP address along with a timestamp. If a request shows up for the PDF file without a valid token, we'll reject it. Or actually, we can force it to be saved to disk, thus preventing the attack from working.

−

We're going to use a redirect to set the browser's URL to the same URL without the anchor, thus preventing the attack. But we have to be able to tell the difference between the first request, and the redirected request. So we're going to add a temporary token to the URL, which we'll verify when it arrives. We don't want an attacker forging one of these tokens, so we're going to encrypt the user's source IP address along with a timestamp.

+

This way, only an attacker from the same IP address who can trick you into clicking a link within 10 seconds of creating it can attack you. Not perfect, but certainly raises the bar quite a bit.

==Download==

==Download==

Line 19:

Line 30:

==Setup==

==Setup==

−

The first step is to add the filter to our application. All we have to do is put the PDFAttackFilter class on our application's classpath, probably by putting it in the classes folder in WEB-INF. You can extract the class file from the

+

The first step is to add the filter to our application. All we have to do is put the PDFAttackFilter class on our application's classpath, probably by putting it in the classes folder in WEB-INF. The class file should be in a folder structure that matches the package (org -> owasp -> filters -> PDFAttackFilter). You can extract the class file from the zip file.

−

Then we just have to add the following to our web.xml. You should paste this in right above your servlet definitions. You'll want to change the mapping so that it only applies to URL's that serve a PDF file. You could use /*.pdf, but you may have servlets that stream PDF files that down't end in .pdf.

+

Then we just have to add the following to our web.xml. You should paste this in right above your servlet definitions. You'll want to change the mapping so that it only applies to URLs that serve a PDF file. You could use *.pdf, but you may have servlets that stream PDF files that don't end in .pdf.

<pre>

<pre>

Line 46:

Line 57:

</filter-mapping>

</filter-mapping>

</pre>

</pre>

+

+

Depending on your application, it may be difficult to map all the URLs that lead to PDF files. You can map multiple url-patterns to the filter if necessary. In theory, it might be possible to send the redirect only if a response with content-type application/pdf. Then you could map the filter to apply to ALL requests. If there is demand for this feature, let us know.

==Source Code==

==Source Code==

Line 53:

Line 66:

<pre>

<pre>

−

package org.owasp.filters;

+

/**

+

* Software published by the Open Web Application Security Project (http://www.owasp.org)

There are not many dependencies here, just the standard Java EE environment. You can compile with:

+

+

javac -classpath j2ee.jar -d . *.java

+

+

Then just copy the 'org' folder that gets created to the WEB-INF/classes folder.

+

+

'''Comment: ''' In the decryptString method, it is necessary to strip the "#a" from the end of the str parameter, otherwise an IllegalBlockSizeException will be thrown with "Input length must be multiple of 8 when decrypting with padded cipher".

[[Category:How To]]

[[Category:How To]]

[[Category:OWASP Java Project]]

[[Category:OWASP Java Project]]

+

[[Category:OWASP_Validation_Project]]

+

[[Category:Countermeasure]]

+

[[Category: Control]]

Latest revision as of 10:25, 26 May 2009

Status

Released 24/4/2007

Overview

This is a filter to block XSS attacks on PDF files served by Java EE applications. The details of the attack are discussed elsewhere. This filter implements a simple algorithm suggested by Amit Klein. We've placed this software in the public domain to make it easy for anyone to use for any purpose. Please let us know if you're using it!

If you have static PDF files, you may not need this filter. Instead, you could change MIME type or the Content-Disposition Header as Adobe security advisory. This will force the user to save the document rather than render it in the browser window.

Approach

So the idea is to strip off the anchor. Unfortunately for us, the browser doesn't send the anchor along with the HTTP request. So we can't just strip it off.

Therefore, we're going to use a redirect to steer the browser to a link without the anchor containing the attack. Well, actually it turns out that we have to overwrite the anchor with something else, so we're going to use "#a".

But there's one last problem to overcome. Since the browser doesn't send the anchor, the new request will look exactly like the request generated by the redirect. With no way of telling the original request from the one generated by our redirect, we'll create an infinite loop.

So to differentiate them, we're going to add a temporary token to the URL in the redirect, which we'll verify when it arrives. We don't want an attacker forging this token, so we're going to encrypt the user's source IP address along with a timestamp. If a request shows up for the PDF file without a valid token, we'll reject it. Or actually, we can force it to be saved to disk, thus preventing the attack from working.

This way, only an attacker from the same IP address who can trick you into clicking a link within 10 seconds of creating it can attack you. Not perfect, but certainly raises the bar quite a bit.

Download

The source code (one file) and the compiled class file are in a single zip file.

Setup

The first step is to add the filter to our application. All we have to do is put the PDFAttackFilter class on our application's classpath, probably by putting it in the classes folder in WEB-INF. The class file should be in a folder structure that matches the package (org -> owasp -> filters -> PDFAttackFilter). You can extract the class file from the zip file.

Then we just have to add the following to our web.xml. You should paste this in right above your servlet definitions. You'll want to change the mapping so that it only applies to URLs that serve a PDF file. You could use *.pdf, but you may have servlets that stream PDF files that don't end in .pdf.

Depending on your application, it may be difficult to map all the URLs that lead to PDF files. You can map multiple url-patterns to the filter if necessary. In theory, it might be possible to send the redirect only if a response with content-type application/pdf. Then you could map the filter to apply to ALL requests. If there is demand for this feature, let us know.

Source Code

This code has been only minimally tested. Please help us verify the approach and the implementation used here.

Compile

There are not many dependencies here, just the standard Java EE environment. You can compile with:

javac -classpath j2ee.jar -d . *.java

Then just copy the 'org' folder that gets created to the WEB-INF/classes folder.

Comment: In the decryptString method, it is necessary to strip the "#a" from the end of the str parameter, otherwise an IllegalBlockSizeException will be thrown with "Input length must be multiple of 8 when decrypting with padded cipher".