[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
- From: "James Landis" <jcl24@xxxxxxxxxxx>
- Subject: Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous
- Date: Wed, 3 Jan 2007 16:56:46 -0500
------=_Part_90542_20776747.1167861406645
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Ah, I misread the exploit URL and saw parameter data not anchor information.
Yes you're right, a redirect by itself really doesn't seem to be usable
unless you can ensure that it only happens once. Either way, you're
maintaining state information.
-j
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.
>
------=_Part_90542_20776747.1167861406645
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Ah, I misread the exploit URL and saw parameter data not anchor information. Yes you're right, a redirect by itself really doesn't seem to be usable unless you can ensure that it only happens once. Either way, you're maintaining state information.
<br><br>-j<br><br><div><span class="gmail_quote">On 1/3/07, <b class="gmail_sendername">RSnake</b> <<a href="mailto:rsnake@shocking.com";>rsnake@shocking.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;">
<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></blockquote></div><br>
------=_Part_90542_20776747.1167861406645--
Brought to you by http://www.webappsec.org
Search this site
|