21.1 JavaScript and Security
JavaScript's first line of defense
against malicious code is that the language simply does not support
certain capabilities. For example,
client-side JavaScript does not provide any way to write or delete
files or directories on the client computer. With no File object and
no file access functions, a JavaScript program cannot delete a
user's data or plant viruses on the user's system.
Similarly, client-side JavaScript has no networking primitives of any
type. A JavaScript program can load URLs and can send HTML form data
to web servers, CGI scripts, and email addresses, but it cannot
establish a direct connection to any other hosts on the network. This
means, for example, that a JavaScript program cannot use a
client's machine as an attack platform from which to attempt to
crack passwords on another machine. (This would be a particularly
dangerous possibility if the JavaScript program had been loaded from
the Internet through a firewall and could then attempt to break into
the intranet protected by the firewall.)
Although the core JavaScript language and the basic client-side
object model lack the filesystem and networking features that most
malicious code requires, the situation is not quite as simple as it
appears. In many web browsers, JavaScript is used as a "script
engine" for other software components, such as
ActiveX controls in Internet
Explorer and plugins in Netscape. These components may have
filesystem and network capabilities, and the fact that JavaScript
programs can control them clouds the picture and raises security
concerns. This is particularly true with ActiveX controls, and
Microsoft has at times had to release security patches to prevent
JavaScript code from exploiting the capabilities of scriptable
ActiveX objects. We'll touch on this issue again briefly at the
end of this chapter.
While this intentional lack of features in
client-side JavaScript provides a basic level of security against the
most egregious attacks, other security issues remain. These are
primarily privacy issues -- JavaScript programs must not be
allowed to export information about the user of a browser when that
information is supposed to be private.
When you browse the Web, one of the
pieces of information you are by default consenting to release about
yourself is which web browser you use. As a standard part of the HTTP
protocol, a string identifying your browser, its version, and its
vendor is sent with every request for a web page. This information is
public, as is the IP address of your Internet connection, for
example. Other information, however, should not be public: this
includes your email address, which should not be released unless you
choose to do so by sending an email message or authorizing an
automated email message to be sent under your name.
Similarly, your browsing history (the
record of which sites you've already visited) and the contents
of your bookmarks list should remain private. Your browsing history
and bookmarks say a lot about your interests; this is information
that direct marketers and others pay good money for so that they can
target sales pitches to you more effectively. You can be sure that if
a web browser or JavaScript allowed this valuable private information
to be stolen, some people would steal it every time you visited their
sites, and it would be on the market only seconds later. Most web
users would be uncomfortable knowing that any site they visited could
find out that they were cat fanciers, for example, who were also
interested in women's footwear and the Sierra Club.
Even assuming that we
have no embarrassing fetishes to hide, there are plenty of good
reasons to be concerned about data privacy. One such reason is a
pragmatic concern about receiving electronic junk mail (spam) and the
like. Another is a legitimate concern about keeping secrets. We
don't want a JavaScript program loaded from the Internet and
running in one web browser window to be able to start examining the
contents of other browser windows that contain pages loaded from the
company intranet behind the firewall. The remainder of this chapter
explains how JavaScript defends itself against such abuses.
|