Why CSP Isn’t Enough to Stop Magecart-Like Attacks

As Magecart and formjacking attacks become more sophisticated, it’s essential to address not only what services may interact with users, but what that interaction looks like and how to control it.

2019 left enterprises scrambling for security measures to tackle new threats such as formjacking and targeted attacks perpetrated by the group known as Magecart as well as other attackers leveraging the same techniques. Most, if not all, of the Magecart-style attacks started from a trusted domain, a third party, or the actual website domain. The British Airways attack started from its own domain, while Delta Airlines, Best Buy, Sears, and others started from trusted third-party domains.

Traditionally, security analysts have been quick to suggest Content Security Policy (CSP) as a valid technique to thwart these attacks. In reality, there are many gaps and vulnerabilities in using CSP as an end-all solution for monitoring and protecting websites and ensuring the end user or customer is in fact also protected from these attacks.

Unfortunately, using CSP alone to combat the threat posed by Magecart leaves large gaps and blind spots in the overall health, security, and functionality of a website. 

What Is a CSP?
CSP is implemented through an additional series of headers which a web server can send to a visitor’s browser to define rules about what code, images, videos, and other files can be loaded by the browser. Put simply, the browser is given a list of domains to trust and from which it may retrieve content. If the web page attempts to load content from a domain not listed within the CSP definition provided by the web server, that content will not be loaded. 

CSP can be used to effectively prevent certain types of client-side attacks. In cases where external resources can be mapped beforehand, thoroughly investigated for malicious code, and be kept up to date through future releases, CSP can be a useful component of an overall anti-Magecart strategy. 

However, there are a few issues that show the disadvantages of CSP. Here are three of its biggest problems, as well as a few tips about how to address them.

CSP does allow the owner of a website to control where third-party code can come from, but it does not provide a robust or granular way of handling what that code does once it is executing in the browser. In some ways, this is analogous to giving the key to your business to a contractor and leaving them unsupervised; you are granting them access but have no control over their behavior once they have that access.

As Magecart-like attacks become more sophisticated, it is essential to address not only what services may interact with your visitor, but what that interaction looks like and how it may be controlled. 

More Work and Management Required
Implementing CSP requires an immense amount of effort because of configuration, subject matter expertise, and ongoing maintenance. Each new third-party service introduced into the website will require analysis by developers, the creation of new CSP directives, and changes to the web server application to deploy those new directives. Furthermore, this process may need to be repeated with each new release of any particular third-party service present. Lastly, this requires on-going governance and collaboration between digital media or marketing teams and application development, creating an additional organizational burden.

Third-party services frequently change their own internal architecture for a variety of reasons: feature enhancements, optimization, market conditions, etc. Any changes implemented by the third party may require reconfiguration of the CSP rules created for that service. 

While those changes are being made, the organization using that third-party service must make a decision between disabling CSP altogether and allowing that service to run with no security in place or discontinuing use of the service until a new CSP configuration can be developed in-house. 

Action Plan
Here are three simple steps organizations can take to assess their vulnerability and protect themselves better:

• Perform a website threat analysis to see how vulnerable you really are from malicious attacks.
• Understand what scripts on your website are running and detect ones that shouldn’t be there or aren’t doing what they are intended to do.
• Pay attention to similar industry attacks. If you are an e-commerce company and notice many attacks are in the news, do your homework on them. Make sure you aren’t using the same systems — and if you are, that you are monitoring them efficiently.

Many organizations undervalue the importance of the code they deliver to a visitor’s browser. The look, feel, interactivity, color scheme, and font choice may all be heavily scrutinized to ensure optimal customer satisfaction and return on investment. But often what is shown in the browser is thought of as a presentation layer rather than a vital part of the web application itself. 

Because client-side code is, in many cases, the core of the commerce engine the organization relies upon, it is essential to protect that code not only with the lock-and-key or whitelisting approach provided by CSP, but also robust, next-generation solutions which provide granular control over third parties and truly extend website security to the client side.

Related Content:

Hadar brings more than 15 years of varied executive experience, leading teams and developing multiple out of the box solutions. Formerly Chief Solution Architect at LivePerson global sales and alliances team, Hadar’s can-do approach helped to close contracts worth millions of … View Full Bio

More Insights

Read More HERE