[13729] in bugtraq
Re: recent 'cross site scripting' CERT advisory
daemon@ATHENA.MIT.EDU (Bill Thompson)
Mon Feb 7 16:30:43 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <LPBBLOPOCCCHHDIFALIEAEAOCDAA.bill@dial.pipex.com>
Date: Sun, 6 Feb 2000 09:12:43 -0000
Reply-To: Bill Thompson <bill@DIAL.PIPEX.COM>
From: Bill Thompson <bill@DIAL.PIPEX.COM>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <017701bf6f39$7b1c8970$4402a8c0@rstcorp.com>
-----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-----
