JavaScript Security
In your evolution as a web developer, you'll run into some
security problems eventually. The makers of JavaScript have
identified and solved most of the really glaring security
holes, while the browser vendors have plugged up some the
holes themselves, along with adding a certain measure of
guaranteed security through browser operations. There are
several different approaches to security inherent in
JavaScript. Each has its own pros and cons, but as a whole
they work pretty good. Some of the security procedures are
within the JavaScript interpreter, and some are within the
browser itself. As you begin to develop, you (or your
employer) will no doubt insist on the implementation of some
measure of security. Not taking security considerations into
account will lead to tampering. It's a fact, so you have to
deal with it. Leaving out security in your development will
open your creation (and your company) to tampering. Your
site users will not use your offered content when word gets
out that they are vulnerable due to your security holes.
The browser runs off of the operating system itself, which
means that the file system of the user's machine is a
potential target for malicious users. It is entirely
possible to access a user's directory listing through
JavaScript. Hackers know this, and exploit it on a regular
basis. Security starts with your servers, since it is there
that the user downloads - and executes upon their machine -
your code. Your servers must be tightly controlled and
regularly monitored. Your code must be clean, leaving no
threads open to outside access. This is the developer's
responsibility. More about threads in a later section.
User responsibilities are basically whether or not to trust
your content to run in their machines, leading us back to
the security you, the developer, will implement. This
ability to trust your content and run or not run your
scripts is within the capabilities of the browser - it is a
setting in the preferences section of the browser.
The Problem with Frames
When the first instances of frames were implemented on the
Internet, it took all of two months for the first major
security holes to open up and be recognized by the hacking
community. To understand how frames were used to present a
security hole is to first understand frames themselves.
The way a web page renders frames is as follows:
- A page with instructions for the frames to be rendered is loaded.
- The addresses and particulars of how the frames will be rendered such as border properties and the placement of the frames themselves is given to the browser.
- The documents that will be used to display the content of the frames are then loaded into the given frames.
- The page is then rendered (displayed) to the browser window.
Within this procedure is the ability to load and execute web
pages from other servers on other domains. The JavaScript
variables from one domain are available for examination and
modification to the web pages from the other domains that
are used within the other frames that make up the page. The
first strategy to combat this problem was the Same Origin
Policy, which was taken up by Netscape Navigator, Internet
Explorer and Opera.
The Same Origin Policy - Security the Internet Explorer Way
The Same Origin Policy prevents JavaScript code that was
sent from one server to access the properties of a document
sent from another server, another port, or another protocol
and return that information to the original server. The Same
Origin Policy does not affect all elements of an HTML
document, but rather the key JavaScript elements that a
functioning script within an HTML document cannot be
executed without. The elements that are enforced by the Same
Origin Policy that must pass an origin inspection are as
follows:
- document - The reading and writing of the
anchors, applets, cookie, domain, elements, embeds, forms,
lastModified, length, referrer, title, and URL methods and
properties. Also verified is each instance of a form
element, and all Java CLASSes available to a JavaScript
function via LiveConnect.
- Image - The lowsrc and src properties.
- Layer - The src property.
- Location - Every property available to location
except location.x and location.y.
- Window - The find property.
You can see that most of the functionality of the common
JavaScript script must use at least one of the properties
and methods which must pass the origin inspection, making it
next to impossible to maliciously alter or access the
scripted functions of a framed window.
Occasionally, you may have a need to go against the Same
Origin Policy to achieve the desired result from your web
application. An exception has been made to address this
possibility. To access the information within a page created
and displayed within one of the page frames, you would use
the "document.domain" statement to list a domain that is
trusted by the web application and thus the browser. For
example, for a page that originated at http://developer
.walkthegeek.com to access variables and scripted
entities from a page that originated at http://www.walkthegeek
.com, you would use the following statement within your
function:
document.domain = "walkthegeek.com";
Setting the document.domain property in this way tells the
browser to trust all content from the domain
www.walkthegeek.com as well as all subdomains of
walkthegeek.com, such as the aforementioned http://developer
.walkthegeek.com.
JavaScript Intro
The JavaScript Chronicles
Data-Tainting - Page 3
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
|
