Debunking myths related to client-side security and Magecart attacks

The client-side landscape has been overrun by third-party script attacks executed by malicious attackers utilizing formjacking or other methods made famous by the Magecart attack group.

Many companies assume their current security stack ensures protection for these seemingly basic attacks, but in reality, they open a can of worms and you may not even know you’ve been attacked. Take a read below to see some of the common misconceptions regarding client-side protection, these dedicated threats and if your business is in fact safe.

Myth #1 – I don’t need to worry about client-side security unless I have a virtual shopping cart/eCommerce

While formjacking is heavily concentrated in online retail, there is a significant weakness in other pertinent verticals as only a few lines of code can interrupt any organization that collects personal information on a website.

Attackers also utilize malicious JavaScript injections running almost seamlessly with your third-party vendor scripts that a website utilizes to improve performance or experience. These are all areas of potential vulnerabilities and if not monitored, can prove costly.

Myth #2 – I have a firewall, WAF and a secure connection so I’m safe from these attacks

Firewall, WAF, secure connection and many other solutions are focused on securing internal servers and the communication between the browser and these internal servers. Formjacking and Magecart attacks are executed on the user’s browser and in many cases, load from a remote server. This client-side connection operates completely outside of the security capabilities an organization deploys to secure the server side of the browser session.

Myth #3 – RASP or DASP catches formjacking and Magecart-type attacks

Dynamic Application Security Testing (DAST) is usually active on a pre-production environment and does not cover live sites. The few who run DAST on a live site will simulate a few user profiles but cannot possibly scale this solution to monitor and detect all web sessions.

As third parties change their behavior from user to user, DAST is largely ineffective in detecting attacks on large production networks and completely ineffective at preventing these types of attacks. Detection methodologies do not help organizations fulfill compliance guidelines requiring customer data privacy.

RASP is Runtime Application Self-Protection; it exists only on the Java virtual machine and .NET Common Language Runtime. Since it will not run on the actual live site, third parties are outside of its detection scope. Again, RASP is not intended as a prevention solution. Detection methodologies do not help organizations fulfill compliance guidelines requiring customer data privacy.

Myth #4 – CSP and other page headers will stop Magecart attacks

CSP is often being suggested as the solution for Magecart attacks. Although it can be part of the solution, by now we know that a lot of the Magecart attacks are being done from trusted domains. Take for example the 24/7 chat hack that captured payment card information from huge enterprises websites such as Delta Airlines, Sears, Kmart, and BestBuy. This tool was trusted by those firms and needs to be whitelisted by the CSP in order to work.

Other headers such as HSTS are sometimes also mentioned as a possible solution but all of us understand that by now attackers are sophisticated enough to use SSL (https) when loading their payload to avoid this header as well.

Myth #5 – Magecart hackers need to use a “drop server” to capture the data

In most of the known Magecart attacks, the payload is being delivered by a trusted domain (for example a third party vendor) and the data it collects is being sent to the hacker server, also called “drop server”. In some of the attacks we are seeing the hackers are using domain names that look legit to avoid detection, for example, the drop server in the British Airways attack was under the domain “baways.com”.

But the more sophisticated hackers will avoid using a drop server altogether and create an account in one the third parties the website use in order to capture the information in an undetectable way.

Using Google Analytics to capture user credentials

Myth #6 – You can detect all Magecart attacks from the outside without implementing code to your website

Using a tool to scan the website from the outside in order to capture those attacks is a VERY low barrier that can be overcome by simply using one of the most common methods almost all third-party vendors use. By nature, third party code is dynamic and can adjust to run only for specific users – for example, when you go to a website, you will see an advertisement that is related to your browsing history, and some else will see completely different advertisements according to his history.

Hackers are using those same methods to avoid detection so the hack payload will be applied to real users and not shown to an outside scanner, sometimes limiting the hack to be sent only to a small percentage of the site visitors to avoid detection by humans. In order to detect Magecart, you need real-time all the time protection.

Myth #7 – If I am being attacked right now my team would definitely be aware of it

As proven by the Magecart attack that affected over 800 websites for 3 years, many dedicated attacks are very hard to detect. If you Google “undetected Magecart attacks” the search will return a number of recent threats that top Fortune 100 companies unfortunately experienced. While security teams are trained in responding to DDoS and bot attacks, these vectors are new and evolving establishing additional operational costs in dedicated man hours and more than likely a third-party solution alternative.

Myth #8 – Third-party risks are the top concern your company should be worried about

While third-party risks present the largest issues at hand, you can’t diminish fourth- and fifth- party risks that come as extensions of third parties.

Even the most security-driven websites, who audit and test the vulnerabilities of the third-party scripts they interact with (which is in itself rare and difficult to follow through), still remain exposed through the fourth- and fifth- party scripts these suppliers interact with. This makes the process of fully protecting websites and their users from attack scripts much more challenging.