Javascript XSS: cross-site scripting and digital signatures

Purpose
Demonstrate how XSS (cross-site scripting) is possible in order to allow javascript located at one website to be loaded and used within another website. One of the advantages of this approach is to allow multiple websites to use the same code (in a single location) instead of each website containing their own copy of the javascript code - which also removes the problem of version control.

Overview
You can digitally sign several different types of files to identify those files as being "trusted"; that is, the file(s) that have been digitally signed was done so by an entity (such as a company) that can be identified by a certificate authority such as Verisign or Thawte. This is done through the use of an SSL certificate that is issued to the entity from SSL providers such as Verisign and Thawte. If you do not have server administrator access to the web server the SSL certificate is installed on and where the javascript file(s) will be located at, you will not be able to digitally sign files.

In order to have XSS enabled in a web browser (such as Firefox or Internet Explorer) you need to attach a digital signature to the javascript files (site A) that are going to be used by another website (site B). The other website (site B) does not need to do anything special other than link to the javascript file(s) in a manner such as:

Site B Importing Javascript From Site A:

<html>
<head>
<script language="javascript" type="text/javascript" src="https://www.domain-name.com/sample.js"></script>
</head>
<body>
...
</body>
</html>

Once linked (and the sample.js file is digitally signed), Site B can freely access any javascript functions and variables that may be present in the sample.js file. As well, the sample.js file at Site A can freely access any javascript functions, variables and page data that may be present in the calling webpage at Site B. With this level of trust, accessing a javascript function, for instance, is done in the same way as if the javascript function was actually part of the site. That is, Site B can call a function in sample.js which is at Site A by doing nothing more than calling the function such as alert(functionAtSiteA()). This also means that you can pass data from Site B to a function or variable in sample.js of Site A and visa-versa.

Digitally Signing a Javascript File On Site A (Windows web server):
This part is a little time-consuming and I've actually broken it down into a step-by-step process if you have a Windows 2003 web server, with an SSL certificate for a specific website issued by a valid certificate authority that a web browser will recognize. I also include information on the same process for Apache/Linux (may be incomplete as I did not have the box with an SSL certificate to analyze).

STEP 1		Download the Windows 2008/.Net 3.5 SDK (approximately 15Gb) and install following the instructions: http://www.microsoft.com/downloads/details.aspx?FamilyId=E6E1C3DF-A74F-4207-8586-711EBE331CDC&displaylang=en
STEP 2		Go to Start -> Run -> Enter "cmd" and press enter. Navigate to C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin
STEP 3		At the command prompt type in "signtool signwizard" without the quotes and press enter.
STEP 4		Under the File Selection window, browse to the javascript (.js) file (which is on the same web server as well as the cert)
STEP 5	(Enlarge)	Change filetype to "All Files" so you can select the javascript file.
STEP 6	(Enlarge)	Select "Custom" under the signing options window.
STEP 7	(Enlarge) (Enlarge)	Click the "Select From File" button
STEP 7.1		If this is the first time you've used the .cer file then you may need to perform the following 7.x series of steps. Open the MMC.
STEP 7.2		Select File and add/remove snap-in.
STEP 7.3		Add the "Certificates" snap-in and select "Computer Account" when prompted.
STEP 7.4		Select "Local Computer" at the "Select Computer" pane.
STEP 7.5		Click "Close" on the "Add Standalone" snap-in pane.
STEP 7.6		Click "OK" on the "Add Standalone" snap-in pane.
STEP 7.7		Under the console root, expand the certificates of the local computer.
STEP 7.8		Expand "Personal".
STEP 7.9		Under "Certificates" right-click the desired cert being used to sign the file.
STEP 7.10	(Enlarge) (Enlarge) (Enlarge)	Select "All Tasks" and then "Export".
STEP 7.11		Verify your settings and click "Finish".
STEP 8	(Enlarge)	Select .cer for the filetype.
STEP 9		Select the .cer file that you exported in Step 7.
STEP 10	(Enlarge)	Verify the certificate you selected.
STEP 11	(Enlarge)	Select "Private Key in CSP" and the correct key container. You will not be able to select "Next" until you select the proper key container.
STEP 12	(Enlarge)	Select "Sha1" for the hash.
STEP 13	(Enlarge)	Under the "Additional Certificates" pane make sure both "Only the signature certificate" and "No additional certificates" are selected.
STEP 14		Select the "Add a timestamp to the date" checkbox and enter the following text: http://timestamp.verisign.com/scripts/timstamp.dll
STEP 15	(Enlarge)	Verify your settings and click "Finish".
STEP 16	(Enlarge)	Open the javascript file with Notepad. At the end of the javascript code you should see that the digital signature was appended to it. The javascript file can be edited (such as adding javascript functions) and it will continue to operate without needing another digital signature being created for it as long as you do not alter the digital signature that was originally appended to it. Finally, you can add the digital signature (via copy-n-paste) to the end of other javascript files of the same website; this means you do not need to manually create a digital signature for each javascript file.

