Why bother with the token handling? If the request URI is a PDF and it is a
POST or contains URL parameters, just 30x to the naked PDF. Otherwise it's
safe to serve.
-j
On 1/3/07, Amit Klein <aksecurity@xxxxxxxxx> 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]
>
>