Message-id: <459D73C4.5060709@gmail.com>
Date: Thu, 04 Jan 2007 23:38:12 +0200
From: Amit Klein <aksecurity@...il.com>
To: bugtraq@...urityfocus.com,
	Web Security <websecurity@...appsec.org>
Subject: Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

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.


2. While thinking more about this solution, I observed that if the 
attacker can have an "agent" sharing the same IP address with the victim 
(by agent I mean an entity that can communicate with the target web site 
and read back its response data), then the algorithms I suggested will 
not be effective. Note that an attacker can share IP address with the 
victim when both share a forward proxy (e.g. some universities and 
ISPs), or when the attacker and victim share the same machine 
(multi-user environment). Still, that narrows down the attack surface 
significantly.

Thanks,
-Amit



Amit Klein wrote:
> It seems that I forgot all about Flash when I wrote that (the 
> irony...). The solution I proposed is not secure enough as-is. It is 
> trivial to write a SWF object that will request 
> file.pdf?token_query=123 and add a "Cookie: token_cookie=123". This is 
> discussed in yours truly's "Forging HTTP request headers with Flash" ( 
> http://www.securityfocus.com/archive/1/441014) and in Rapid7's "Rapid7 
> Advisory R7-0026 - HTTP Header Injection Vulnerabilities in the Flash 
> Player Plugin" ( http://www.rapid7.com/advisories/R7-0026.jsp).
> Even adding cryptographic secret, time-based entropy or use counter 
> doesn't help - all this can be circumvented by a server script on the 
> attacker's site preparing the HTTP request and communicating it in 
> real-time to the SWF object at the victim's browser.
>  
> The solution I could come up with is to tie X to the IP address of the 
> client. Yes, I know - it's ugly, and it doesn't work 100% of the 
> cases. But you stand nothing to lose if you simply fall back to the 
> "save to disk" option, suggested by an anonymous SlashDot submitter ( 
> http://it.slashdot.org/comments.pl?sid=214868&threshold=1&commentsort=0&mode=thread&cid=17450834 
> <http://it.slashdot.org/comments.pl?sid=214868&threshold=1&commentsort=0&mode=thread&cid=17450834>).
>  
> So the more secure solution, as I see it, is as following:
>  
> Apply only for PDF resources:
>  
> 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 with Set-Cookie: token_cookie=X 
> to expire at server_time+10sec.
>  
> ELSE IF the URL contains token_query, and token_query==token_cookie 
> 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).
>  
> Hopefully this should work. But it's definitely less elegant than the 
> original (flawed) suggestion.
>  
> -Amit
>  

Powered by blists - more mailing lists