|
BugTraq
Universal XSS with PDF files: highly dangerous Jan 03 2007 02:20AM pdp (architect) (pdp gnucitizen googlemail com) (5 replies) Re: Universal XSS with PDF files: highly dangerous Jan 08 2007 07:27PM The Anarcat (anarcat anarcat ath cx) Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Jan 04 2007 10:00AM HASEGAWA Yosuke (yosuke hasegawa gmail com) Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Jan 03 2007 09:54PM Jean-Jacques Halans (halans gmail com) (2 replies) Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Jan 04 2007 12:44AM Jim Manico (jim manico net) (1 replies) Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Jan 04 2007 01:08AM RSnake (rsnake shocking com) RE: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Jan 03 2007 11:22PM Larry Seltzer (Larry larryseltzer com) Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Jan 03 2007 08:37AM sven vetsch disenchant ch (2 replies) Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Jan 03 2007 10:27AM pdp (architect) (pdp gnucitizen googlemail com) Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Jan 03 2007 05:17AM Amit Klein (aksecurity gmail com) (1 replies) Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous Jan 03 2007 06:15PM Amit Klein (aksecurity gmail com) (1 replies) |
|
Privacy Statement |
most cases. However, if the attacker is able to upload PDF documents,
he/she can craft one that will produce the desired result as soon as
it gets opend by the user. This can be achieved by setting the PDF
file to redirect. David K. from michaeldawe.org had a POC somewhere.
This attack vector is limited due to the fact that the attacker needs
to upload malicious PDF files, but it is still very dangerous. Think
about email attachments. I haven't tested this idea myself, though.
On 1/3/07, Amit Klein <aksecurity (at) gmail (dot) com [email concealed]> wrote:
> Amit Klein wrote:
> > pdp (architect) wrote:
> >> I will be very quick and just point to links where you can read about
> >> this issue.
> >>
> >> It seams that PDF documents can execute JavaScript code for no
> >> apparent reason by using the following template:
> >>
> >>
> >> http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_
here
> >>
> >>
> >> You must understand that the attacker doesn't need to have write
> >> access to the specified PDF document. In order to get an XSS vector
> >> working you need to have a PDF file hosted on the target and that's
> >> all about it. The rest is just a matter of your abilities and desires.
> >>
> > Amazing, and kudos to Sven Vetsch who found this.
> >
> Oops, seems that the credit went to the wrong guy. Actual credit go to
> Stefano Di Paola, with contributions from Giorgio Fedon (IE Dos, UXSS
> Analysis) and Elia Florio (Poc and Code Execution analysis).
>
> BTW, one way to mitigate this is for the server, upon receiving a
> request to file.pdf (without a valid query+cookie pair, see below), to
> redirect it to file.pdf?token_query=X (where X is an unpredictable, high
> entropy string) accompanied with a Set-Cookie header for a cookie named
> say "token_cookie" with value X and short expiration period (e.g. 10
> seconds). The browser will then respond with a request to
> file.pdf?token_query=X with Cookie token_cookie=X. At this point, if the
> server receives token_query==token_cookie, the server knows this is a
> legit request (i.e. without fragment), and it can safely serve the PDF
> resource.
>
> I suppose this can be implemented easily as an Apache module/ISAPI/NSAPI
> filters.
>
> -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]
>
>
--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org
[ reply ]