misc. cross site scripting issues

[marcs () ZNEP COM (Marc Slemko)]

There have been a few random "cross site scripting" related issues that I
have run into 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

Details:

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.  I 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 I
were a Netscape customer using this product, I 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
======================================================================

I 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.  I 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

I find 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 this week.  Interestingly
enough, this exact same problem with Hotmail was reported in bugtraq
six months ago or so, 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.  I 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.  I 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.  I find this to be just 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 I posted about the other day.  But wait, it gets worse.
With Navigator, you can use a URL such as:

    <A HREF="ftp://ftp.netscape.com/<script">ftp://ftp.netscape.com/<script</A>>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, I noticed a
few NT ones that do.  However, I think 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.

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.