This article originally appeared in Security Boulevard on November 19, 2018.
We’ve seen an acceleration of attacks from Magecart threat actors and their JavaScript credit card and personal information-skimming attacks. In the past two months, British Airways, Feedify, the ABS-CBN Store, the UAAP Store, Newegg and most recently, Shopper Approved have all revealed they have been compromised by Magecart. As British Airways suspects as many as 380,000 transactions were compromised, and the Newegg site has 50 million visitors a month, it’s possible that the number of affected users now reaches into the millions.
Active since 2015, Magecart first hit the big time in June when Ticketmaster UK announced that it had been hacked and that the credit card information of 40,000 users might have been stolen. Magecart had found a backdoor into hundreds of websites by hacking a third-party JavaScript supplier called Inbenta, allowing them to embed their credit card skimming code within Inbenta’s own code. Soon after, New Zealand’s Westpac bank reissued 30,000 cards based on suspicious transactions linked to Ticketmaster payments.
This threat vector, attacking through third-party JavaScript suppliers, is concerning for two reasons. First, it allows hackers to bypass the security precautions of companies that might otherwise be considered to have well-funded and sophisticated security. Second, it has the potential to affect websites and consumers on a massive scale, by leveraging a vulnerability virtually every website has to third-party JavaScript attacks.
Vigilance Isn’t Enough
The simple challenge when trying to defend against Magecart is that traditional website security isn’t enough. They can compromise your website by attacking your trusted third-party partners, so you won’t find suspicious activity inside of your databases. You’ll only discover that Magecart is in the house if their skimmer code is detected inside your third-party scripts, or when suspicious activity is spotted on the credit cards of customers. By then, it’s too late—not only is security penetrated, but customer trust suffers, brand damage occurs, compliance violations require reporting and there may be government fines.
Why Third-Party JavaScript is Dangerous
JavaScript is nearly universally used in dynamic web pages to provide extended functionalities that enhance user experience or provide website analytics. JavaScript interacts with the page’s Document Object Model (DOM) and provides third-party JavaScript vendors with the same level of website administration privileges as those granted to the website owner. Compromised third-party JavaScript code may be used by threat actors to modify, read or extract any information entered or rendered on the webpage. This includes personal and financial data. In addition to introducing elevated website security risk, third-party JavaScript introduces significant compliance and data privacy concerns, since third-party JavaScript is hosted outside of the security controls website owners are able to monitor and control.
But Wait, There’s Hope
Security professionals will note that the concept of third-party JavaScript attacks is not new. It’s been lurking at No. 7 on the OWASP Top Ten security vulnerabilities defined loosely as Cross Site Scripting, or XSS. It’s possible that Magecart’s massively distributed attacks will give this category a bump up next year. Until then, security professionals do have some strategies that can insulate websites from Magecart-style attacks.
Prevention is the Best Option
The best thing security pros can do to prevent an attack is to implement technology that controls the access and permissions of every third-party JavaScript vendor running on web pages. This insulates websites, their visitors and private customer data from the inappropriate or unwanted behaviors of third parties and the more malicious activities of hackers that seek to exploit them.
Prevention approaches for addressing client-side connections not only secure the organization but are required for adequate data control defined by regulatory compliance (e.g. GDPR and California’s newly passed Digital Privacy Law). Without the ability to control private customer data and prevent unauthorized access by third-party website vendors or hackers, an organization is in a state of non-compliance.
Prevention approaches include:
Content Security Policy (CSP): CSP enables administrators to specify the domains that the browser should consider to be valid sources of data, meaning only data from these whitelisted domains can be loaded to the page. This ensures that only JavaScript received from whitelisted domains will be executed. While this methodology can contribute to website security effectiveness, it will not mitigate an attack originating from a whitelisted domain (or vendor). There are also cases where third parties will use multiple domains within a content delivery network (CDN) such as Azure or Akamai, so if hackers attack from within that CDN, your website will remain vulnerable.
In many cases, CSP also introduces new configuration and maintenance challenges for R&D teams as third-party tools frequently leverage multiple domains or change their CDN. CSPs can cause third-party tools to stop working when third-party JavaScript updates or domain changes are not accommodated in the CSP. Additionally, the will prevent fourth-party tools, critical to the proper operation of third-party JavaScript, from properly executing.
Sub-Resource Integrity (SRI): SRI adds a cryptographic hash to JavaScript allowing browsers to verify that files they fetch are delivered without manipulation. This provides a path to ensure malicious JavaScript won’t be loaded from compromised third parties. However, SRI is notably complex to apply to dynamic JavaScript code. The majority of third-party JavaScript vendors continuously improve their services, which results in frequent changes to JavaScript. Adapting SRI to match this dynamic nature can be burdensome and can result in problematic false positives that detract from website effectiveness. In addition, there are many services with dynamic JavaScript that change per user. In these cases, SRI is not effective.
iframes and Sandbox iframes: Vendor JavaScript can be put into an iframe from different domains (e.g. foreign iframe), this will work as a “container” and vendor JavaScript will not have direct access to the host page DOM and cookies. For additional security, the “sandbox” attribute can be used to apply additional safeguards such as secure origin and even cookie control. Unfortunately, the very same safeguards that made iframes an effective method for dealing with third-party JavaScript vulnerabilities is now causing a decline in their use as most third-party vendors require information from the page to function. For example, an ad server may require information about the user to serve the appropriate ad. Analytics tools or heat maps require information about visitor, clicks and cursor location. Again, most third-party JavaScript tools cannot function without access to the elements of the page DOM.
Realtime Sandbox Insulation: This strategy puts vendor JavaScript into a client-side real-time sandbox that acts as a buffer from the actual page. The vendor JavaScript is thereby quarantined and cannot interact directly with the host page, its JavaScript cookies or local storage. The sandbox and host page communicate securely with each other passing only the information needed for the operation of the third-party JavaScript tool without sharing private or sensitive data with the sandboxed JavaScript. The realtime sandbox operates dynamically across each and every website session, using predefined policy rules that establish access and permissions of third-party JavaScript. This scalable framework requires little administration and effectively insulates third-party JavaScript from initiating client-side attacks on web sessions or to violate data privacy concerns related to privacy requirements defined by compliance.
Application Monitoring: Monitoring provides a detection-based approach that provides a less secure, reactive methodology. The major inadequacy of detection approaches is that they are incapable of preventing attacks. These include technologies such as DAST and RASP. Even with a multitude of global sensors, detection schemes often miss highly targeted and hyper-segmented attacks altogether. Additionally, a detection event signals leakage of customer data and constitutes a compliance violation that requires disclosure. The resulting fines, PR crises, remediation and operational fire drills are often significant. Fundamentally, these approaches are not scalable, and the persistence of the underlying vulnerability renders these approaches ineffective.
Vendor Due Diligence Assessments: Many organizations, and especially those under strict compliance mandates, perform routine, comprehensive vendor security assessments. Although well-intended and highly recommended, such exercises provide point-in-time assessments. They do not provide prevention or even continuous detection. Although these assessments should be part of a comprehensive security program, they are in no way adequate as a standalone approach to mitigating or preventing website supply chain third-party risk.
Restricting the Use of Third-Party Tools: Exercising a debilitating level of caution by limiting or restricting the usage of beneficial third-party tools on websites is generally counterproductive to the overall goals of the business. Limiting the number of tools able to be deployed on an organization’s website limits the ability to provide an engaging user experience and extract meaningful analytics. This methodology makes delivering a compelling, differentiated and dynamic web presence difficult.
Website Operators Have a New Responsibility to their Customers
CISOs and CIOs need to secure their websites, but they can’t do it at the expense of the functionality that keeps the business running. The most secure website would be the one that has no connection to the internet, but this would, of course, defeat the purpose of having a website that serves customers. As we protect the website, we must also ensure the business is being driven forward.
Chris Olson, CEO of The Media Trust, said, “Architecture is hacked all the time without even realizing it. Every enterprise needs to be monitoring their website, but they don’t. They check the 10 percent to 20 percent of source code that is their own, what they are ignoring is the 80 percent via third parties.” Since today’s websites are comprised of 80 percent third-party code, it’s not enough for website operators to build strong walls and gates around only the code they specifically create. As we’ve seen in great detail with the accelerating Magecart attacks, threat actors have circumvented organization’s website security defenses by hacking trusted third-party JavaScript suppliers, since it provides the identical level of control and privilege as directly attacking the organization’s owned JavaScript code. The reality is this: If your third-party JavaScript partners are compromised, you are compromised.
