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

["James Landis" <jcl24@xxxxxxxxxxx>]

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

Associating a timestamp and IP address with this scheme eliminates this
attack.

On 1/4/07, Amit Klein <aksecurity@gmail.com> wrote:
>
> Guy Podjarny wrote:
> > 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).
> >
> >
> Here's an attack against this scheme:
>
> Attacker sends the user a link to http://www.attacker.site/script.cgi
>
> When the user requests http://www.attacker.site/script.cgi, the
> script.cgi requests file.pdf from vuln.site. It gets back a redirection
> URL and a session cookie. Then, it creates a Flash object that requests
> the URL with an injected Cookie header (with the session cookie) and
> serves this to the victim client. Voila.
>
>
>
> ----------------------------------------------------------------------------
> 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_14068_31517063.1167958951883
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Associating a timestamp and IP address with this scheme eliminates this attack.<br><br><div><span class="gmail_quote">On 1/4/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;">Guy Podjarny wrote:<br>&gt; Another similar option is to use a single-use random value (not
<br>&gt; encrypted), that gets invalidated after it&#39;s served back.<br>&gt;<br>&gt; You can save the random value on the (non persistent) session<br>&gt; (server-side), and serve the PDF only if the correct random value is
<br>&gt; provided.<br>&gt; Once a random value has been used, it&#39;s cleared (single-use).<br>&gt; In any case where the wrong value is provided - recreate a random value,<br>&gt; save it on the session, and redirect to the PDF with it (same behavior
<br>&gt; as when the token isn&#39;t provided at all).<br>&gt;<br>&gt;<br>Here&#39;s an attack against this scheme:<br><br>Attacker sends the user a link to <a href="http://www.attacker.site/script.cgi";>http://www.attacker.site/script.cgi
</a><br><br>When the user requests <a href="http://www.attacker.site/script.cgi";>http://www.attacker.site/script.cgi</a>, the<br>script.cgi requests file.pdf from vuln.site. It gets back a redirection<br>URL and a session cookie. Then, it creates a Flash object that requests
<br>the URL with an injected Cookie header (with the session cookie) and<br>serves this to the victim client. Voila.<br><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_14068_31517063.1167958951883--