Magecart and e-Skimming: Why JavaScript and Github Aren’t Always Safe

15 July 2021

Websites used to be built—coded by a team of developers line by line. Now, they are assembled. Chunks of pre-written code with varying functionality, built by multiple developers of varying capabilities, are pieced together to create the final product. Themes, scripts, templates, applets, plugins, and huge blocks of code from disparate sources are commonly pulled together to make a website. In fact, modern web applications load an average of over 20 third- and fourth-party scripts as part of the user experience. While these third-party code snippets and applications are arrows in a developer’s quiver to quickly add functionality for a better user experience, they are also fertile ground for vulnerable code that can be easily manipulated by threat actors. 

Third- and fourth-party  code is often accessed from open-source repositories like GitHub. And herein lies the issue. When you bring in somebody else’s code, you not only incorporate the code’s logic to help accomplish your goal, but you also incorporate everything else the developer has chosen to embed—including vulnerabilities and coding errors. When building a website using third-party code, you are trusting the developer to have considered application security while they wrote it. Unfortunately, for many developers, security is an afterthought, so businesses risk inadvertently introducing vulnerabilities, code weaknesses, and, at worst, malware into their web app or site. 

Hackers working around the world are constantly on the lookout for website and web application vulnerabilities. Spear phishing, brute force attacks, ransomware, and other cyberthreats dominate the headlines. However, while the server side gets the media’s attention, and the CISO’s budget, it’s often the client-side that hides the land mines. There are approximately 20,000 client-side breaches a year. Now that the European Union has released its General Data Protection Regulation (GDPR) and U.S. government entities are fining businesses for breaches, securing the client-side is paramount and requires immediate attention. 

Customers interact with your business through your sites and web apps. This is where they learn about you and pay for goods and services. But security isn’t limited to just public-facing websites. Companies use a wide range of internal web apps. HR, purchasing, and marketing all deploy solutions to align and drive company goals, which are invariably to increase efficiency and generate revenue. Meanwhile, the front end is often untested, unmonitored, and vulnerable

The love/hate relationship with JavaScript

HTML/CSS and JavaScript are the backbone of the web. The vast majority of websites use client-side JavaScript, and any web browser worthy of mention has a dedicated engine to execute the code on the user’s device. Today, nine out of ten websites rely on JavaScript to load an array of features. Location trackers, analytics, pixels, chatbots, forms and more crowd the header of most sites. Many of these are externally controlled. Third parties can make changes to embedded JavaScript and load whatever actions they choose, including scripts from their libraries (fourth-party suppliers). These embedded scripts can dwell in your websites and web applications for weeks, months and even longer. If these scripts are malicious in nature, they can capture personally identifiable information (PII), financial transactions and records, and help themselves to unauthorized access to confidential data. Every week, the news brings us stories of e-skimming, cross-site scripting, Magecart, and other successful attacks on websites and web applications. Many of these attacks and breaches relate to some of the world’s most well-known, trusted and successful brands. However, the vast majority of breaches go unreported. Most victim organizations have 50 to1000 employees—too small to make the news—but not too insignificant to be targeted by threat actors. 

Security stakeholders are aware that client-side malware and other malicious code is often hidden in JavaScript. However, the front end of modern websites are complex and opaque—and client-side code dynamically changes by design with every session. Compounding this is a lack of traceability or accountability, limited bandwidth, and a reluctance to commit manhours to find and remediate client-side security issues. Security teams simply don’t have the tools to examine everything that’s ingested in the browser during the customer experience. It’s outside the installed security perimeter and creates the daunting task of looking for externally loaded code for every user journey. Security analysts and application developers who have dipped their toe into client-side security generally have to cobble together multiple technologies and execute arduous manual processes to evaluate the security of each web asset individually. The result is usually a pragmatic “do the best you can with what you have” approach. 

Plus, there are internal dynamics. A classic example is balancing corporate sales goals and corporate security, often best observed in the interactions between the marketing and IT departments. There’s a natural tension within most companies: marketing wants to get stuff out, while among IT’s many responsibilities is cybersecurity—to keep stuff out. The constant demand is for increased functionality—better tools, more speed, and increased bandwidth to give customers the best experience possible, every time. The reality is that it can take months to submit a product or solution as a proof of concept, go through IT vetting, get budget approval, pass the compliance board, test and go to production. When corporate sales and revenue goals are on the line, this process can be a mental non-starter. And that’s a recipe for covert operations. Marketing may get its functionality but at the risk of security.

What’s hiding in plain sight?

A cat burglar doesn’t operate with a smash-and-grab style; rather, you never know they were there. The same is true with a compromised website or web application. Malicious code can lie seemingly dormant right under the users’ fingertips. Meanwhile, it captures their data from form fills, chatbots, and especially financial transaction pages. The most common path is scraping via keystroke capture. Scripts log, mirror and save user information as they enter it online. Cross-site scripting and request forgeries are popular threat actor attack tactics.

Notably, there are two major factors involved in the development of website code: lack of time and lack of attention to security. Application developers who bring in third-party tools often take for granted that a piece of JavaScript code is secure and will run as advertised. Or, due to workload and expectations, often the developer will take the code and “grip it & rip it,” that is, throw the code into the website or application and move on to the ten other things on the to-do list. 

Who are the bad guys?

Scores of highly trained cybersecurity professionals devote their lives to detecting and responding to cyber attacks. On the other side, similarly brilliant minds spend their waking hours devising cyberattack strategies, tactics, procedures, and malware that are as sophisticated as they are sinister. 

With the price of entry being a computer and internet connection, there is perhaps no field more global than hacking. WordPress is the world’s largest web platform, with tens of thousands of plugins ready to nestle into a site as easily as hitting the download and install buttons. These components load hundreds of JavaScript scripts from all over the world. Many are infected with spyware and keyloggers built to steal sensitive data without security teams’ knowledge. 

There are large-scale hacking groups made up of dozens of hackers and even larger state-sponsored agencies, such as the well-documented activities by the Russian government. While some Eastern Bloc states may lead the pack, they are not the only hotspot: North Korea and China are also big players in nation-state sponsored cyberattacks. And other countries in Asia and South America, as well as Europe and the United States, all house active threat actor communities. 

How do I protect my users?

If you are a managed security service provider (MSSP), app developer, or are responsible for your company’s online presence, it’s your responsibility to prevent web asset infiltration and data exfiltration. It requires a complete understanding of your inventory, access to the tools to identify and eradicate nefarious code now and in the future, and continued vigilance to protect your business and your customers. 

The proper defense technique is built on three pillars:

  • Detect & Identify: Know your web assets and the data they hold and perform deep-dive scans frequently to reveal intrusions, behavioral anomalies and unknown threats, as well as uncover weaknesses in your client-side security posture. This stage includes communicating the threat landscape and client-side attack surface to internal stakeholders for remediation. 
  • Prioritize & Respond: With a complete view of the client-side attack surface across all the digital properties you can find and take corrective action against browser-level skimming and other client-side cyberattacks. 
  • Monitor & Prevent: Maintain an airtight front end with automatic, real-time monitoring of your client-side web assets and changes to JavaScript code.

Client-side application security solutions and the use of automated tools to identify and report on web assets and related data can help organizations maintain appropriate defense levels.

The goal is to deliver customer experiences without risk or compromise. The dangers that come through the front end are significant, as are the historic challenges to defeat them: complexity, a lack of visibility, and an inability to uncover, remediate, and prevent client-side security threats. But with knowledge of what is needed, it can be done and not just said.

Learn How to Guard Your Web Applications Today

See Client-side Security in Action!