Data Tainting - Security the Netscape Way
When it was seen that more security was needed to protect
the user of the Internet, Netscape initiated a new type of
security that was more powerful than anything previous -
Data Tainting. Data Tainting is a combination of the Same
Origin Policy and a setting on the client (user's) computer.
It works in much the same way. It controls the right to
trust another domain and access JavaScript variables and
objects from a page served from a different server, and can
be turned on and off at will. Basically, if Data Tainting is
turned off, a message window will pop up saying that
accessing JavaScript entities on pages from another domain
is not allowed.
- Windows - NS_ENABLE_TAINT=1 - Place the statement
given in the autoexec.bat file for Windows 3.1X, 95, 98 and NT.
For Windows NT, you may also set data tainting as a User
Environment variable.
- UNIX - NS_ENABLE_TAINT=1 - This one depends on
which UNIX shell you are operating with. Basically, you would
set an environment variable through the use of the set env
or env commands.
- Macintosh - You would remove the two forward
slashes before the NS_ENABLE_TAINT statement, which can
be found by editing the resource of type envi and number
128 in the Navigator application itself. The NS_ENABLE_TAINT
statement should be near the end of the document.
- OS/2 - NS_ENABLE_TAINT=1 - Set the given statement
in the config.sys file in the root of your startup drive.
Applying Data Tainting only affects Netscape's Navigator.
Since Data Tainting works in much the same way as the Same
Origin Policy, not all page elements are tested for their
origin - only the absolutely essential parts a JavaScript
script cannot exist without are tested. The list is as
follows:
- document - The cookie, domain, lastModified,
links, referrer, title, and URL properties.
- form - Every instance of a form element.
- history - The current, next, previous and
toString methods and properties.
- link - The hash, host, hostname, href,
pathname, port, protocol, search, and toString
properties and methods.
- location - The hash, host, hostname,
href, pathname, port, protocol, search, and toString
properties and methods.
- option - The defaultSelected, selected,
text, and value properties and methods.
- plugin - The name property.
- window - The defaultStatus, name, and
status properties and methods.
All of the above are tested for its origin. You may test to
see if Data Tainting has been enabled through the use of the
taintEnabled() method, which will return a value of true if
it is enabled or false if it isn't. You may also specify
elements of your script that are to be tainted. It should be
noted that Data Tainting is available only to JavaScript
versions 1.1 and lower. The versions of JavaScript starting
with JavaScript 1.2 use a different type of security -
Signed Scripts.
Signed Scripts
Signed Scripts are used to gain access to certain restricted
information about the client's (the user's) computer. It
uses LiveConnect and the Java Capabilities API (Application
Programming Interface) to access this restricted
information. With this model, you have the ability to "sign"
external JavaScript files with your Security Certificate.
Your Security Certificate is like a fingerprint - it is
unique to you or your organization. Security Certificates
can be created through the use of Netscape's Page Signer
Tool, which is available online, free of charge, at
http://developer.netscape.com. Select the Tools option on
the Site Map.
Netscape's Page Signer tool will allow you to create your
individual and unique online security identification. The
tool builds a JAR (Java Archive) file that includes both
your security certificate and your code. When the document
has an HTML SCRIPT tag that has the ARCHIVE attribute set,
the browser performs a verification check before the code is
executed. An alert box pops up which gives the user a chance
to accept or decline the running of your script. If the
script is included within the document and not within an
external .js file, the JAR file should include only your
security identification, although it is still accessed
through the use of the ARCHIVE attribute.
Since the user can accept or decline a script from running,
Netscape has provided another level to the security that can
be enforced by the user. Some think it to be too user -
driven to use often. By this I mean that the browser will
ask too many questions for what areas of the script to be
run, causing increased user annoyance. The areas of the
script which are available to be accepted or declined
through the use of an alert box are set using the Java
method
"netscape.security.PrivelidgeManager.enablePrivelidge()".
There is a list of options that a developer can attempt to
have the user verify. That list is as follows:
- UniversalBrowserAccess - This method
allows both the reading and the writing of priviledged
data in and to the browser.
- UniversalBrowserRead - This method allows
only the reading of privileged data in the browser,
and is required when using the history object or
getting the value of a DragDrop value within the
browser.
- UniversalBrowserWrite - This method allows
only the writing of privileged data in the browser,
and is required when using any property of an event
object, adding or removing any of the browser's content
bars (status bar, menu bar, etc.), and setting the
window object's values within the script.
- UniversalFileRead - This method allows the
reading of the file system of the user's machine, and
is required when using the fileUpload() method.
- UniversalPreferencesRead - This method allows
the script to read and report the browsers preferences
settings.
- UniversalPreferencesWrite - This method allows
the script to set the preference settings within your
(the user's) browser.
- UniversalSendMail - This method allows the script
to send an email with the user's name, and is required when
using the news: or mailto: attributes within a script.
You can see that the aforementioned pros and cons are quite
evident here. Additionally, each of the two major browsers -
Microsoft's Internet Explorer and Netscape's Navigator -
have differing security measures in place. Internet Explorer
uses the Same Origin Policy, while Netscape uses the Signed
Scripts method. Each is good, in its own way. What is
frustrating, as you'll se when you attempt to enforce
security, is that they are very different. A totally
different directory path for each is sometimes required,
effectively doubling the work you'll have to put in to
satisfy the security considerations for each browser.
JavaScript Security - Page 2
The JavaScript Chronicles
Syntax - Page 4
The JavaScript Chronicles
JavaScript Introduction
Part 2: Data Types
Part 3: Arrays
Part 4: Operators
Part 5: Conditional Statements
Part 6: JavaScript Functions
Part 7: Pattern Matching - The RegExp Object
Part 8: Introduction to Server Side JavaScript
Part 9: Server Side JavaScript Mail Sending
Part 10: Server Side JavaScript and File Manipulation
Part 11: Working with Forms in JavaScript
Part 12: Getting to Know Dynamic HTML
|