[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
- From: "Prasad Shenoy" <prasad.shenoy@xxxxxxxxx>
- Subject: Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
- Date: Wed, 3 Jan 2007 17:18:05 -0500
------=_Part_128106_25391671.1167862685614
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Also note that not all Open Parameters generate an XSS attack. From my
observation, the parameters that bail out are usually the ones that accept
single digit as input.
Thanks.
On 1/3/07, Dave Ferguson <gmdavef@gmail.com> wrote:
>
> 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@shocking.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@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.
> >
> >
> ----------------------------------------------------------------------------
> > 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]
> >
> >
>
>
> ----------------------------------------------------------------------------
> 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]
>
>
--
Prasad
------=_Part_128106_25391671.1167862685614
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Also note that not all Open Parameters generate an XSS attack. From my observation, the parameters that bail out are usually the ones that accept single digit as input.<br><br>Thanks.<br><br><div><span class="gmail_quote">
On 1/3/07, <b class="gmail_sendername">Dave Ferguson</b> <<a href="mailto:gmdavef@gmail.com";>gmdavef@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
One of the things I found most intriguing is the different keywords on<br>the URL that can be used. Adobe calls them "open parameters" and the<br>reference is here:<br><br><a href="http://partners.adobe.com/public/developer/en/acrobat/PDFOpenParameters.pdf";>
http://partners.adobe.com/public/developer/en/acrobat/PDFOpenParameters.pdf</a><br><br>As mentioned in the Di Paola and Fedon paper, the "fdf" parameter<br>provides another mechanism for injecting a URL to exploit XSRF.
<br><br>Dave F.<br><br>On 1/3/07, RSnake <<a href="mailto:rsnake@shocking.com";>rsnake@shocking.com</a>> wrote:<br>><br>> It's not a part of the URL string that is passed to the header:<br>><br>> <a href="http://www.google.com/appliance/pdf/google_gsa_datasheet.pdf#blah=javascript:alert(%22XSS%22)">
http://www.google.com/appliance/pdf/google_gsa_datasheet.pdf#blah=javascript:alert(%22XSS%22)</a>;<br>><br>> becomes:<br>><br>> GET /appliance/pdf/google_gsa_datasheet.pdf HTTP/1.0<br>> Host: <a href="http://www.google.com";>
www.google.com</a><br>> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:<a href="http://1.8.1.1";>1.8.1.1</a>) Gecko/20061204 Firefox/2.0.0.1<br>> Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=
0.9,text/plain;q=0.8,image/png,*/*;q=0.5<br>> Accept-Language: en-us,en;q=0.5<br>> Accept-Encoding: gzip,deflate<br>> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7<br>> Keep-Alive: 300<br>> Proxy-Connection: keep-alive
<br>> Pragma: no-cache<br>><br>> So I think your idea was partly good, the 301 redirection will knock off<br>> the URL fragment, but it has nothing to do with GET vs POST, and you'll<br>> need to redirect it to a unique token to prevent infinite loops or
<br>> someone just forwarding to a guessable token.<br>><br>> -RSnake<br>> <a href="http://ha.ckers.org/";>http://ha.ckers.org/</a><br>> <a href="http://sla.ckers.org/";>http://sla.ckers.org/</a><br>> <a href="http://ha.ckers.org/fierce/";>
http://ha.ckers.org/fierce/</a><br>><br>><br>> On Wed, 3 Jan 2007, James Landis wrote:<br>><br>> > Why bother with the token handling? If the request URI is a PDF and it is a<br>> > POST or contains URL parameters, just 30x to the naked PDF. Otherwise it's
<br>> > safe to serve.<br>> ><br>> > -j<br>> ><br>> > On 1/3/07, Amit Klein <<a href="mailto:aksecurity@gmail.com";>aksecurity@gmail.com</a>> wrote:<br>> >><br>> >> Amit Klein wrote:
<br>> >> > pdp (architect) wrote:<br>> >> >> I will be very quick and just point to links where you can read about<br>> >> >> this issue.<br>> >> >><br>> >> >> It seams that PDF documents can execute JavaScript code for no
<br>> >> >> apparent reason by using the following template:<br>> >> >><br>> >> >><br>> >> >><br>> >> <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>> >> >><br>> >> >><br>> >> >> You must understand that the attacker doesn't need to have write
<br>> >> >> access to the specified PDF document. In order to get an XSS vector<br>> >> >> working you need to have a PDF file hosted on the target and that's<br>> >> >> all about it. The rest is just a matter of your abilities and desires.
<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>><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><br clear="all"><br>-- <br>Prasad<br>
------=_Part_128106_25391671.1167862685614--
Brought to you by http://www.webappsec.org
Search this site
|