Message-ID: <081820050248.20714.4303F7180009518A000050EA21602807480A9D0B0E039A9B979A9B@att.net>
Date: Thu Aug 18 03:49:10 2005
From: tuytumadre at att.net (tuytumadre@....net)
Subject: Internet Explorer 6 Meta Refresh Parsing
	Weakness

Why should Microsoft be accountable for the mistakes of webmasters? Have you even tested any of ther other browsers? Even if you have, a webmaster should indeed be responsible for blindly redirecting a user to a url supplied in input. This isn't an Internet Explorer mistake - it is a webmaster mistake, and quite a silly one at that.

Btw, if this message appears in your mailboxes twice, it's because I sent it twice (the first time I received a DNS failure message).

Regards,
Paul
Greyhats Security
http://greyhatsecurity.org


-------------- Original message from Moritz Naumann <info@...itz-naumann.com>: -------------- 


> -----BEGIN PGP SIGNED MESSAGE----- 
> Hash: SHA1 
> 
> 
> 
> SA0001 
> 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
> +++++ Internet Explorer 6 Meta Refresh Parsing Weakness +++++ 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
> 
> 
> PUBLISHED ON 
> Aug 17, 2005 
> 
> 
> PUBLISHED AT 
> http://moritz-naumann.com/adv/0001/ie6meta/0001.txt 
> 
> 
> PUBLISHED BY 
> Moritz Naumann IT Consulting & Services 
> Hamburg/Germany 
> http://moritz-naumann.com/ 
> 
> info AT moritz HYPHON naumann D0T com 
> GPG key: http://moritz-naumann.com/keys/0x277F060C.asc 
> 
> 
> AFFECTED PRODUCT OR SERVICE 
> Microsoft Internet Explorer 
> http://www.microsoft.com/windows/ie/ 
> 
> 
> AFFECTED VERSION 
> Version 6 up to release 6.0.2900.2180 (SP2 + all patches) 
> Possibly versions < 6.0 (untested) 
> 
> 
> BACKGROUND 
> While the format of 
> META http-equiv="refresh" 
> and 
> META name="refresh" 
> type HTML headers was never exactly defined by they W3C, web 
> browsers have been interpreting this instruction since early 
> releases. Web application developers got used to the clients' 
> behaviour and using this tag to initiate URL redirections 
> became common. 
> 
> As most web browsers, Internet Explorer 6 interprets this tag, 
> too. However, in contrary to other web browsers, IE6's HTML 
> parser uses a pretty loose rule set which facilitates 
> injection of malicious code into it when browsing web 
> applications which insufficiently sanitize user supplied 
> input. 
> 
> For example, a web application may use the following PHP code 
> (redirect.php) to redirect a web browser to a different URL: 
> 
> 
> > $goto = $_GET["goto"]; // Input sanitization omitted 
> $meta1 = ''; 
> echo $meta.$goto; 
> ?> 
> 
> 
> 
> Assuming this script is hosted in the web root on example.org, 
> the following HTML code would be returned on a request to 
> http://example.org/redirect.php?goto=localhost : 
> 
> 
> 
> 
> 
> 
> Obviously, a web application developer must make sure that no 
> malicious code can be injected along the 'goto' parameter passed 
> via the HTTP GET method. A common method to sanitize user input 
> would be to hardcode the protocol part of the URL ('http://') 
> contained in 'goto', and to URL-encode any double quotes. This 
> would assumely make it difficult to inject any malicious client 
> side code. 
> 
> 
> ISSUE 
> Unlickily, and in contrary to other web browsers, Internet 
> Explorer 6 allows multiple 'URL=' parts in the 'content' 
> attribute and will only interpret the last value given. 
> Resulting from this, it is still possible to inject code into a 
> web application using the input sanitization described above 
> which will be executed when using Internet Explorer 6. 
> 
> For example, Internet Explorer 6 will interpret the following 
> statement: 
> 
> URL parameter: 
> goto=;URL=javascript:alert('XSS'); 
> Resulting META tag: 
> content="0; URL=http://;URL=javascript:alert('XSS');"> 
> Resulting behaviour: 
> Displays Javascript alert with text 'XSS' 
> 
> Making use of Internet Explorers loose parsing, a code such as 
> this value of the 'goto' URL parameter will work, too: 
> 
> %20%20%20%20%20;UrL=jaVAscRIpt:alert('XSS'); 
> 
> will work, too. As any of ';', 'UrL', '=', 'jaVAscRIpt' and ':' 
> may be legal content passed to the traget web site (think of a 
> search term passed to a search engine), sanitizing this is not 
> too easy. 
> 
> As the expected behaviour would be that a web browser would 
> either return an error message for incorrect syntax or would 
> attempt to interpret anything after the first 'URL=' part as the 
> target URL, Internet Explorer behaves in a pretty uncommon way. A 
> fix on the user agent side would be the best solution for this 
> issue. 
> 
> 
> WORKAROUND 
> Client: Disable META REFRESH in Security Settings for the Internet 
> Zone. 
> Server: Perform thorough sanitization on your web applications. 
> 
> 
> SOLUTIONS 
> Microsoft will not provide a patch. 
> 
> 
> TIMELINE 
> Aug 04, 2005: Vendor informed 
> Aug 04, 2005: First vendor reply 
> Aug 17, 2005: Vendor finishes investigation, declares itself 
> unaccountabile 
> 
> 
> CREDIT 
> N/A 
> 
> 
> LICENSE 
> Creative Commons Attribution-ShareAlike License Germany 
> http://creativecommons.org/licenses/by-sa/2.0/de/ 
> 
> 
> -----BEGIN PGP SIGNATURE----- 
> Version: GnuPG v1.4.1 (GNU/Linux) 
> 
> iD8DBQFDA6WGn6GkvSd/BgwRAnIRAJ9sK7ub/JwoBwNQjtC8j4QxiVl3kwCfUNqi 
> o+WaJkCQ9LUzdLtNwdBungg= 
> =lNVL 
> -----END PGP SIGNATURE----- 
> _______________________________________________ 
> Full-Disclosure - We believe in it. 
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html 
> Hosted and sponsored by Secunia - http://secunia.com/ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050818/4ba7fb69/attachment.html

Powered by blists - more mailing lists