October 31, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

JavaScript Security

  • January 16, 2009
  • By Thomas Valentine
  • Send Email »
  • More Articles »

Applying Data Tainting only affects Netscape's Navigator. Because 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 whether 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 also may 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 and 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.

Because 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 that are available to be accepted or declined through the use of an alert box are set using the Java method "netscape.security.PrivelidgeManager.enablePrivelidge()". Here is a list of options that a developer can attempt to have the user verify:

  • 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, and so forth), 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 browser's 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, whereas 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.

Conclusion

Hopefully, this article has helped you understand the security problems that your users may encounter and how you can prevent problems with your JavaScript coding. When coding, look out for the potential security issues discussed here. Remember that you can use the same origin policy, data tainting, and signed scripts to tighten those security gaps.





Page 2 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel