Re: recent 'cross site scripting' CERT advisory

[bill () DIAL PIPEX COM (Bill Thompson)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In the light of our discussion on cross site scripting I am
cross-posting
(with Steve's permission) a message from the online-news list which
describes
some ways the problem could be used in exploits.

- -- Start forwarded message
Subject: Re: Javascript "virus" in new CERT warning
From: Steve Bonisteel <steveb () typecast com>
Date: Fri, 04 Feb 2000 21:54:39 -0500
X-Message-Number: 9

At 03:11 PM 04/02/00 +0000, Adam Gaffin wrote:

> The CERT warning also has some ramifications for sites that run user
> forums. If you let your users use HTML in their postings, you
> should  figure out how to disable certain tags (script, embed,
> applet and  object).

[Assuming we're talking about cross-site scripting here...]

True, but if sites with user forums weren't already aware of this,
they should not be running Web-based bulletin board and chat rooms
:-)

I did some quick tests after the advisory and had no trouble at all
finding sites where some form of a cross-site scripting attack could
be introduced. Web sites that have implemented their own site-search
routines are particularly vulnerable.

Once a hole is found, then the browser-cookie thing is often wide
open (on sites using cookies, obviously), because it's common for
site programmers to trust their own cookies. I reviewed by *own* code
for various CGI applications and realized that, in all cases, my code
assumes only *I* could have set the cookie.

If everyone checks their code, I'd bet they'd find the same thing in
many cases.

The bottom line is that it's not a *script* problem: it's an
oversight on the part of Web developers (like me!).

How serious the problem is depends on a huge variety of factors on
each site.

For example: If your site puts a registered user's name in a cookie
and then reads that name field later for a personalized page that
says "Welcome back. Steve!" ... then it's *possible* that if, say,
your site-search application is open to CSS, people could find their
personalized page greeting them with "Welcome back, Pinhead!"

But what if an e-commerce site does the same thing, and prints what
it thinks is the user name on an order-entry form? In that case, an
application that doesn't parse the cookie for script code could
introduce a credit-card-stealing routine to the page.

That's just one example. There are all kinds a site-specific
variations that may or not use cookies. A direct, cross-site link to
a CGI shopping application "Checkout,"  as an example, would be a
high-probability way to introduce a malicious script into a form that
still appears to be working from the user's perspective.

One form of protection from a truly *cross-site* attack that I didn't
see mentioned in the CERT advisory is the trusty "HTTP_REFERER"
check. But then, with so many sites using affiliate programs to get
their search boxes and book-buying links distributed across the Web,
there may be few major e-commerce sites that block requests based on
the referral source.

In my tests, many of the *successful* search-engine attacks actually
"broke" the search. By that, I mean that the site returned a page
that complained in some way that the search was not successful -
sometime reporting a syntax error. But, in many of those cases, a
script was still successfully launched - a script that *could* have
altered a cookie, which might do its real work later.

Again, if we're talking about cross-site scripting, I haven't heard
of a "denial of service" kind of attack, as mentioned by Mr. Meyer.

Regards,
SRB

- --
Steve Bonisteel
TypeCast
- --- end forwarded message  --
Bill Thompson
Cambridge UK

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 Int. for non-commercial use
<http://www.pgpinternational.com>

iQA/AwUBOJ05OVNT/DkNet0bEQIf8wCghGCHG0RtMzVkffKx1Myx4yjBEmIAnR9G
g3YLwoAQsc97ue84EqplO5M2
=7KyT
-----END PGP SIGNATURE-----