If you ever use user-supplied data in a meta refresh, you have to be careful or your Internet Explorer users will be at risk:
-------------------
-----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.txtPUBLISHED 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.ascAFFECTED 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:
<!-- Common HTML 4.01 header except "</head>" goes here -->
<?php
$goto = $_GET["goto"]; // Input sanitization omitted
$meta1 = '<META http-equiv="refresh" content="0; URL=http://';
$meta2 = '">';
echo $meta.$goto;
?>
</head>
<!-- Common HTML 4.01 <body> goes here -->
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 :
<!-- Common HTML 4.01 header except "</head>" goes here -->
<META http-equiv="refresh" content="0; URL=http://localhost">
</head>
<!-- Common HTML 4.01 <body> goes here -->
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.htmlHosted and sponsored by Secunia -
http://secunia.com/
