Re: recent 'cross site scripting' CERT advisory

[marcs () ZNEP COM (Marc Slemko)]

-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 4 Feb 2000, Tim Hollebeek wrote:

> Misconception #2: This problem is "new"
>
> Security experts and hackers have been aware of the ability to exploit these
> problems for a long time, but creators of web sites and web-enabled software
> have for the most part not paid adequate attention to these problems.
> CERT's motivation appears to be to raise awareness of these significant
> dangers in the hopes that future and existing systems will be
> (re-)engineered with these problems in mind.
>
> Misconception #3: This problem has never been exploited by hackers.
>
> Many of the problems with Microsoft's hotmail have been due to attacks which
>  fall within the range of this security advisor, as does the eBayla attack
> on eBay.

Erm... you are still missing the entire point of the advisory and the
entire new aspect of it.

The know issues you describe are where user B posts content that
user A can see.  This issue is about something that user A requests
and only user A sees.  The first issue is old, and is what your
examples are.  The second has never been widely recognized, and
where it has been recognized the implications have not been
understood.  The fact that the first scenario is old news and
largely dealt with (although certainly not completely; there are
still javascript holes in hotmail, etc.) is expliciltly pointed
out in the CERT advisory, and it makes it clear that the real meat
of the issue being discussed is the second class of sites.

Sure, they all end up boiling down to the same basic thing, but
the methods of attack are different and the sites impacted by the
second class of attacks are orders of magnitude larger.

A huge number of sites (eg. you can steal accounts on at least half
of the top 10 web sites, including several commerce sites) are
impacted by this to varying degrees.  Many or most of them don't
realize it.  The message to them: GET WITH IT!  I'm sure that as
nasty people start realizing this, you will see a lot of exploits
being posted.  They aren't hard to find.

It is critical to realize this.  I have talked to people at a couple of
top ecommerce sites that were completely vulnerable to this attack.  They
had no idea of their exposure.  Had they seen the CERT advisory?  Well,
of course.  But they didn't think it mattered to them.

This also brings to the forefront a lot of other issues that have
been lingering, such as the dangerous of persistent signons and
single signon systems (which can sometimes be exploited without
this cross site scripting problem by getting someone to follow the
right link) and the fact that it is _extremely_ difficult to properly
encode or filter things, especially if you want to allow "safe"
HTML through.  This is a major issue.

Things users should do:

1. Disable scripting if possible.  See the CERT advisory and MS docs for
info on this.  Note that this is not a complete solution, because the
problem is not a scripting problem.  Scripting languages just make it
easier to exploit because they have fairly complete control over what
the user sees and does.  Disabling scripting languages, however, obviously
isn't possible all the time.

2. Do not use a mail reader that forces you to display HTML messages.
Using something like Outlook Express is very dangerous, since it
means that you can be exploited if an email message arrives in your
inbox and is displayed.  If you do use something like Outlook
Express, be sure to configure it to disable scripting and make it
as restrictive as possible.  Unfortunately, in the case of Outlook
Express, this doesn't appear to be enough since I can't find any
setting that will stop things like IFRAMEs from automatically
loading, which are enough to make you vulnerable in many situations.
Hopefully I'm missing something.

3. Do _NOT_ enable the option of keeping yourself persistently
logged in at any site that matters at all.  Persistent logins make
it far easier to steal cookies that allow others to steal your
account.  Be especially wary of sites with a single login system
for a lot of sites, such as msn.com (which includes hotmail, etc.
through MS Passport) and yahoo.com (which includes yahoo mail),
since any single site in that domain that is vulnerable will
compromise your cookies (and account) for the entire site.  Some
sites don't provide obvious ways to logout, such as Amazon.  On
those sites, often a "Not user foo?  Click here" link will log you
out.  Use it.  And make sure the site knows that you want the option
of not being persistently logged in.

4. Don't randomly follow links that you are sent.  Unfortunately, for
many users, when combined with (2) this is impossible.

5. Even if you think you are safe because a site asks for a password
before letting you do anything having any real consequence, be
wary.  I have found a number of top sites where this is improperly
implemented:  ie. if you know where the particular page the form
submits to is (and this is normally the same for all users, possibly
with some session identifier appended), you can access it directly
without having to supply any password.

Things web developers should do:

1. Read all the recommendations in the CERT advisory, the Apache info, and
the Microsoft info.  I think the MS info contains the most detailed
information in a lot of areas here.  Do what this info says.  Namely,
properly filter or encode all output.  Unfortunately, figuring out what
"properly" means and how to do it is not as trivial as some documents
would make it seem.

2. Pay particular attention to any software you run.  At last count,
at least IIS5, Apache, WebSite Pro, Roxen, Netscape Enterprise,
Zeus and thttpd had vulnerabilities in their default configurations,
to the best of my knowledge.  Some are fixable with config changes
(eg.  override default error page), some may not be.  Of these,
Apache's vulnerabilities are probably the smallest, as they are
almost entirely based on not specifying an explicit charset.  See
point 3 below.  Get in touch with your vendor; if your vendor says
they aren't vulnerable, be dubious; they may not understand the
problem.  Note that while software like webservers is a small part
of the problem, and the easiest part to fix, if it isn't fixed then
fixing all your code does no good.

3. Pay particular attention to the charset issue.  If you don't specify an
explicit charset on your documents, it is possible the client could
interpret "+ADwK-" as "<" if it is using UTF-7.  IE even gives
users an "auto-select" option that will make this trivial.  For
those lucky enough (or english-centric enough) not to have to deal
with multiple charactersets, the Apache patches released allow
you to force every resource on your server to be sent with a charset
that you specify regardless of what module, etc. it is sent from.

4. Remember that if you are using domain based cookies (eg.
.znep.com) instead of host based cookies (eg. foo.znep.com) then
_any_ vulnerable server in your domain will make you vulnerable,
even if that server doesn't do anything that matters.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQCVAwUBOJxjTlQv/g4Arev1AQFtCwQApHgIYBI7gc2jULUdw/IqhTI+6wH9gkya
vZhnk66u1A5OeRO78jqZqQSvJT1Rnx/bG+dqy93fH+UZyb06y8co80ZtlMUDOzyE
7YrRIW9p+cprUzMP/pJ6NkvaeroCzwsYPvJG5HCyjYGeX3mb9JheR3XfGrAX1v7+
+xFhP69ilcY=
=QuzO
-----END PGP SIGNATURE-----