Home page logo

bugtraq logo Bugtraq mailing list archives

Re: recent 'cross site scripting' CERT advisory
From: bill () DIAL PIPEX COM (Bill Thompson)
Date: Sun, 6 Feb 2000 09:12:43 -0000

Hash: SHA1

In the light of our discussion on cross site scripting I am
(with Steve's permission) a message from the online-news list which
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.


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

Version: PGPfreeware 6.5.1 Int. for non-commercial use


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]