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

[RSnake <rsnake () shocking com>]

That's correct.  In doing some quick tests you can mitigate this if you
take the URL (let's say http://site.com/file.pdf) and 301 them to the
same file with an empty anchor tag:  http://site.com/file.pdf#

Of course that would cause an infinite loop since the empty anchor tag
is not visible to the webserver so the unique token is still required.

-RSnake
http://ha.ckers.org/
http://sla.ckers.org/
http://ha.ckers.org/fierce/

On Thu, 4 Jan 2007, Billy Hoffman wrote:

> You cannot filter this URLs, because a URL fragment denotes something
> inside of a resource. The server doesn't care what the fragment it. The
> HTTP request sent when you click on a URL with a fragment doesn't
> contain the fragment at all. This means a site cannot even implement a
> web application firewall or IDS rule to not serve a PDF. They can't tell
> the different between a PDF requested for legitimate reasons or a PDF
> requested as part of an attack.
>
>
>
> Short of removing all PDF's from a website, that site cannot ensure they
> are acting as an accomplice to exploit a user.
>
>
>
> Fun times,
>
> Billy Hoffman
>
> --
>
> Lead Researcher, SPI Labs
>
> SPI Dynamics Inc. - http://www.spidynamics.com
> <http://www.spidynamics.com/>
>
> Phone:  678-781-4800
>
> Direct:   678-781-4845
>
> ________________________________
>
> From: skarvin [mailto:skarvin () gmail com]
> Sent: Thursday, January 04, 2007 4:04 AM
> To: bugtraq () securityfocus com; websecurity () webappsec org
> Subject: Re: [WEB SECURITY] Universal XSS with PDF files: highly
> dangerous
>
>
>
> Hi all,
>
> Another possible solution is to use the Apache mod_security to filter
> that kind of urls.
>
> bye
>
> 2007/1/4, pdp (architect) < pdp.gnucitizen () googlemail com
> <mailto:pdp.gnucitizen () googlemail com> >:
>
> ahhh, fragment identifiers make sense to browsers only. they are not
> send to the server
>
> On 1/4/07, der wert <derwert () hotmail com> wrote:
> > The best solution I see would be to keep all pdf files in a non-web
> > accessible location on the web server, then have all the pdf files
> outputed
> > through a script such as a php script. In php you can check the what
> the
> > REQUEST_URI is, if it isn't equal to what you were expecting which
> would
> > mean extra parameters were taken away or added then you could just
> have the
> > php script not output the pdf file since that would mean someone had
> been
> > tampering with the URI.
> >
> > D
> >
> > ________________________________
> > Get free, personalized online radio with MSN Radio powered by Pandora.
> Try
> > it!
>
>
> --
> pdp (architect) | petko d. petkov
> http://www.gnucitizen.org
>
> ------------------------------------------------------------------------
> ----
> 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]
>
>
>
>
> --
> Un saludo,
>
> This message was written entirely with recycled electrons.
>
> blog: http://skarvin.blogspot.com
> main(){int j=1234;char t[]=":@abcdefghijklmnopqrstuvwxyz.\n",*i=
> "iqgbgxmsuspcpdofeqgbnek.";char *strchr(const char *,int);while(
> *i){j+=strchr(t,*i++)-t;j%=sizeof t-1;putchar(t[j]);} return 0;}
>
> skarvin