Another helpful application (which will cut down on the number of steps that you may need to perform) is known as Crypto4 PKI; used mainly to select .cer for the public key export and .pvk for the private key export...this means you may not need to download the Windows 2008/.Net 3.5 SDK (approximately 15Gb) and install it on the Windows web server.

[UPDATE]: Crypto4 PKI is no longer available. In its place please reference "How to convert your .PFX (p12) certificate to a .pvk + .spc combination on Windows" that you would use after step 7.11.

Digitally Signing a Javascript File On Site A (Apache/Linux web server):
As I previously mentioned, I do not have a step by step tutorial created for the exact process of digitally signing a javascript file on an Apache/Linux web server. However, the process (as previously described) is basically the same in that you need to use an SSL certificate (such as from Verisign/Thawte) installed on the web server for a website (the website which will contain the javascript file to be digitally signed).

The first thing that you want to have installed on the web server is the Signing Tool (signtool 1.3). You can find it on the Mozilla.org website on this webpage.

The second thing that you want to have is some documentation on how to digitally sign a file. If you have never signed a file, you may want to take a look at this Sun documentation. While the emphasis is placed on having a .jar file (.zip archive of your javascript files in this case), I strongly suspect that you can just digitally sign a .js file without having to go through all of the extra overhead of a .jar file.

Why do I say that? On the Windows web server you can digitally sign a single .js file and that signature is recognized in both Internet Explorer 7x and Firefox 3x and it works just fine. Second, in the context of just .js files being digitally signed, I do not know if Internet Explorer will work with a .jar file containing all the .js files or .xul data (obviously Firefox has the capability to work with those types of files). So, for the sake of cross-browser compatibility each individual .js file is digitally signed and then linked to in the client webpage (see example 2 of documentation I have at the end of this page). Finally, anytime one of the .js files contained in the .jar file changes means that you have to go through the whole process of re-signing the .jar file...so you have to have server administrator priviledges or consume more of that individual's time.

Third, you will need to construct some commands on the web server (indicated by the previously mentioned Sun documentation). When you think you are done with digitally signing a .js file, open the .js file with a text editor such as vi. If a digital signature can be appended to the .js file (as it can be with a Windows web server - which is compatible with Internet Explorer 7x and Firefox 3x), you will see something similiar to this.

Of additional interest to you may be some documentation that Verisign and Thawte have for the digital signing process.

A Few Test Scenarios
The zip file below contains two examples that you may want to experiment with (note: you will need to remove the partial digital signature from the .js files prior to adding your own complete digital signature).

Example one focuses on the "parent site" importing a javascript from a "child site" which contains the signed javascript. In this example, a function at the "parent site" passes data to a javascript function contained at the "child site". The "child site" takes that data and passes it back to the "parent site". The purpose of this example is to show, with minimal overhead, how to pass data and access functions between the websites.

Example two is somewhat more complex in that the "parent site" imports a series of signed javascript files from the "child site". These signed javascript files are the building blocks of a RTE (Rich Text Editor). Basically what happens is that the "parent site" passes data to the "child site". The "child site" takes that data and inserts it into the RTE. A user can then change the data in the RTE. When the user clicks on the "Save" button the "child site" takes the data contained in the RTE and passes that data back to the "parent site".

Download the javascript-signing.zip file or the javascript-signing.rar file.