[<prev] [next>] [day] [month] [year] [list]
Message-ID: <9943310A8769B24FB590AEBFCD7B9931E63396@mymail.aspectsecurity.com>
Date: Fri, 5 Jan 2007 01:45:34 -0500
From: "Jeff Williams" <jeff.williams@...ectsecurity.com>
To: <bugtraq@...urityfocus.com>
Subject: Re: Universal XSS with PDF files: highly dangerous
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@...il.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
>
Powered by blists - more mailing lists