Third-party JavaScript is a common technique used to add functionality, user experiences, or security paradigms to your web site. However, these website additions can introduce significant friction. Not all users want to wait for the various JavaScript components to load, and no one is interested in losing their credit card info to Magecart-related content skimming. To gain a better understanding of the impact and risks of third-party code, the CQ Prime Threat Research team analyzed 60+ alerts from our news monitoring bots looking for Magecart in January 2020, and the results are surprising.
Magecart is Prevalent
Our first observation is that, in the 60 or so cases we reviewed, most of the affected organizations made use of third-party code. They appeared not to be tracking the externally sourced JavaScript for changes or monitoring its impact to their sites. Of the 60 web sites, analyzed from news reports of them being impacted by Magecart, all had a third party call to another site that houses the script for execution. Examples ranged from midsized retailers to larger organizations such as the Olympics Ticket Sales and Australian Bushfires Donations site.
Too Many Secrets
Many popular websites will use third-party code to support Ad Networks, Ad Trackers, Styles, and methods of moving data. Image 1 below highlights the impact on a web site that has Facebook as a third-party dependency. The Facebook dependency is the blue circle in the middle of the image that is connecting to many external script resources and is being called by many other organizations. Its popularity illustrates how interconnected dependencies can be and why Magecart is so prolific and hard to reign in, since attacking the Facebook dependency in this example could/would expand quickly to many targets.
Image 1: Adding third-party integration like Facebook dramatically increases the complexity of managing the interrelated dependencies and associated risk.
By itself, the sheer volume of interrelated dependencies highlights the security risk of third-party code. Call outs to image files, fonts, styles, and various other scripts are used on most basic of sites. More heavily trafficked, popular sites will call JavaScript from 50 places. Any one of those places can be compromised to point to a new piece of third-party code, or could have malicious code injected via some other attack vector. There are just too many places that are being pulled from to think this type of attack isn’t possible.
Adding to the risk of too many JavaScript callouts , is the fact that few organizations have complete visibility into their third-party dependencies. They are often unaware of changes, new additions, or when one begins redirecting credit card data to another site. In recent Magecart attacks, BASE64 encoding was used to obfuscate the JavaScript that was watching for specific checkout forms. If that form was loaded, the Name, Address, Phone Number, Credit Card, CVV, Expiry, was capture and sent to a server for collection in a database. Image 2 shows a
JavaScript snippet that loaded with the main page and quietly waited for the checkout sequence.
Image 2: An example of third-party integration code – an easy target for Magecart attackers.
This BASE64 encoded string simply opens a connection to post data back to the server “’open’,’POST’,’setRequestHeader’,’Content-Type’,’application/x-www-form-urlencoded’”
One of the suggested mitigations for this type of attack is Sub Resource Integrity (SRI). This means you includea hash of all of your third-party JavaScript in your code. The browser then pulls the hash, makes its own, and compares them. If it detects something has changed it doesn’t load that code. Though, there is a drawback to this approach. Since, if you or the vendor make changes you need to redo the hash and redeploy. It can be orchestrated but given that some popular browsers like IE and Edge don’t have full support; SRI hasn’t taken on huge amounts of adoption. As more third-party code is adopted, the number of secret hashes would have to grow dynamically, and something would have to become the single source of truth for all JavaScript on the planet –an unlikely proposition.
Too Slow to Execute
An often-overlooked impact of the increased number of third-party code snippets executing on a web site is their impact on the page load speed. Some of this code is used to build the page dynamically, for analytics purposes, to provide user experience feedback, or to protect the site from automated attacks.
Using Google’s PageSpeed Insights (https://developers.google.com/speed/pagespeed/insights/) to analyze commonly used web sites, demonstrates where the greatest page load impact was. In cases where the page had a third-party code performing obfuscation or just doing of-page calculation, the page loads were dramatically increased. Performance tuning for these sites would need to include removing some of these components as they are just getting in the way, causing user friction from load times and offering yet another third-party set of code being utilized.
Image 3: The impact on user experience when third-party code executes at page load.
In the more extreme cases, PageSpeed Insights showed that JavaScript designed to collect telemetry for automated attack protection added five seconds to a fairly simplistic page’s load time. In the age of password vaults, the authentication waiting game is no longer a hiding place for third-party code execution. Users have come to expect pages to load quickly and without much fuss.
Adding third-party code can be a great way to create interactivity with your end users and create a positive user experience. However, you should place it inline on your site only with an extreme amount of care and caution. Not knowing what that code does, how it executes, or its impact on the browser, can introduce risk.
As we begin to see more and more attacks happening on this layer, we need to realize that having a good inventory of our third-party resources and having policies to track when it changes is important. Otherwise attacks on this vector, such as credit card skimming, might go unnoticed. If your application has so many dependencies that you cannot effectively understand if one changes, you should look into having a better inventory of your dependencies and how they impact user security as well as user experience.
Looking for a way to protect your public-facing applications? Learn more about App Firewall in the video below.
Sign up for the latest Cequence Security news
By clicking Subscribe, I agree to the use of my personal data in accordance with Cequence Security Privacy Policy. Cequence Security will not sell, trade, lease, or rent your personal data to third parties.
