Magecart and e-skimming attacks often begin and end with JavaScript. In this blog, we’ll take a look at why JavaScript and Github aren’t always safe for website and web application development and how they contribute to the client-side security gap.
Websites used to be built—coded by a team of developers line by line. Now, they are assembled. Developers of varying capabilities build websites composed of chunks of pre-written code with varying functionality. 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 quickly add functionality to improve the user experience, they are also fertile ground for vulnerable code that can be easily manipulated by threat actors.
JavaScript and open-source code from Github is vulnerable to Magecart and e-skimming
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, but you also incorporate everything else the developer has embedded—including vulnerabilities and coding errors. When building a website using third-party code, you are trusting the developer to have considered application security during development. Unfortunately, for many developers, security is an afterthought. So, businesses risk inadvertently introducing vulnerabilities, code weaknesses, and, worse, malware into their web app or site. Sadly, Magecart and e-skimming are often the result of these issues.
Hackers know JavaScript and Github aren’t safe
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 often remains 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. 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, and forms crowd the header of most sites. Many of these are externally controlled.
Threat actors 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, they can capture personally identifiable information (PII), financial transactions and records, and other types of 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, many breaches go unreported, since the majority of victim organizations have 50 to 1,000 employees—significant enough for attack—but too small to make the news.
Security teams know JavaScript and Github aren’t safe (but they can only do so much)
Security stakeholders are aware that JavaScript and Github aren’t safe and hide client-side malware and other malicious code. However, the front end of modern websites are complex and opaque—and client-side code dynamically changes by design with every session. Compounding this are problems with traceability and accountability, limited bandwidth, and a reluctance to commit the time needed to locate and fix client-side security issues. Security teams simply don’t have the tools to examine everything in the browser. Security analysts and application developers with some client-side security experience generally have to cobble together multiple technologies and execute arduous manual client-side security processes. And often these processes must evaluate the security of each web asset individually. The result is usually a pragmatic “do the best you can with what you have.”
Balancing production with JavaScript and Github security risks
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. Marketing wants to get stuff out and IT wants to keep stuff out. An improved user experience necessitates a constant demand for increased functionality—better tools, more speed, and increased bandwidth. Unfortunately, it can take months to submit 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 can be a 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?
The best cat burglar is silent and invisible. The same is true with threat actors that compromise a website or web application. Malicious code can lie undetected right under the users’ fingertips. Meanwhile, it captures their data from form fills, chatbots, and 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 often take for granted that a piece of third-party JavaScript code is secure. 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 their to-do list.
Who are the bad guys?
Scores of highly trained cybersecurity professionals devote their lives to detecting and responding to cyberattacks. On the other side, similarly brilliant minds spend their waking hours devising cyberattack strategies, tactics, and malware that are as sophisticated as they are sinister.
Since a computer and internet connection is the only price to entry, 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 from Magecart and e-skimming?
If you are a managed security service provider (MSSP), app developer, or responsible for your company’s online presence, it’s up to you to prevent web asset infiltration and data exfiltration. This requires a complete understanding of your inventory. It also requires access to the tools to identify and eradicate malicious 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 Magecart and e-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.
