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-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0701031316510.27544@fingers.shocking.com>
Date: Wed, 3 Jan 2007 13:21:29 -0800 (PST)
From: RSnake <rsnake@...cking.com>
To: James Landis <jcl24@...nell.edu>
Cc: Amit Klein <aksecurity@...il.com>, bugtraq@...urityfocus.com,
	Web Security <websecurity@...appsec.org>
Subject: Re: [WEB SECURITY] Universal XSS with PDF files: highly dangerous


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.