[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <242a0a8f0610020644x37f26acate234bf012073e457@mail.gmail.com>
Date: Mon, 2 Oct 2006 09:44:27 -0400
From: "Brian Eaton" <eaton.lists@...il.com>
To: "Paul Szabo" <psz@...hs.usyd.edu.au>
Cc: bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk
Subject: Re: [Full-disclosure] IE UXSS (Universal XSS in IE, was Re: Microsoft Internet Information Services UTF-7 XSS Vulnerability [MS06-053])
On 10/2/06, Paul Szabo <psz@...hs.usyd.edu.au> wrote:
> This provides UXSS (Universal Cross-Site Scripting):
>
> http://apache.svr/+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-/ZZZ...
>
> (with a couple of hundred Zs) will do what we want. Works for https also:
>
> https://apache.svr/+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-/ZZZ...
>
> Can steal any Apache server (http or https) cookies. I do not have easy
> access to ISS servers to test whether similar attacks would work there.
>
> Will Apache fix (carefully escape) the error message? Will MS fix IE to
> not be so over-friendly?
This should only be possible if neither the HTTP headers nor the HTML
page specifies the character set of the document. If the server
doesn't tell IE the character set, the autodetection "feature" will
kick in, and the site is vulnerable. I just tested Apache 1.3.37 and
Apache 2.2.3, and both specified a content-type header of "text/html;
charset=iso-8859-1" for 404 responses, so the attack failed. My
browser was IE 6.0.2800.1106.
I'm guessing that you tested a server wth some kind of customized 404
response that neglected to include a charset specification. That's
not a vulnerability in Apache, that is poor site configuration.
(I do wish that IE didn't have this character set autodetection
feature, or at least that it was restricted to commonly used character
sets that don't use strange encodings for HTML metacharacters.)
Regards,
Brian
Powered by blists - more mailing lists