The Strengths and Limitations of a Content Security Policy (CSP)

Not that long ago, Magecart threats were only on the risk radar of ecommerce InfoSec teams but highly publicized attacks against businesses such as Macy’s, Ticketmaster, Forbes, MyPillow, AmeriSleep and hundreds of college bookstores have shaken consumer confidence.

Magecart is a blanket term used to describe the multiple groups of cybercriminals that target the client-side vulnerabilities of websites by adding hidden card skimming code into trusted JavaScript files which can be called up on a website.

Consumers have good reason to be concerned about these attacks; the average Magecart code may reside on a site for up to two months, siphoning off payment card data without their or the site owner’s knowledge.

These threats have prompted firms to consider creating a Content Security Policy (CSP), which is a coding mechanism that specifies which domains and tags should be loaded in web applications and secures them against common vulnerabilities such as cross-site scripting (XSS) and clickjacking.

Cross-site scripting (XSS) is the most common flaw in major modern websites and the most damaging, since cybercriminals can exploit these bugs by intercepting Personal Identify Information (PII) along with payment card data.

Content Security Policy (CSP) configuration and limitations

Developers can create a CSP by using a control approach, which may utilize nonces or hashes that implement the policy through a HTTP response. Browsers that support the CSP can parse the header information and determine which trusted domains and scripts can be loaded based on instructions in the header.  CSPs were traditionally built just using a control URL domain approach which allows scripts to be loaded from vetted sites, but this assumed that all requests coming from these known domains were safe and able to be executed.

However, this assumption doesn’t apply to modern applications where a CSP may be bypassed by JSONP endpoints and other CDNs, along with third parties that use AngularJS library, which allow attackers to gain access. These CSPs may also be weak against certain types of XSS attacks, in particular DOM-based XSS due to unsafe-inline policies.

A study was produced which revealed that the recommended methodology now incorporates a nonce-based strict CSP approach. A strict CSP requires adding a nonce element to all <script> elements, which some platforms can do automatically. Inline event handlers must also be Refactored, and for every page load a new nonce must be created, which can slow the site down.  Numerous other site adoptions must also be implemented.  Coding mistakes can also happen with large CSPs such as a missing “object-src,” where a policy specifies script-src but lacks the object-src directive (and does not set the default-src) which allows script execution by injecting plugin resources.

Even if a strict CSP approach is used, Google studies show around 25 percent of XSS bugs can still be exploited, such as:

• Injections into the body of <script> – if the web application isn’t properly coded for user input script (even if it contains a valid nonce), malicious data can escape out of strings and inject its own code into the existing script
• Policies which contain unsafe-eval, injections into eval(), set Timeout()and a few other API flaws
• Scriptless or post-XSS attacks can still be executed
• Account frameworks Angular and AngularJS will pose challenges
• Some XSS vulnerabilities are not mitigated by a CSP
• Not all browsers support CSP policies and may negate their effectiveness

Due to their complexity, coding mistakes are often made and the free applications available for helping test a CSP are outdated and buggy. Using a third-party CSP based platform provider also introduces configuration uncertainties since multiple (outside) parties are involved which causes the configuration time to stretch out to weeks.

Considering websites are running dozens of third-party vendors in a dynamic environment with ongoing changes, dev cycle workflows aren’t going to be agile enough for a Marketing team to effectively run campaigns, along with ideal site performance.  A policy must be maintained and constantly tested through dev cycle workflows, balancing website security and marketing functionality will always be hard to achieve.

Lastly, the long-term feasibility of operating an ever-evolving campaign is not sustainable since the larger a site is the more complex a CSP must become which will negate its protection capabilities and affect site performance.

MarSec™ and CSP: Better together

While a proper CSP does offer some protection, a more comprehensive, and easier to implement, solution is needed. Ensighten’s MarSec™ sits on the client side and is designed from the ground up to actively enforce against DOM-based Magecart attacks, protect a site visitor’s PII through data governance, prevent ad injections and enable global data privacy regulation enforcement in real time .

MarSec™ is easily implemented through an enforcement gateway which inspects every piece of data that passes through it and only loads what is authorized. Threat mitigation through MarSec™ is not impacted by browser type, JSONP endpoints or inline scripts.  It offers an intuitive drag-and-drop toggle configuration, robust reporting capabilities and endless customization configurations to easily manage and scale with enterprise sites.

Content Security Policies are not designed to be the sole method of protection and should be used in tandem with MarSec™ to provide:

• Stricter control on certain areas such as checkout pages
• Prevention of unsafe internal redirects
• An ability to easily identify or organize third-party vendors
• No impact on website performance or marketing functionality of the website supply chain
• An agile approach to the maintenance and testing of the policy which isn’t hindered by a dev cycle workflow
• Real-time robust reporting that can reveal what was blocked and why and what site visitors are opting out of for data
• Integration with native and external security and compliance workflows to act as enforcer
• Intuitive configuration and management by Marketing and InfoSec teams which both benefit from its capabilities
• Management and scalability with enterprise sites
• Additional benefit of data privacy regulation enforcement

When coupled with MarSec™, a CSP forms a comprehensive layered front against Magecart attacks, ad injection, third-party PII leakage and data privacy enforcement.