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
-----BEGIN PGP SIGNED MESSAGE-----
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
From: Steve Bonisteel <steveb () typecast com>
Date: Fri, 04 Feb 2000 21:54:39 -0500
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
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
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
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.
- --- end forwarded message --
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 Int. for non-commercial use
-----END PGP SIGNATURE-----
Re: Bypass Virus Checking minus (Feb 03)
Re: Bypass Virus Checking salme () US IBM COM (Feb 02)