IE hole exposes Web surfers' private data

Security enthusiasts Bennett Haselton and Jamie McCarthy demonstrated how a simple substitution in Web addresses (URLs) can foil IE's security checks, exposing the cookie files that Web sites place on visitors' computers. Cookies authenticate people's identities when they return to Web sites and store data about visitors' activities and purchases.

Microsoft noted that the hole doesn't let an attacker "inventory" the visitor's cookies, but only targets specific ones from certain sites. The company also said that a victim would have to visit a malicious Web site.

Still, Microsoft acknowledged that the hole leaves room for plenty of trouble.

"The vulnerability could allow a malicious Web site to read, change or delete cookies that belong to another Web site," Microsoft said in a statement. "We expect to deliver the patch shortly. A security bulletin will be published...to discuss the issue and advise customers how to obtain and apply the patch."

The hole lends credence to the fears of privacy advocates, who say the technology and business of collecting Web surfers' private information--such as when and where they surf and which books and other items they purchase--is prone to abuse and mishap.

Such concerns have made their way to the U.S. Congress, which is evaluating cookies with a jaundiced eye.

Meanwhile, browser makers must continually fend off hacks that threaten the security of cookie files.

As a basic security precaution, Web browsers give information stored on a cookie only to the site that put it there in the first place. According to the bug hunters' analysis, IE does this by comparing the cookie's and Web site's domains and proceeding only if they match. In other words, if Yahoo Mail has placed a cookie on an account holder's computer, IE will yield the information only to a "yahoo.com" server.

The bug's discoverers determined that IE was checking domains by examining the information directly preceding the first single-slash mark of the Web address. For example, a URL that reads "http://amazon.com/getcookies" would have access to cookies from "amazon.com" servers.

But HTML, the coding language of the Web, allows a substitution for those single slashes, opening the door to the security problem. In writing URLs, "%2f" works fine in place of the slash--except that in checking cookie domains against Web server addresses, IE doesn't recognize "%2f" as a slash equivalent.

That lets a nosy Web server request a visitor's cookies by disguising its own domain by following it with the "%2f" sign, and by appending a bogus "amazon.com/"--or other domain whose cookies it is targeting--at the end of its request.

For example, in demonstrating the exploit on the Peacefire Web site, the bug hunters showed how to read a person's Amazon.com cookie by directing IE to the URL: "http://www.peacefire.org%2fsecurity%2fiecookies%2fshowcookie.html%3F.amazon.com."

Because IE doesn't recognize "%2f" as a slash, it skips to the end of the URL to find the domain and lets a Web server read the person's Amazon.com cookie.

"This can reveal anything from your real name and email address to books you've been purchasing," said Haselton, who heads the Peacefire anti-filtering group. "Any site that uses cookies for authentication is vulnerable."

That includes free Web-based email services such as Hotmail and Yahoo Mail, as well as any site that uses a shopping cart, Haselton said. He noted that the hole could not be exploited to steal mail passwords, and that access to Web email accounts was only possible while the password holder was logged into the account.

The demonstration exploit relies on JavaScript, a scripting language for executing tasks without a person's interaction, to transfer the cookie information from the visitor's computer to the Web server. The bug hunters recommended that IE users disable JavaScript.

They added that Netscape's Communicator browser is not affected.