Could JavaScript Steal a Cookie?

In my March column on digital IDs, I mentioned in passing -- as one reason why client certificates are superior to cookies -- that certificates are more secure. I said that was so because a server could inspect a browser's request and grab a cookie that was not one that the server had placed in the browser's cookie file.

This is wrong , and I apologize. Here's how the mechanism actually wo rks. Given a cookie file beginning with

      .infoseek.com     InfoSeekUserID  ...cookiedata...

      cg
i.netscape.com  NETSCAPE_VERIFY ...cookiedata...

the browser will send InfoSeekUserID's data only to addresses matching .infoseek.com; that is, only to servers in the domain from which the InfoSeekUserID cookie was sent. Similarly, NETSCAPE_VERIFY will go only to cgi.netscape.com, the server that created that cookie.

I got this wrong because I thought that, when parsing the client's data, the server ended up with an environment that looks like this:

      InfoSeekUserID  data
      NETSCAPE_VERIFY data

The server could get at any cookie's data by matching its name, if known. In fact, there's only one cookie-related CGI variable, HTTP_COOKIE, whose value is the concatenation of cookie entries that match the server's domain . Unfortunately, since the machine I happened to test on had only cookies I had put there, and no others, I got the wrong impression that the browser sent all cookie data, not just that matching the server's domain.

Another rea son I got this wrong was that I'd been told by a hacker whose skills I respect that it was trivial to pick off unauthorized cookie data. Maybe so, but it's not as trivial as you might think. Out of curiosity, I tried to see how I could steal unauthorized cookie data. I got as far as the following three steps:

1 I noted that JavaScript can do file:/// URLs, so you can, for example, do this...

      document.location = "file:///c:/program files/netscape/navigator/cookies.txt"

...and cause a browser to load the cookie file on a Windows box running Navigator.

2 I remembered from Rex Baldazo's column ( http://www.byte.com/art/9608/sec9/art1.htm ) that you can create a hidden frame. So, step 1 could occur invisibly.

3 I l earned that JavaScript can call the Submit method on a Submit-button object so that a form executes all by itself when it loads.

This was starting to smell like a way to steal local files. But it's not so simple. JavaScript cannot actually build a page itself on the fly and then load that page. Nor can it grab material from the screen or write a local file. I could not find a way to get JavaScript to construct a form that pulls in a local file and then sends it somewhere.

If, on the other hand, such a form were placed on your machine in a known location by some other means, then JavaScript could load and execute it, causing transmission of a local file. Of course, if your disk's been compromised in that way, all bets are off anyway.

I don't think JavaScript is the security disaster some folks say it is. I still think that digital IDs will supplant cookies, but not because cookies are easy to steal. They're not. At least I don't think they are. If someone has convincing proof otherwise, I'd l ove to see it.