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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3403d5c50701031358v4481e958kfbafccc85c5d64df@mail.gmail.com>
Date: Wed, 3 Jan 2007 15:58:12 -0600
From: "Dave Ferguson" <gmdavef@...il.com>
To: websecurity@...appsec.org, bugtraq@...urityfocus.com
Subject: Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous

One of the things I found most intriguing is the different keywords on
the URL that can be used.  Adobe calls them "open parameters" and the
reference is here:

http://partners.adobe.com/public/developer/en/acrobat/PDFOpenParameters.pdf

As mentioned in the Di Paola and Fedon paper, the "fdf" parameter
provides another mechanism for injecting a URL to exploit XSRF.

Dave F.

On 1/3/07, RSnake <rsnake@...cking.com> wrote:
>
> It's not a part of the URL string that is passed to the header:
>
> http://www.google.com/appliance/pdf/google_gsa_datasheet.pdf#blah=javascript:alert(%22XSS%22);
>
> becomes:
>
> GET /appliance/pdf/google_gsa_datasheet.pdf HTTP/1.0
> Host: www.google.com
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
> Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Proxy-Connection: keep-alive
> Pragma: no-cache
>
> So I think your idea was partly good, the 301 redirection will knock off
> the URL fragment, but it has nothing to do with GET vs POST, and you'll
> need to redirect it to a unique token to prevent infinite loops or
> someone just forwarding to a guessable token.
>
> -RSnake
> http://ha.ckers.org/
> http://sla.ckers.org/
> http://ha.ckers.org/fierce/
>
>
> On Wed, 3 Jan 2007, James Landis wrote:
>
> > 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@...il.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.
>
> ----------------------------------------------------------------------------
> 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]
>
>