New Attacks Recall Old Problems with Browser Cookies

DHS CERT published an alert prompted by a paper delivered at USENIX regarding the security of browser cookies.

In case didn’t know or need a reminder, browser cookies aren’t exactly impervious to attack.

The DHS-sponsored CERT at the Software Engineering Institute at Carnegie Mellon University this week dropped an alert that warns users about the continued prevalence of a class of cookie vulnerabilities that puts users’ privacy and even financial well-being at risk.

The alert was prompted by a research paper presented at last month’s USENIX Security Symposium called “Cookies Lack Integrity: Real-World Implications,” [pdf] written by Xiaofeng Zheng, Jian Jiang, Jinjin Liang, Haixin Duan, Shuo Chen, Tao Wan and Nicholas Weaver of China’s Tsinghua University, International Computer Science Institute, Microsoft, Huawei Canada, and the University of California Berkeley.

The paper takes an in-depth tour of cookie-injection attacks, which can happen even over secure HTTPS connections, and describes vulnerabilities and implementation weaknesses in the RFC 6265 cookie specification that compound the issue.

The attack described at USENIX involves a network-based sitting in a man-in-the-middle position who can inject cookies in an HTTP session that will also attach themselves to HTTPS connections. The researchers said the vulnerabilities are present in a number of heavily-trafficked sites—they identify Google and Bank of America by name—and added that a number of consequences could include privacy violations, account hijacking and financial loss.

“You are on a network which the attacker can control (such as at Starbucks or an open WiFi). The attacker temporarily hijacks your browser to insert cookies for a targeted site,” Weaver told Threatpost. “Now, sometime later when you visit the site (on a different network, under different circumstances), your browser presents the bad cookies to the site, and the site acts on the bad cookies in a site-dependent way. EG, it could just simply track the user, or it could be a full XSS attack buried in the cookie itself.”

In the paper, the researchers note that domain isolation of cookies is weak and that different but related domains can have a shared cookie scope. From the paper:

“A cookie may have a “secure” flag, indicating that it should only be presented over HTTPS, ensuring confidentiality of its value against a network man-in-the-middle (MITM). However, there is no similar measure to protect its integrity from the same adversary: an HTTP response is allowed to set a secure cookie for its domain. An adversary on a related domain capable of disrupting cookie integrity by making use of shared cookie.”

Not even the Same-Origin Policy, which is meant to wall content between domains, is an effective deterrent in these attacks because the network-based attacker can force the victim’s browser to visit a malicious site.

“Since RFC 6265 does not specify any mechanism to provide isolation and integrity guarantees, web browser implementations do not always authenticate the domain setting a cookie,” the CERT alert said. “A malicious attacker can utilize this to set a cookie that is later used via an HTTPS connection instead of the cookie set by the actual site.”

The researchers suggest a number of possible mitigations, chief among them the implementation of HTTP Strict Transport Security (HSTS), and changes browser makers can address. The paper also proposes a proof-of-concept browser extension that better isolates cookies between HTTP and HTTPS domains.

“HSTS prevents your browser from accepting the attacker’s cookies for all HSTS supporting sites you’ve already visited, since they come through HTTP not HTTPS,” Weaver said. “So any site which sets HSTS to its base domain and all subdomains is effectively immune.

“[Browsers] need to change how cookies operate, which is always an area fraught with risk because of the possibility that a more secure cookie policy might break existing websites,” Weaver said.

Suggested articles