Spying Scripts and JavaScript Security Policy

Spying Scripts and JavaScript Security Policy

 

In addition to the security issues addressed in the previous section, there are some security issues that are specific to Javascript. These issues involves user privacy and the protection of sensitive user information. These issues central around the way in which Javascript prevents scripts from one Internet host from accessing the data of script that are from other Internet hosts.

 

]A script that executes in one browser window or frame has the capability to access data entered by a user in another window or frame.

]You have seen several examples of how this can be done in part II, "Using Predefined Objects and Methods".

]In most cases, this is a desirable features. However, under some scenarios it can pose a security risk.

]For example, consider the case where a user is browsing a hacker web site in one browser window and performing an online purchase in another.

]what prevents an untrusted script from the hacker's web site from reading the credit information that you enter into the shopping from of the other window? This is what spying scripts do.

 

The answer to this potential problem has been addressed since javascript. However , the specific manner in which it has been resolved has changed with Javascript. In Javascript , a script that executives in the context of a document loaded from one Internet host is prevented from accessing the properties and methods of documents that are loaded form other Internet hosts. This provided a simple solution to the spying script problem. This solution is referred to as the Same Origin Security Policy.

 

However , in javascript Netscape lost its flair for simplicity and came up with an approach for allowing scripts from one host to securely access the properties of documents that are loaded from other hosts. However, the capability to identify security sensitive properties as private (referred to as tainting) is provided. Tainted values cannot be disclosed without the user’s permission. When data tainting is turned off (the default), the Javascript same origin security policy is in effect.

 

The good point about data tainting is that it allows some flexibility in security. However, this benefits was outweighed by the cumbersome process by which it was implemented; the requirement to taint properties to keep them secure; and the fact that the whole process confused the user. More information on data tinting is provided in online Appendix A, “comparing Javascript and JScript”. Data tainting is essentially a dead and should be avoided.

 

Principle The principal is a person or organization that signs a script.

 

Target The target is the script or portion of a script that is signed.

 

Signature The principal creates the signature by applying encryption key to the contents of the target (script). The signature indicates that the signer has (or should have) verified that the script is trustworthy. The signature also acts as a seal in that it can be used to verify that the script has not been altered after it has been signed. The signature can be verified as being from the principal using cryptographic methods involving he principal’s public key.

 

Privilege when a signed script executes, it requests privileges from the browser and user. The browser presents information about the script’s signature to the user so that the user can make informed decisions about whether he or she should grant the privileges requested by the script. A privilege generally involves permission to perform a security sensitive operation , such as collecting information from other windows or generating e-mail on behalf of the user.

 

Certificate A certificate is an electronic document that at tests to the fact that a principal can be recognized by a particular public key. Anyone can sign a script. However, to have your signature recognized, the public key associated with your signature must itself be signed by a recognized certificate authority (such as verisign). This boils down to the fact that you must pay the certificate authority to give you a certificate. The  certificate authority generally performs some investigation to see if you are indeed who you say you are. The details of object signing device into cryptographic methods. Links to these details are provided in online Appendix B, “Accessing Online References.”

 

Internet Explorer maintains the simple same origin security policy in all of its browser versions. To get around this policy , you will need to develop a custom ActiveX control and sign the control using Microsoft’s code signing tools.

 

Having covered the evolution of Netscape security policy related to spying scripts , you may wonder how this affects your scripts development. In general, if your scripts do not have any compelling need to access the properties of documents that are loaded from other Web sites in other frames and windows , you have nothing to worry about . Both Navigator and internet Explorer default to the same origin security policy. If, for some reason, your scripts need to access the properties of these other documents or to send information, such as e-mail , on behalf of the user, you will have a security problem.

 

To solve this problem, you will need to implements a Navigator specific solution and an Internet Explorer specific solution. You will need to use signed scripts with Navigator and signed ActiveX controls with Internet Explorer. In both cases, you will need to get a code signing certificate from a certificate authority and sign your scripts using appropriate code signing tools.