Bypassing Security Restrictions and Signing Code

  • Revision slug: Bypassing_Security_Restrictions_and_Signing_Code
  • Revision title: Bypassing Security Restrictions and Signing Code
  • Revision id: 77773
  • Created:
  • Creator: Mathieu Deaudelin
  • Is current revision? No
  • Comment The "Security Central" now links to the Security page on this wiki instead of "Security Developer Central" on DevEdge. Both are equivalents.

Revision Content

One link at the end of this article is broken.
It is labeled ''(broken-link)''

Often it may be necessary to deploy or test code that has to function beyond the safe "sandbox" security zone of the browsing environment. An example might be a script that comes from one domain that is trying to invoke methods on scripts affiliated with another domain. Typically, such scripts have to be digitally signed with a code signing certificate to make such invocations in Netscape and Mozilla browsers. Though deploying signed code is the ideal solution for production environments that will be accessed by several users, often developers would like a way to make a quick test of their scripts without the additional step of signing the code. This article presents information on how to edit your Netscape or Mozilla preferences in order to accomplish this.

JavaScript code that runs on Mozilla and Netscape browsers is subject to certain restrictions, such as the Same Origin Policy which prevents document or script loaded from one origin from getting or setting properties of a document from a different origin. Such restrictions are a familiar notion since the Netscape Navigator 2.0 days. Security Central provides links on using tools to affix digital signatures to JavaScript files, as well as links on how to deploy signed code. A references section has also been added at the end. This technote shows users a way around the security restrictions, particularly those imposed by having to sign your code, and the techniques prescribed here should be considered for testing purposes only.

Netscape and Mozilla browsers are highly configurable. By going to the Edit | Preferences menu, you can see ways in the preferences panel to configure your browsing experiences. There are additionally some number of hidden preferences also, and most of these are in the form of entries in special JavaScript files stored in your profile directory.

One such file is prefs.js which is in your profile directory. To learn more about where your profile directory is located, please see the Netscape 7 release notes. On Windows 2000, for example, the location of this file might be C:\Documents and Settings\arun\Application Data\Mozilla\Profiles\arun\43x9dyn.slt\prefs.js. There is one line you can add to this file that will allow you to bypass some of the script restrictions without signing your scripts.

Before editing this file, you'll have to make sure that you've exited the browser. Completely shut down Netscape 7 or your Mozilla browser. Take special care if you're running the Quick Launch feature on Windows -- be sure to exit the browser from the icon on the right of your taskbar. When the browser has exited, add this line of code to the file:

    user_pref("signed.applets.codebase_principal_support", true); 

The phraseology of the preference dates to the Netscape Communicator 4.x days, when adding this preference to the prefs.js file would allow unsigned Java applets and unsigned JavaScript scripts to access properties which needed special privileges to access them. In the Netscape and Mozilla browser world, the preference has no meaning for Java Applets, but certainly continues to have meaning for scripts asking for additional privileges without a digital signature.

Scripts can ask for additional privileges by invoking the PrivilegeManager. For example:

function getHomePage() {
  try { 
    // ask user for permission
    netscape.security.PrivilegeManager.enablePrivilege('UniversalPreferencesRead');
    var hp = navigator.preference('browser.startup.homepage');
    alert('Your home page is ' + hp);
  } catch (e) {
    // user refused permission
    alert('Permission to read homepage was denied.'); 
  }
}

will cause an alert dialog to display telling the user that a script on the site has requested extended security privileges and whether the user would like to permit such access this time, each time, or not at all. If the user agrees, the script will be allowed to read the preference that stores what your startup homepage is. Typically, such code to read your preferences would have to be digitally signed. By adding the codebase principals entry in your prefs.js file, however, the code does not need to be signed. Here is a complete list of privileges you can set. In particular, the UniversalBrowserRead privilege allows you to bypass the same-origin restriction on scripts.

There are risks associated with editing your prefs.js file like this, since you now increase the risk of malicious sites being able to take advantage of your more permissive client. If you make this modification to your preferences, be certain to only grant special privileges to sites you trust (such as your own).

Related Links

Original Document Information

  • Author(s): Arun K. Ranganathan, Netscape Communications
  • Last Updated Date: 11 Nov 2002
  • Copyright Information: Copyright © 2001-2003 Netscape. All rights reserved.

Revision Source

<pre>One link at the end of this article is broken.
It is labeled ''(broken-link)''
</pre>
<p>Often it may be necessary to deploy or test code that has to function beyond the safe "sandbox" security zone of the browsing environment. An example might be a script that comes from one domain that is trying to invoke methods on scripts affiliated with another domain. Typically, such scripts have to be digitally signed with a code signing certificate to make such invocations in Netscape and Mozilla browsers. Though deploying signed code is the ideal solution for production environments that will be accessed by several users, often developers would like a way to make a quick test of their scripts without the additional step of signing the code. This article presents information on how to edit your Netscape or Mozilla preferences in order to accomplish this.
</p><p>JavaScript code that runs on Mozilla and Netscape browsers is subject to certain restrictions, such as the <a class="external" href="http://www.mozilla.org/projects/security/components/same-origin.html">Same Origin Policy</a> which prevents document or script loaded from one origin from getting or setting properties of a document from a different origin. Such restrictions are a familiar notion since the Netscape Navigator 2.0 days. <a href="en/Security">Security Central</a> provides links on using tools to affix digital signatures to JavaScript files, as well as links on how to deploy signed code. A <a href="#Related_Links">references</a> section has also been added at the end. This technote shows users a way around the security restrictions, particularly those imposed by having to sign your code, and the techniques prescribed here should be considered for testing purposes only.
</p><p>Netscape and Mozilla browsers are highly configurable. By going to the Edit | Preferences menu, you can see ways in the preferences panel to configure your browsing experiences. There are additionally some number of hidden preferences also, and most of these are in the form of entries in special JavaScript files stored in your profile directory.
</p><p>One such file is prefs.js which is in your profile directory. To learn more about where your profile directory is located, please see the <a class="external" href="http://wp.netscape.com/eng/mozilla/ns7/relnotes/7.html#profiles_location">Netscape 7 release notes</a>. On Windows 2000, for example, the location of this file might be <i>C:\Documents and Settings\arun\Application Data\Mozilla\Profiles\arun\43x9dyn.slt\prefs.js</i>. There is one line you can add to this file that will allow you to bypass some of the script restrictions without signing your scripts.
</p><p>Before editing this file, you'll have to make sure that you've exited the browser. Completely shut down Netscape 7 or your Mozilla browser. Take special care if you're running the Quick Launch feature on Windows -- be sure to exit the browser from the icon on the right of your taskbar. When the browser has exited, add this line of code to the file:
</p>
<pre>    user_pref("signed.applets.codebase_principal_support", true); 
</pre>
<p>The phraseology of the preference dates to the Netscape Communicator 4.x days, when adding this preference to the prefs.js file would allow unsigned Java applets and unsigned JavaScript scripts to access properties which needed special privileges to access them. In the Netscape and Mozilla browser world, the preference has no meaning for Java Applets, but certainly continues to have meaning for scripts asking for additional privileges without a digital signature.
</p><p>Scripts can ask for additional privileges by invoking the PrivilegeManager. For example:
</p>
<pre>function getHomePage() {
  try { 
    // ask user for permission
    netscape.security.PrivilegeManager.enablePrivilege('UniversalPreferencesRead');
    var hp = navigator.preference('browser.startup.homepage');
    alert('Your home page is ' + hp);
  } catch (e) {
    // user refused permission
    alert('Permission to read homepage was denied.'); 
  }
}
</pre>
<p>will cause an alert dialog to display telling the user that a script on the site has requested extended security privileges and whether the user would like to permit such access this time, each time, or not at all. If the user agrees, the script will be allowed to read the preference that stores what your startup homepage is. Typically, such code to read your preferences would have to be digitally signed. By adding the codebase principals entry in your prefs.js file, however, the code does not need to be signed. Here is <a class="external" href="http://www.mozilla.org/projects/security/components/signed-scripts.html#privs-list">a complete list of privileges</a> you can set. In particular, the UniversalBrowserRead privilege allows you to bypass the same-origin restriction on scripts.
</p><p>There are risks associated with editing your prefs.js file like this, since you now increase the risk of malicious sites being able to take advantage of your more permissive client. If you make this modification to your preferences, be certain to only grant special privileges to sites you trust (such as your own).
</p>
<h3 name="Related_Links"> Related Links </h3>
<ul><li> <a class="external" href="http://www.mozilla.org/projects/security/components/ConfigPolicy.html">Further Script Access Preferences</a>
</li><li> <a class="external" href="http://www.mozilla.org/projects/security/components/same-origin.html">Same Origin Policy</a>
</li><li> <a class="external" href="http://developer.netscape.com/software/signedobj/jarpack.html">Using Signtool 1.3 (broken-link)</a>
</li><li> <a class="external" href="http://www.mozilla.org/projects/security/components/signed-scripts.html#privs-list">List of Privileges Scripts can ask for</a>
</li></ul>
<div class="originaldocinfo">
<h3 name="Original_Document_Information"> Original Document Information </h3>
<ul><li> Author(s): Arun K. Ranganathan, Netscape Communications
</li><li> Last Updated Date: 11 Nov 2002
</li><li> Copyright Information: Copyright © 2001-2003 Netscape. All rights reserved.
</li></ul>
</div>
Revert to this revision