Bugtraq mailing list archives

Re: Universal XSS with PDF files: highly dangerous


From: "Jeff Williams" <jeff.williams () aspectsecurity com>
Date: Fri, 5 Jan 2007 01:45:34 -0500

Hi,

I've implemented a Java EE filter that implements this algorithm.  Thanks to Amit for detailing this for everyone.

I've tested with Firefox and it appears to work in all three cases.  The deployment is simple, you just drop in the 
class file and add a few lines to web.xml.  There are a few configuration options, like token name, timeout, and 
encryption password.  Please help us make sure the implementation is right.

http://www.owasp.org/index.php/PDF_Attack_Filter_for_Java_EE

Thanks,

--Jeff
 
Jeff Williams, Chair
The OWASP Foundation
"Dedicated to finding and fighting the causes of insecure software"

-------------------------

On 1/4/07, Amit Klein <aksecurity () gmail com> wrote:
Updates:

1. In private communication, Tom Spector observed that the cookie
doesn't add any significant security. In retrospect, I could have
omitted it completely. It's there as a remnant of a previous idea I had.
In other words, I see nothing wrong with the following, simpler and more
elegant algorithm ("Look ma - no cookie"):

IF the URL doesn't contain token_query, then:
  calculate X=encrypt_with_key(server_time, client_IP_address)
  redirect to file.pdf?token_query=X

ELSE IF the URL contains token_query, and
decrypt(token_query).IP_address==client_IP_address and
decrypt(token_query).time>server_time-10sec
  serve the PDF resource as an in-line resource

ELSE
  serve the PDF resource as a "save to disk" resource via a proper
choice of the Content-Type header (and/or an attachment, via
Content-Disposition).


And big thanks to Tom who pointed this out.


-Amit






Current thread: