CSP bypass: How one Chrome XSS bug took 2.5 years and an HTML spec change to fix

Browser flaw enabled XSS attacks on protected pages

The Chromium team has patched a 2.5-year-old bug that made it possible to stage cross-site scripting (XSS) attacks on web pages, even if they had been configured to prevent XSS attacks.

Discovered by Jun Kokatsu, browser security researcher at Microsoft, the bug allowed crafty attackers to bypass Content Security Policy (CSP), an HTTP header that restricts external resources loaded and run on the web page.

Blob attack

In a proof-of-concept, Kokatsu showed that if a web application creates a Blob URL with attacker-controlled data, it could lead to XSS attacks – even if the site is protected with strict CSP policies. Blobs are raw data that can be read as text or streams.

Due to the way iframes (embedded HTML pages) inherit headers and policies from their parent page, an attacker could exploit the bug to bypass the CSP rules and execute malicious code on the page.

Read more of the latest cross-site scripting (XSS) news

For example, a recent XSS vulnerability in chat.mozilla.org occurred due to creating a Blob URL from a Blob object passed by an attacker.

“This XSS could have been still exploitable even if they had CSP,” Kokatsu told The Daily Swig in written comments.

Kokatsu also said that the attack could be staged on other URL schemes, including and URLs.

A patch two years in the making

Kokatsu discovered the bug in December 2018. It was initially dismissed as something of a non-issue, but the Chromium team later acknowledged its severity and implemented new container security policies in the Chromium specification.

“Not many people realize that cross-origin pages can navigate iframes or windows opened by them,” Kokatsu said. “This understanding is required to understand the attack, and the problem space of policy inheritance issues in the CSP’s specification.”

Nonetheless, due to its complexity, it took more than two years to get the bug fixed. “CSP needs to inherit policy to local scheme, because those schemes (e.g., , , , ) don’t have response headers,” Kokatsu said.

YOU MIGHT ALSO LIKE Google abandons plans to simplify URLs in Chrome following real-world testing

While some of the schemes were relatively easy to solve, Blob URLs were especially difficult to patch because it’s hard to track which document created the URL.

“Therefore, they had to make a new concept in HTML’s specification to track this information,” Kokatsu said.

The new HTML specification, Policy Container, provides more granular control over the policies inherited across HTML documents and their embedded components. It currently applies to CSP and Referrer Policy only. Kokatsu says it needs to be applied to other policies as well.

The complexity of iframe security

Using iframes has been fraught with security concerns. “The ability to link other pages or frame other pages has been one of the benefits of the web. However, it does add complexity to the ecosystem both from browser security and web security,” Kokatsu said.

Browser vendors are constantly trying to develop new specifications and tools to mitigate attacks through embedded frames. Some of these specifications include X-Frame-options, iframe sandbox, and Permission Policy.

“While threats to/from iframes will continue, I’m hopeful that over time we can mitigate many attacks, and move to a safer web,” Kokatsu said.

“As attack[s] advance, what’s important is to understand what’s working, and where we need more specific mitigation, and then apply more defense on those spots.”

MORE CUTTING-EDGE RESEARCH Blind regex injection: Theoretical exploit offers new means of forcing web apps to spill secrets