Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

["James Landis" <jcl24@xxxxxxxxxxx>]

------=_Part_88065_4689961.1167853143273
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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@gmail.com> 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]
>
>

------=_Part_88065_4689961.1167853143273
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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&#39;s safe to serve.<br><br>-j<br><br><div><span class="gmail_quote">On 1/3/07, 
<b class="gmail_sendername">Amit Klein</b> &lt;<a href="mailto:aksecurity@gmail.com";>aksecurity@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Amit Klein wrote:<br>&gt; pdp (architect) wrote:<br>&gt;&gt; I will be very quick and just point to links where you can read about<br>&gt;&gt; this issue.<br>&gt;&gt;<br>&gt;&gt; It seams that PDF documents can execute JavaScript code for no
<br>&gt;&gt; apparent reason by using the following template:<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; <a href="http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here";>http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_here
</a><br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; You must understand that the attacker doesn&#39;t need to have write<br>&gt;&gt; access to the specified PDF document. In order to get an XSS vector<br>&gt;&gt; working you need to have a PDF file hosted on the target and that&#39;s
<br>&gt;&gt; all about it. The rest is just a matter of your abilities and desires.<br>&gt;&gt;<br>&gt; Amazing, and kudos to Sven Vetsch who found this.<br>&gt;<br>Oops, seems that the credit went to the wrong guy. Actual credit go to
<br>Stefano Di Paola, with contributions from Giorgio Fedon (IE Dos, UXSS<br>Analysis) and Elia Florio (Poc and Code Execution analysis).<br><br>BTW, one way to mitigate this is for the server, upon receiving a<br>request to 
file.pdf (without a valid query+cookie pair, see below), to<br>redirect it to file.pdf?token_query=X (where X is an unpredictable, high<br>entropy string) accompanied with a Set-Cookie header for a cookie named<br>say &quot;token_cookie&quot; with value X and short expiration period (
e.g. 10<br>seconds). The browser will then respond with a request to<br>file.pdf?token_query=X with Cookie token_cookie=X. At this point, if the<br>server receives token_query==token_cookie, the server knows this is a<br>
legit request (i.e. without fragment), and it can safely serve the PDF<br>resource.<br><br>I suppose this can be implemented easily as an Apache module/ISAPI/NSAPI<br>filters.<br><br>-Amit<br><br>----------------------------------------------------------------------------
<br>The Web Security Mailing List:<br><a href="http://www.webappsec.org/lists/websecurity/";>http://www.webappsec.org/lists/websecurity/</a><br><br>The Web Security Mailing List Archives:<br><a href="http://www.webappsec.org/lists/websecurity/archive/";>
http://www.webappsec.org/lists/websecurity/archive/</a><br><a href="http://www.webappsec.org/rss/websecurity.rss";>http://www.webappsec.org/rss/websecurity.rss</a> [RSS Feed]<br><br></blockquote></div><br>

------=_Part_88065_4689961.1167853143273--