Bugtraq mailing list archives
RE: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
From: "Guy Podjarny" <gpodjarny () watchfire com>
Date: Thu, 4 Jan 2007 17:46:19 -0500
Another similar option is to use a single-use random value (not encrypted), that gets invalidated after it's served back. You can save the random value on the (non persistent) session (server-side), and serve the PDF only if the correct random value is provided. Once a random value has been used, it's cleared (single-use). In any case where the wrong value is provided - recreate a random value, save it on the session, and redirect to the PDF with it (same behavior as when the token isn't provided at all). So the flow is: IF the URL Session[X] != null (we have a previously created random val) AND request contains token_query AND token_query==Session[X]: Session[X] = null -- > Clear the token (it's only good for one use) serve the PDF resource as an in-line resource ELSE: calculate X = new random token value Session["token"] = X -- > save X on session (works for that user only) redirect to file.pdf?token_query=X Time delays can be added for extra security, but since the session isn't persistent, it'll usually not be required. One more note about the redirect: It seems that firefox retains the fragment portion when you redirect. So if you're browsing: http://server/page.aspx#target And you redirect to http://server/page.aspx, Firefox will keep the #target fragment! To work around this, you can redirect to http://server/page.aspx#a - by adding a fragment to your redirect, you make firefox get rid of the old one. Cheers, Guypo -----Original Message----- From: Amit Klein [mailto:aksecurity () gmail com] Sent: Thursday, January 04, 2007 4:38 PM To: bugtraq () securityfocus com; Web Security 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
------------------------------------------------------------------------ ---- The Web Security Mailing List: http://www.webappsec.org/lists/websecurity/ The Web Security Mailing List Archives: http://www.webappsec.org/lists/websecurity/archive/ http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
Current thread:
- Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous, (continued)
- Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous bugtraq (Jan 04)
- RE: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Martin O'Neal (Jan 08)
- Message not available
- Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Amit Klein (Jan 08)
- Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous RSnake (Jan 08)
- Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Amit Klein (Jan 08)
- Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous RSnake (Jan 08)
- Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Amit Klein (Jan 08)
- Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Brian Eaton (Jan 09)
- RE: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Marvin Simkin (Jan 09)
- Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Ralph Angenendt (Jan 10)
- RE: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Guy Podjarny (Jan 08)
- Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Amit Klein (Jan 08)
- RE: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Tom Spector (Jan 09)
- Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous pdp (architect) (Jan 03)
- Re: Universal XSS with PDF files: highly dangerous ascii (Jan 03)
- Re: Universal XSS with PDF files: highly dangerous Thierry Zoller (Jan 04)
- RE: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Larry Seltzer (Jan 03)
- Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Jim Manico (Jan 04)