With so much of commerce taking place online nowadays, online businesses quite understandably have and will continue to commit substantial investment into every aspect of their digital storefronts as they strive to capture a greater share of the vast and growing eCommerce market.
They’re not the only ones trying to capitalize on these digital opportunities however: Entire economies have been built and continue to grow to profit off of online commerce by a myriad of methods, ranging from fraud and identity theft, collecting users’ private information, to injecting malicious content that redirects web traffic and revenue away from the intended destination to other sites.
With so much at stake then, online businesses have also invested in solutions aimed at protecting their users’ security and privacy. We recently covered how one of these solutions, a Content Security Policy (CSP), works and explained the 5 main areas its capabilities fall short in preventing Customer Journey Hijacking, which specifically targets consumer browsers in order to inject unauthorized ads that disrupt users when visiting online retail sites and divert them to competing offers.
Ad injectors and other malicious actors have used browser extensions as one of the main routes to installing code injections and for very good reason: they exploit consumer side vulnerabilities that allow them to bypass server-side security solutions, including a CSP. Add the fact that browser extension are so widely used, and it’s little wonder why they have become a prime target for injectors.
To help online businesses understand how a malicious browser extension can still inject invasive impacting a website running a CSP, let’s first take a look at how CSPs and browser extensions work.
What is a CSP?
The World Wide Web Consortium (W3C) is the main international standards organization for the World Wide Web. Here’s how they define a CSP, and how it should and should not be used:
“It is a tool which developers can use to lock down their applications in various ways, mitigating the risk of content injection vulnerabilities such as cross-site scripting, and reducing the privilege with which their applications execute.
CSP is not intended as a first line of defense against content injection vulnerabilities. Instead, CSP is best used as defense-in-depth. It reduces the harm that a malicious injection can cause, but it is not a replacement for careful input validation and output encoding.”
How does a browser extension work?
Browser extensions are event-based programs used to modify or enhance the browsing experience. An event is a browser trigger, such as navigating to a new page, removing a bookmark, or closing a tab. Browser extensions monitor these events in their background script and react with specified instructions. A background page is loaded when it is needed, and unloaded when it goes idle. Once it has been loaded, a background page will stay running as long as it is performing an action, such as calling the browser API or issuing a network request for example. A background page will not unload until all visible views and all message ports are closed.
So… Does a CSP Actually Prevent Browser Injections?
Still think that applying a CSP restriction on your website will keep your users and your business secure from browser injections that hijack your customers? Think again. The same W3C Specification document clearly outlines these Implementation Considerations:
All web browsers align with this W3C specification. Indeed, when using the Browser webRequest API, extensions can edit the request before it gets to the webpage. Just like that… the extension can bypass the website CSP restriction. With no reach or capability on the client side, the CSP simply can’t prevent this.
How does a browser extension bypass a CSP?
Browser extension APIs define a set of events that follow the life cycle of web requests, and can use these events to observe and analyze incoming and outgoing traffic. Specific synchronous events will allow the browser extension to intercept, block, or modify a request.
For example, the Chrome Extension webRequest API has a function called onHeadersReceived, which fires each time an HTTP(S) response header is received. Due to redirects and authentication requests, this can happen multiple times per request. This event is intended to allow extensions to add, modify, and delete response headers, such as incoming Content-Type headers and CSP headers.
Malicious or not, Chrome extensions use the onHeadersReceived event to modify the CSP headers, ‘CONTENT-SECURITY-POLICY’, and ‘X-WEBKIT-CSP’ before the webpage rendered.
The CSP Directives registry contains many types of directives enabling developers to control certain aspects of their sites’ behavior. There are directives govern resource fetching, the state of a document, aspects of navigation, and reporting.
Chrome extensions can decide which directives to modify — or even set a new CSP header that bypasses all requests. For example, the extension can set the default source for a website to include every asset added to the page using the ‘default-src’ directive.
The example below shows how the default source is set to allow all assets on a webpage, consequently allowing for extensions to inject unauthorized content:
Want to see how this code looks on a supposedly CSP-protected web page?
Here’s how to install the Chrome extension locally:
- Download the crx file from GitHub
- Open chrome://extensions/ on Chrome
- Enable “developer mode” on the page (This is just to enable you to install the Extension locally)
- Drag and drop the crx file onto the page
- Done. You’ll now see the Extension in the Extensions list.
- Now navigate to a website with CSP to see how this code appears.
The Verdict: A CSP Will Not Prevent Browser Injections from Disrupting Your Site Experience
As the example above shows, the writing is on the proverbial wall: CSPs do not have the client-side capabilities required to stop browser injections from injecting code into your website. As we previously covered, browser extensions and add-ons inject code and HTML elements directly into the end user’s browser, completely bypassing the CSP.
Protecting the integrity of your website and how it’s experienced by your customers requires technology that monitors web browser activity taking place on the client-side and is capable of blocking unauthorized code from running.