Java Script Security - Java Script

One of the biggest issues for any Web-based system, whether it be purely informational or an online storefront,is security. JavaScript is filled with security checks to prevent malicious scripts from attacking your computer, but specific security measures are also taken by each browser. Mozilla, for instance, has an entirely unique security model involving signed scripts and enhanced privileges. If you understand which security measures apply to all browsers and which are browser-specific you can create more secure JavaScript.

The Same Origin Policy

It was briefly mentioned earlier in the book that JavaScript can only communicate with pages from the same domain. For example, a home page cannot interact with any browser window or frame containing a page from Mozilla’s Web site. This security measure is known as the Same Origin Policy.

Two scripts are considered to have the same origin if the containing pages:

  • Use the same protocol (such as http://)
  • Use the same port (typically port 80)
  • Have the same domain name

If all three of these conditions aren’t met, the two scripts are not allowed to interact. For instance, a script running on cannot access a page from p2p.wisdomjobs.com because these are considered different domain names. This same script can’t access pages from www.wisdomjobs.com:8080 because it has a different port number or from about:blank because it’s a different protocol.

The effect on BOM and DOM scripting

These rules affect the way you can interact with the BOM and the DOM. For instance, you cannot access the document object for any page from a different origin, meaning that you can’t access any of the DOM structure. The following two lines illustrate the issue:

The previous code should output two alerts, each displaying the URL of the page in the second frame (the frame at index 1). You may recall from earlier in the book that both the window and document objects have a location object as a property. If the script using these two lines of code is from a different origin than the page contained in the frame, the second line of code fails because the script cannot access the document.location object or any of its properties. The script can, however, access the window. location object (represented by frames[1].location) and can still access all the other properties of the window.

You may also remember that the XML HTTP Request object (in all browsers) and the Web Service functionality work only with resources from the same domain; this is yet another instance where the Same Origin Policy takes effect. It also applies to plugins.

The exception to the rule

Common logic dictates that www.wrox.com and p2p.wrox.com belong to the same domain,so they should be able to communicate with one another. As it turns out, the browser developers agree and have provided a way to allow such communication.

In the pages from each subdomain, a single line of script can be included to circumvent the Same Origin Policy. This is done by setting the document.domain property as shown here:

document.domain = “wisdomjobs.com”;

This simple line of code then eliminates all the security blocks for JavaScript communication. Note, however, that you can set the domain only to a value already in the URL, so a page from www.wisdomjobs.com cannot set the domain to mozilla.org, because that is a violation of the Same Origin Policy.

Window object issues

A number of measures protect end users from malicious scripts attempting to use windows.

First and foremost, windows cannot be opened off screen or smaller than 100 x 100. If you specify coordinates that are off the screen,the window is automatically placed on the screen in a location close to where you specified, but with enough space to see the entire window. Likewise,if you try to open a window smaller than 100 x 100, the window automatically opens up to 100 x 100. These rules, although seemingly impractical, help to ensure that users are always aware of windows popped up from scripts.

You also can’t open windows that are larger than the user’s desktop. You can’t, for instance, open a window that is 1600 x 1200 on a screen that is 1024 x 768.

These same window position and dimension rules apply after the window has been created. You cannot move a pop-up window off screen using moveBy() or moveTo(), nor can you resize the window to be smaller than 100 x 100 or to be larger than the desktop using resizeBy() and resizeTo().

Also a window cannot be closed using the close() method unless the window was opened using window. open(). If you try to close a window that wasn’t opened by script, a dialog is displayed asking for the user’s permission to close to the window.

Most browsers now come with pop-up blockers built-in. Many non-technical users actually have no idea whether or not pop-up blocking is turned on. Keep this in mind when designing your Web solution.

Typically, pop-up blockers work by blocking all pop-up windows that occur without user interaction, meaning that you can’t open up a new window during events such as load and unload;pop-up windows can only be opened during events such as click and keypress.However, some pop-up blockers that block all pop-up windows without regard for user interaction. So how can you tell if one of your pop-up windows has met with an untimely block?

The window.open() method typically returns a pointer to the newly created window. If the window was blocked, window.open() usually returns null:

The preceding code displays a message to the user when the window has been blocked. In general, it’s always best to make sure the method returned doesn’t return null whenever you open a window.

This method works well for Windows XP Service Pack 2’s IE pop-up blocker, Mozilla’s pop-up blocker, and the Google Toolbar pop-up blocker.For others, you may need to surround the window.open() call in a try..catch block (because some other pop-up blockers actually cause JavaScript errors instead of just returning null).

Mozilla-specific issues

As part of the Netscape Communicator code overhaul, Mozilla introduced several new security mechanisms for ensuring the authenticity and safety of scripts embedded in Web pages. The first involves activating enhanced privileges.

Privileges

Various security-related capabilities are arranged into privileges. In order to use these privileged functions, you must request permission from the user using netscape.security.Privilege Manager.enablePrivilege().

Mozilla provides guidance to developers regarding the proper use of privileges in a document entitled “JavaScript Security: Signed Scripts” . In this document, Jesse Ruderman lists the following available privileges for Mozilla:

Privileges

In order to enable a privilege,you must pass in one of these values to the enablePrivilege() method:

You may remember this line of code from Chapter 17, “Web Services.” This privilege was necessary in order to complete the Web Service calls. The UniversalBrowserRead privilege also allows you to access the URLs in the browser’s history, such as the following:

This script outputs the URL of each page in the browser’s history, as stored in the history object.

As soon as you have completed the use of privileged actions, it’s best to disable the privilege to ensure that no malicious scripts can use the privilege:

The UniversalBrowserWrite privilege is perhaps the most interesting because it enables you to avoid the window restrictions mentioned earlier. When this privilege is enabled, you can:

  • Resize windows to be less than 100 x 100 or greater than the user’s desktop size.
  • Move windows off screen.
  • Create windows without a window title.
  • Close a window using close() regardless of how the window was opened.

If a privilege is requested and not accepted, then the JavaScript Console displays a message saying, “User did not grant privilege”.

Signed scripts

In order to use the extended privileges, your script must be signed. JavaScript files can be signed in the same manner as applets, and doing so allows access to these privileges. Signing a script involves obtaining a digital certificate from a security firm that authenticates the script’s location, publisher, and usage.

When a signed script is loaded, the browser displays a message asking if the signed script should be allowed to access the extended privileges it may use. The Mozilla Foundation provides SignTool to aid in the signing of scripts. This small utility packages a script into a JAR file along with its digital certificate. In order to use signed scripts, the containing HTML page must be accessed using a URL with the following format:

jar:http://www.yourdomain.com/signedscripts.jar!/page.htm

When the script is properly signed and accessed with an appropriate URL, the user just accepts the digital certificate;he is not required to allow each privilege as it is enabled. If the script isn’t signed appropriately, it won’t run. The JavaScript Console displays the same message the user sees when he doesn’t allow an extended privilege (“User did not grant privilege”).

Codebase Principals

Another way to access the extended privileges is to enable Codebase Principals. This policy determines the safety of a given script based on where it’s loaded from (its codebase). Presumably, a script is safe if it is being loaded from the same server as the HTML page. This is not exactly a safe assumption, which is why all Mozilla browsers come with Codebase Principals disabled. It is purposely difficult to enable so that the average user won’t turn on Codebase Principals by mistake. Codebase Principals should only be used for testing and debugging of a script that will eventually be signed.

Resource limitations

If you’re a software developer or a software user, you’re probably aware that some programs can end up overreaching their memory limit, making your machine run more slowly, become unstable, and sometimes crash. It was decided by browser companies that JavaScript would not affect the user’s computer in this detrimental way.For this reason,browsers only run up to one million lines of JavaScript is any one call.

One million sounds like a lot of lines (probably more lines than you’ll ever need), but every once in a while you may find yourself bumping up against this limit.When this happens, the browser notifies you in some way: Internet Explorer pops up a dialog box telling you that a script is causing the browser to run slowly and asks if you would like to continue running the script; Mozilla simply opts out of the current operation and places an error message in the JavaScript Console.

The one million lines aren’t cumulative, so you don’t need to worry if you have scripts that run when the user clicks on different parts of the page. This restriction exists only within a single function call to prevent problems such as infinite loops and infinite recursion.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Java Script Topics