Date: Mon, 7 Feb 2000 18:28:08 -0500 (EST)
From: Steven Champeon
To: "[wd] - the Web Design community"
Subject: [WD]: more about the Cross-site scripting issue


Here's a good rundown of all the stuff in the other advisories:

 <http://microsoft.com/technet/security/CSOverv.asp>

I'm still not that excited about this, but that doesn't mean you
shouldn't be. Basically, if you provide public access to forms or
other mechanisms that allow a user to change the output of a page, you
need to be sure that your backend is properly escaping any input that
might potentially be dangerous given an expanded set of circumstances.
These circumstances, which used to be as simple as ensuring that you
don't allow SSI "exec" and HTML, now include many variations on that
theme, taking into account the ways different browsers interpret
different character sets. And that exposes a whole set of problems
in areas we've already been told to watch out for - such as dangerous
user-injected scripting. Read the advisories.

So, it's code review time for all of you dynamic Web site developers.
Bear in mind it's not just a question of pages that are *entirely*
dynamic, it also includes any pages that include dynamic *parts*.

By way of example, here's my DHTML GUIs "bookstore configurator":

 <http://dhtml-guis.com/>

Click on the link "choose which online bookseller you want to use here".
This will open /book/preferences.html, in a popup window. From here, it
is possible to set a cookie to one of the following:

 <option value="amazon.com">amazon.com
 <option value="amazon.co.uk">amazon.co.uk
 <option value="borders.com">borders.com
 <option value="fatbrain.com">fatbrain.com
 <option value="bn.com">barnesandnoble.com

Choosing one of these options and clicking the "make this my bookseller"
button sets the cookie "bookseller" to the value of the option you
selected. When you go back to the main window, after choosing a bookseller,
you'll notice that where it may have said "you do not currently have a
bookseller configured", it now says "your current bookseller is amazon.com"
or whatever. This text is chosen by way of an Apache XSSI:

 <!--#config errmsg="" -->
 <!--#set var="bookseller" value="$HTTP_COOKIE" -->
 <!--#if expr="$bookseller = /.*fatbrain.com.*/" -->
 (amazon text goes here)
 <!--#elif expr="$bookseller = /.*borders.com.*/" -->
 (borders.com text goes here)
 (etc.)
 <!--#else-->
 (default info goes here)
 <!--#endif-->

Now, if I'd actually used the cookie value (e.g., "amazon.com") when writing
a portion of the text that is displayed - by way of an SSI #echo, for example)
my site would be vulnerable to the XSS[1] problem. Someone could presumably
figure out a way to inject bad code/markup into the cookie, and if that
cookie's contents were included in any of the text above, it'd be a problem.
Consider the cookie with the contents:

 <a href="http://evil.hacker.org/do-me">amazon.com</a>

or

 %3Cscript%3Ealert%28%22gimme a password, yo!%22%29%3B%3C%2Fscript%3E

Get the idea? The URLencoded string would likely be unencoded by a
CGI script that sets the cookie, if I were using CGI instead of client
side Javascript. Of course, *I'm* not in this example, but you may be
somewhere. And when the contents of the cookie were written out to the
HTML (on the fly, or otherwise) you'd have just included a live script
that would scare the bejeezus out of your visitors. Or it might be more
subtle, like a long script that asked for your customer ID or worse,
then submitted it to evil.hacker.org via a form.submit.

Anyway - back to the DHTML GUIs example.

When it comes time to buy a book, you follow a link like this one:

 <http://dhtml-guis.com/cgi-bin/biblio-redirect/0764532677>

The biblio-redirect script is a Perl program that also uses the cookie
value, but only indirectly:

# check for cookie
if($ENV{'HTTP_COOKIE'} =~ /amazon\.co\.uk/i) {
  print STDOUT "Location: $amazon_uk\r\n\r\n";
  $where = "amazon.co.uk";
}  elsif($ENV{'HTTP_COOKIE'} =~ /borders\.com/i) {
  print STDOUT "Location: $borders_url\r\n\r\n";
  $where = "borders.com";

...

} else {
  print STDOUT "Location: $amazon_com\r\n\r\n";
  $where = "amazon.com";
}

...where "$amazon_uk" is a URL hardcoded at the top of the script but
which uses the ISBN/ASBN passed in by way of the PATH_INFO variable. If
you pass it garbage (e.g., "123456789X"), all that happens is the browser
is redirected to a garbage URL.

example:

 <http://dhtml-guis.com/cgi-bin/biblio-redirect/123456789X>

simply redirects to:

 <http://www.amazon.com/exec/obidos/ASIN/123456789X/dynamichtmlguis>

Which doesn't exist.

OK, so I'm pretty much covered. Here's where things could get interesting.
Let's say that someone wants to inject badness into this URL, say by way
of URLEncoded characters. Simply submit the GET below:

 <http://dhtml-guis.com/cgi-bin/biblio-redirect/%0D%0A%0D%0A>

but it simply translates into:

 Location: http://www.amazon.com/exec/obidos/ASIN/

because the "%0D%0A%0D%0A" is the double CRLF pair that ends the HTTP
headers. Whee. Luckily, this script's headers are parsed by Apache, so
it doesn't even affect the final header ouput. Things would be different
for an "nph-" script.

wasabi:1011 % telnet dhtml-guis.com 80
Trying 216.27.10.31...
Connected to dhtml-guis.com.
Escape character is '^]'.
GET /cgi-bin/biblio-redirect/%0D%0A%0D%0A HTTP/1.1
Host: dhtml-guis.com

HTTP/1.1 302 Found
Date: Mon, 07 Feb 2000 23:14:09 GMT
Server: Apache/1.3.9 (hesketh.com/inc) mod_perl/1.21
Location: http://www.amazon.com/exec/obidos/ASIN/
Transfer-Encoding: chunked
Content-Type: text/html

db 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>302 Found</TITLE>
</HEAD><BODY>
<H1>Found</H1>
The document has moved <A HREF="http://www.amazon.com/exec/obidos/ASIN/">here</A>.<P>
</BODY></HTML>

Here's the same example with an nph- script instead:

wasabi:1015 % telnet dhtml-guis.com 80
Trying 216.27.10.31...
Connected to dhtml-guis.com.
Escape character is '^]'.
GET /cgi-bin/nph-bibtest/%0D%0A%0D%0A HTTP/1.1
Host: dhtml-guis.com

Location: http://www.amazon.com/exec/obidos/ASIN/

/dynamichtmlguis

Hm. Good thing I'm using a hardcoded URL for the *beginning* of the
redirect. You always do that, too - right?

So, provided you don't trust or directly use input from a client when
making decisions on the server end, you're probably okay. But check.
It's really easy to assume that your query string or path info variables
are safe. It's not very smart, but it is really easy.

Be safe,
Steve

[1] Because "CSS" is a dumb acronym.


+----------------------------------------------------------------------+
     more info about webdesign-l: http://www.hesketh.com/lists/