Formjacking is a type of cyber attack that can be used by an attacker to steal sensitive information that is entered by website users through forms.  Most usually this type of attack targets ecommerce sites to obtain payment card details and personal information that are entered by customers; however, Formjacking attacks can target any website which accepts information through web forms. With stolen payment card details commanding an average of $45 each on the black market, a successful Formjacking attack at a reasonably busy ecommerce site can yield significant financial results for the criminals.

There has been a significant rise in the incidence of Formjacking attacks in recent months, with many of the high-profile attacks being attributed to the cyber-criminal gang known as Magecart.  Recent victims include Ticketmaster, British Airways and US retailer NewEgg.

How does Formjacking work?

Formjacking is a type of JavaScript injection attack.  Criminals find a way to change one of the JavaScript files being loaded as part of the webpage and the compromised file contains JavaScript code which alters the behaviour of the targeted form on the web page. In most cases, the modified web form is configured to send a copy of any entered text to a server controlled by the attackers.

It may be tempting to think that in a world of PCI-DSS compliance, where all source code is version controlled and all files on the web server are monitored by tools looking for unexpected modification, that it will not be possible for an attacker to modify the source code of your website – and you are probably right!  The problem is, most Formjacking attacks do not attempt to compromise your website directly – the criminals do not need to go anywhere near your servers in order to steal your client’s card details! JavaScript libraries that are imported from other Internet-based servers, can often be targeted by attackers, as these libraries may result in multiple websites belonging to many organisations to be compromised.

Do you trust your friends?

Because of the success of security standards such as PCI-DSS, ISO 27001 and Cyber Essential Plus, many (if not most) organisations that process sensitive data such as card payments, have taken significant strides to improve their security.

Regular website penetration testing ensures that organisation’s web applications are secure, while network penetration testing ensures that systems and servers are secure. Adoption of information security policies based on recognised standards, such as ISO 27001 and PCI-DSS ensures that organisation’s policies and processes are secure.  As a result, cyber-criminals have moved their attention elsewhere and gone looking for the weakest link in the chain.  This has given rise to a new wave of attacks against your suppliers and business partners in what is known as supply chain attacks.  The logic is simple – if you trust your suppliers enough to bring them (or their code) inside your secure perimeter, then if criminals can inject malicious code into your supplier’s system,  the chances are it will be treated as trusted code by your security monitoring and be welcomed with open arms.

In the case of Formjacking, or any JavaScript injection based attack, the risk is actually much greater and the chance of detection much less.  This is because of the way in which web pages and JavaScript function.

The anatomy of a modern web page

Modern web pages should be thought of as being less like a page of formatted text (like a Microsoft Word Document) and more like an integrated computer program that creates a page of formatted text. The source code of the computer program is a combination of HTML and JavaScript and your web browser interprets the instructions in the HTML and JavaScript code and displays the results to you. When you visit a website, what actually happens is that the web server downloads a file of HTML and JavaScript to your web browser which is then processed (or rendered) by the web browser in order to create the web page that you see.

One of the things JavaScript is used for is to generate additional HTML “on-the-fly” as the page is processed by your browser, so that the web page is generated dynamically on a per-user basis.. This is how responsive web pages work – JavaScript in the page detects whether you are using a phone, tablet or desktop and then produces different output accordingly, formatted for your device.  The web page you see on your screen can therefore be very different from the original source that was downloaded from the web server, because the JavaScript rewrites the HTML as it is processed and all you get to see in your browser is the final output.

Nobody likes to re-invent the wheel, least of all software developers, so there is a well-established eco-system of JavaScript libraries that are re-used across many web sites.  For example, the jQuery library is used by over 66 million websites to process events, display animations and handle AJAX processing for web applications.

The way JavaScript works makes it very easy to import a library of JavaScript code from another website and then use its functionality within your webpage.  Usually, this code is imported directly from the library author’s own web  server into the user’s browser. So a webpage being downloaded by a visitor to a website will also download JavaScript libraries from third-party web servers, such as jQuery and often dozens of others.  Services such as Google Analytics, EU Cookie Disclaimers, marketing analytics, chat bots and many others all work by having their JavaScript libraries dynamically imported into web pages.

Importing the JavaScript directly from the vendor makes a lot of sense at first glance. It means you always use the latest version of the library and it offloads some of the download bandwidth to someone else’s server.  The downside however, is that these JavaScript libraries are necessarily trusted by you and your client’s browser.  As a result, an attack which compromises the source code at any of your suppliers will enable the attackers to inject arbitrary JavaScript into your webpage and change its behaviour without you or your clients being aware.  This is an example of a supply chain attack.

This style of attack is exactly how Magecart was able to steal card data from Ticketmaster customers for nine months. The criminals compromised the chatbot provider Inbenta that was used for customer support on the Ticketmaster website.  By compromising the chatbot Javascript library, the attackers were able to inject JavaScript which altered the behaviour of the ecommerce checkout system and capture a copy of the card details submitted by customers.

Research from Symantec suggested Formjacking is on the rise with 4800 websites being compromised each month according to their recent Internet Security Threat Report. By using compromised third-party JavaScript libraries, criminals do not have to target a large number of individual websites. By focusing on the supply chain and attacking third parties libraries that are used by many different websites, criminals can magnify their attack very easily.

How to safeguard against Formjacking attacks

You can protect your own source code from attempts to install malicious Formjacking code by treating your source code with the same care as you do high value client or payment data:

• Secure source code repositories and files against unauthorised access and modification.
• Implement change control measures to validate and authorise all changes.
• Peer review all code changes to ensure the stated reason for change matches the actual changes being made to the code.
• Implement automated file change detection and monitoring for source code repositories and web server folders.
• Use automated source code analysis tools to identify unexpected behaviours in the code.
• Monitor and analyse all browser traffic during testing to ensure no unexpected connections are being made to third party servers.
• Conduct regular penetration testing of your web application or at any time where a significant change has been made to the source code.

If you are using third-party libraries in your webpages, consider these additional steps to protect yourself from supply chain attacks:

• Review the security measures your suppliers have in place for their source code and compare them to your own on a regular basis. Consider insisting they comply with a recognised standard such as ISO 27001.
• Host third-party JavaScript libraries on your own server rather than importing them from the vendors server. This way, you can control any changes to the source code and have full-control over the web server security.
• Implement Subresource Integrity checks to protect against unexpected modification of third party libraries used on your web pages.
• Monitor and analyse all browser traffic during testing to ensure no unexpected connections are being made to third-party servers.