COMMAND
misc. cross site scripting issues
SYSTEMS AFFECTED
Most systems
PROBLEM
Marc Slemko found following. There have been a few random "cross
site scripting" related issues in the past month that people may
be interested in. Summary:
1. Netscape Enterprise server default 404 page is vulnerable
2. IIS5 default error pages are vulnerable
3. Don't forget the javascript entities
4. IE Ignores MIME types
5. IE sends cookies via http to every port
6. IE and Navigator interpret HTML in ftp directory listings
Netscape Enterprise server default 404 page is vulnerable
=========================================================
Well, iPlanet or whatever the marketing folks are calling it now:
marcs@alive:~$ telnet people.netscape.com 80
Trying 207.200.72.32...
Connected to www27.netscape.com.
Escape character is '^]'.
GET /notthere HTTP/1.0
Referer: "><B>foo
HTTP/1.1 404 Not found
Server: Netscape-Enterprise/4.0
Date: Mon, 13 Mar 2000 02:12:56 GMT
Content-type: text/html
Content-length: 291
Connection: close
<TITLE>Not Found</TITLE><H1>Not Found</H1> The requested object does not exist on this server. The link you followed is either outdated, inaccurate, or the server has been instructed not to let you have it. Please inform the site administrator of the <A HREF=""><B>foo">referring page</A>.
This can be avoided simply by specifying an explicit 404 document.
The disturbing part is Netscape's (erm... iPlanet's?) reaction
to this. Shortly after the CERT advisory came out, they had CERT
add a link to the bulletin to:
http://developer.iplanet.com/docs/technote/security/cert_ca2000_02.html
This page states:
Web Server Administrators: The CERT Advisory states that you
are "encouraged to apply patches as suggested by your vendor
to address this problem." There are no patches required for
the iPlanet(TM) Web Server products (formerly Netscape
Enterprise Server).
Unfortunately, as you can clearly see, this isn't true. Marc
notified the appropriate people at Netscape about this a few days
after they posted this information, and they claimed to have
updated the page but, despite repeated prompting, it obviously
never made it to the website.
Are there any other related problems in Netscape Enterprise? Have
they looked? If they have found any, would they tell you? If you
were a Netscape customer using this product, he would be quite
concerned about why they left information that they knew to be
incorrect be posted on their website for months, and about what
other problems the server may be vulnerable to.
IIS5 default error pages are vulnerable
=======================================
Do not know if this applies to any release version of IIS5 or only
prerelease versions that various sites such as www.microsoft.com
were running; www.microsoft.com is now running a fixed version,
not that it particularly matters much for www.microsoft.com. Marc
did notify Microsoft about this a while ago. IIS5 comes with a
bunch of default error pages. For example, the 404 page includes
a suggestion of:
Open the www.example.com home
Where example.com is the domain you are visiting and is a
hyperlink to the root of the webserver. This is generated by a
javascript function:
function Homepage(){
<!--
// in real bits, urls get returned to our script like this:
// res://shdocvw.dll/http_404.htm#http://www.DocURL.com/bar.htm
//For testing use DocURL = "res://shdocvw.dll/http_404.htm#https://www.microsoft.com/bar.htm"
DocURL = document.URL;
//this is where the http or https will be, as found by searching for :// but skipping the res://
protocolIndex=DocURL.indexOf("://",4);
//this finds the ending slash for the domain server
serverIndex=DocURL.indexOf("/",protocolIndex + 3);
//for the href, we need a valid URL to the domain. We search for the # symbol to find the begining
//of the true URL, and add 1 to skip it - this is the BeginURL value. We use serverIndex as the end marker.
//urlresult=DocURL.substring(protocolIndex - 4,serverIndex);
BeginURL=DocURL.indexOf("#",1) + 1;
urlresult=DocURL.substring(BeginURL,serverIndex);
//for display, we need to skip after http://, and go to the next slash
displayresult=DocURL.substring(protocolIndex + 3 ,serverIndex);
document.write('<A HREF="' + urlresult + '">' + displayresult + "</a>");
}
//-->
This javascript appears to be stolen from IE5, without some of
the security fixes that are in IE5 to stop it from having the
same problem. You could exploit it using a URL such as:
http://iis5server.example.com/notthere"></A><SCRIPT>alert(document.domain)</SCRIPT>#end
Marc finds this bug an interesting example, because of how it
works on the client side, with the client itself outputting the
javascript using other javascript and information local to the
client (ie. the "#end" is never sent to the server).
Don't forget the javascript entities
====================================
No, this is nothing new. But it bears repeating; Hotmail was
vulnerable to this up until it was fixed. Interestingly enough,
this exact same problem with Hotmail was reported in bugtraq, yet
it was never fixed. Hmm...
The issue is that Netscape supports a horrid concept called
"javascript entities" that can appear in attribute values. For
example:
<B &{alert(document.domain)};>
<IMG SRC="&{alert(document.domain)};">
IE doesn't support this, nor should it. But it is definitely
something that many sites miss out on, and is another example of
why trying to filter out bad things instead of only allowing known
good things is very very very hard to get right.
IE Ignores MIME types
=====================
No, this is nothing new and has long been known as an "IE is too
silly to follow standards" thing. But it is also a security
issue. IE will try to guess what MIME type to use to display
content, even if the server specifies a perfectly good one. Lets
use the Apache printenv script as an example; current versions
output as text/plain, which means there is no encoding of special
characters necessary or possible. Yet IE will decide, under some
situations, that it knows better and that the output should
really be interpreted as HTML. There is nothing that can be done
to encode this, since there is no encoding of special characters
for text/plain. This is caused entirely by IE's broken behavior.
There is no excuse for IE acting this way. It makes life a pain
for IE users, not only because it makes them see bogus content,
but also because if they use IE to make sure webpages they create
work, then they are done a disservice by not noticing that their
server may be sending the incorrect MIME type. They lose out all
around.
IE sends cookies via http to every port
=======================================
If you set a normal (ie. non-secure) cookie in IE, then IE will
send that cookie back to the server when making a HTTP connection
on any port, not just the port it was sent on. It is fairly well
known that IE does the same thing with HTTP authentication, which
is another security issue, but that is another problem.
The issue here is somewhat interesting; there are various common
non-HTTP servers that I can _almost_ convince to send back
responses to a HTTP request, including the request URL in an
error message, that IE will display as HTML. So you can almost
use a non-HTTP server to exploit the cross site scripting issue
by having IE make a HTTP request to it that will result in it
spitting back error messages because it doesn't understand HTTP.
We say "almost" because there are some special conditions that
are necessary to make it work, and I haven't found a way to quite
make it work with most common non-HTTP servers. Marc could make
it work with Navigator due to its bug that lets you make it send
newline characters in a request, but Navigator won't send the
cookie to other ports so it is of limited use. Maybe someone
else could come up with a realistic exploit of this.
When combined with the fact that IE sends cookies to every port,
this means it may be possible to exploit a non-HTTP server running
on a machine to steal cookies, or even HTTP basic authentication
info. Yet another evidence of how disturbing the current way that
security is implemented using HTTP is, and how deep the issues
are.
IE and Navigator interpret HTML in ftp directory listings
=========================================================
The heading says it all. If you can create a filename or
directory name on a ftp server with the appropriate characters,
IE and Navigator will interpret them as HTML. They will do the
same thing for files; the former isn't too reasonable, the latter
is unfortunately reasonable.
IE5 appears to not treat it as being in the same domain as http
access to the site for cookies. That is good.
Navigator, however, does send cookies meaning you can use a ftp
document to steal cookies. This is similar to the NNTP issue in
Navigator. But wait, it gets worse. With Navigator, you can use
a URL such as:
ftp://ftp.netscape.com/<script>alert(document.cookie)</script>/../../
and Navigator will execute the javascript when it displays the
directory listing, because it includes "Current directory is
/<script>alert(document.cookie)</script>/../../".
This, however, depends on the ftp server returning success when a
command like:
CWD /<script>alert(document.cookie)</script>/../../
is sent to it. Some do, some don't. In particular, Marc noticed
a few NT ones that do. However, he thinks you can probably
combine this with the Navigator bug that lets you send newline
characters to trick the server into sending responses that
Navigator will think mean that changing into the directory
succeeded, so that it will display the directory listing that
lets you exploit it.
SOLUTION
So add ftp servers (at the very least, ftp servers with anonymous
logins) to the list of things you may not be able to safely run on
the same server as web sites where cross site scripting related
issues matter.