Re: Active-content filtering (was RE: Buffer Overruns)

[Crispin Cowan <crispin () cse ogi edu>]

"Hazel A. Borg" wrote:

> I am a web developer who took a course in firewalls which opened up
> my eyes to a whole new world.  I have been following the messages in
> this group with great interest.  You are correct in the fact that I don't
> understand the technology and I was wondering if someone if you could
> educate me.  No where in my schooling or the references I use in web
> developing is there a mention of the security problems with JavaScript.

The way Javascript is *supposed* to work is that the applets are downloaded to
the client browser to run.  The browser runs them in a "sandbox" [1] which
contains the applet so that it cannot read or corrupt anything sensitive.

What *actually* happens is that the sandbox is amazingly porus.  Bugs in the
sandboxing function of one or more common browsers allow Javascript (or Java)
applets to access content that they were not intended to access.  My favorite
was the "eBayla" applet:  a Javascript applet suitable for placing on an
ebay.com auction.  When a would-be buyer with Javascript enabled browses the
auction, the applet scoops up the buyer's ebay password, and e-mails it back to
the seller.  Then the seller can forge bids as the buyer.

I had to make the case to a collegue that Javascript is hopelessly insecure,
and counted 20 separate Javascript vulnerabilities in the six months preceeding
May 1999.  There have been numerous vulnerabilities announced since then, the
most recent arising December 16.

With this kind of history of security vulnerability, the prudent and
security-conscious browser does *not* roam around the Internet with Javascript
enabled.  Thus it is rather annoying to come upon a web site that *requires*
Javascript in order to function.  I have no problem with sites that just
Javascript for extra "glitz" (mouse-overs, etc.) but when it is *required* in
order to access content, then it is a problem.  Some examples:

   * Continental Airlines:  Following the "enter here" link, one comes to a
     site that contains no HTML at all.  With Javascript disabled, you just get
     a blank page:
     http://www.continental.com/dash/build_dash.asp?vs_1999_11_22_00
   * City Search:  Their home page  http://www.citysearch.com/ helpfully
     detects if you are not running Javascript, and kicks you off
     http://www.citysearch.com/CitySearch/home/upgrade.html.  There does not
     appear to be any real reason for this.  Javascript is used for navigation,
     but only in trivial ways, e.g. the city selector menu uses Javascript to
     obviate the need to click the "go" button.  This site could easly be
     cleansed to not require Javascript, but City Search has decided that their
     glitz & convience is more important than their customer's security.
   * The National Information systems Security conference:
     http://csrc.nist.gov/nissc/program/r_d.htm   If you would expect anyone to
     know better, it's them.  The scholars behind NISSC probably do know
     better, but the web developers aren't reading the content they're
     deploying.  On this page is a link to the New Security Paradigms Workshop,
     but this link (javascript:openWindow('rd2.htm','popupAboutWin')) has been
     pointlessly implemented as Javascript instead of HTML, because all it does
     is open a window with some HTML in it.  More over, that HTML *has* a
     static HTTP URL ( http://csrc.nist.gov/nissc/program/rd2.htm ) but for
     some bizzarre reason, they chose not to use it.

> All the programs like adobe image ready and macromedia fireworks etc use
> JavaScript making features as a major selling point in their software.
> In simple terms what is the major risk with JavaScript?

Regarding the tools, I realize that this is a problem.  Many of the web
development tools spout about scripting as a feature, not realizing that it is
also a major defect.  I don't have direct experience with these tools, but
presumably they at least announce when they are deploying scripting?  If so, on
each occasion when scripting is employed, ask yourself what the user experience
will be *without* this script.  If it is reduced glitz, no problem.  If it is
inaccessable content, then *seriously* consider re-arranging content so that it
is accessable via pure HTML.

Thanks for listening,
    Crispin-----
Crispin Cowan, CTO, WireX Communications, Inc.    http://wirex.com
Free Hardened Linux Distribution:                 http://immunix.org