How the JavaScript-in-cookies security exploit works

Exploit:
Grants a webmaster the ability to read properties of any HTML files on a user's hard drive. In particular, the webmaster can access links from the user's bookmark file, or access HTML files in the user's cache directory and retrieve the titles of these pages to determine the user's surfing history.

Requirements:

  1. The user must be running a profile called "default". Most Communicator installations are set up like this. (If the webmaster is running the exploit against one particular person, the exploit will work with any profile name as long as the webmaster can guess what it is.)
  2. The user must have JavaScript and cookies turned on.

How it works

The key to the exploit is that you can set a value of a cookie to contain JavaScript. The following JavaScript code: 

document.cookie = "jscookie=\<script\>alert('hello
world')\</script\>;expires=Fri,
31 Dec 2000 23:00:00 GMT;domain=.peacefire.org;path=/"
will cause the line 
<script>alert('hello world')</script>
to appear in the file
C:\Program Files\Netscape\Users\default\cookies.txt

There are some restrictions on the JavaScript code that can be inserted into the cookies.txt file in this way; obviously the code can't contain newlines because newlines are not allowed in a cookie value, and the code also can't contain semicolons, because semicolons are already reserved as a separator in the "document.cookie" string. Without newlines and semicolons, the way to concatenate multiple code statements into one cookie value is to separate them with commas.

So, first the webmaster uses a page to set a cookie value to contain JavaScript code. Then the webmaster directs the user to a frames page (this can be done with an automatic redirect), where one of the frames points to the user's local file:
C:\Program Files\Netscape\Users\default\cookies.txt

and another frame points to the file that the webmaster wants to read, in this case:
C:\Program Files\Netscape\Users\default\bookmark.htm

Then the JavaScript code in the cookies.txt file goes to work. Because the cookies.txt file and the bookmark.htm file are in the same "domain", the JavaScript code in cookies.txt can access properties of bookmark.htm. This stolen data can then be sent back to the webmaster e.g. by setting the SRC attribute of a third frame to point to a CGI script on the webmaster's server, and including the stolen data in the GET query string.

(There is one more trick necessary to get this to work; if you load the file cookies.txt into a frame as it is, Netscape will load it as a text file and not an HTML file, so the JavaScript code won't get executed. To fool Netscape into loading the file as an HTML file, load it as
C:\Program Files\Netscape\Users\default\cookies.txt?/.html

and the ".html" on the end will cause it to be loaded as an HTML file, so that the JavaScript code will get executed.)