Blog
Attacks on users with malicious JavaScript is trending upward and is impacting organizations through attacks suck as Magecart. These attacks are currently being utilized to steal credit card data by hosting malicious JavaScript in ways that site owners are unable to identify until a breach occurs. These attacks can lead to reputational damage and huge fines as seen by the $230 million fine to British Airlines.
The attackers are continuously adapting to bypass existing security measures but by implementing stricter controls; the attack surface can be significantly reduced and your users could be at a lower risk of compromise. The attackers are currently utilizing three primary attack vectors, including the following:
Web application compromise leading to the changing of code. If your web application is vulnerable and is taken over, the attackers can easily replace your existing code with their malicious one.
The server hosting the JavaScript is compromised. Many organizations utilize third-party hosting (such as EC2) to host their JavaScript, but those servers are rarely considered part of their hardening standards. For more information on Magecart risks to EC2, please visit Third-party Risk: Magecart Creditcard Attacks
Third-party service provider is compromised. Utilizing chat and payment functionality through a third-party is common and those providers need to be held accountable to the same security standards you are.
The Technical Issues
Below are the five technical issues typically identified through-out our engagements. By understanding each of them and their corresponding risks, your organization can take steps to prioritizing the issues based on your environment. The five are in no particular order and can vary in importance based on each unique environment.
Missing Content Security Policy (CSP): The CSP limits the external sources to which a website can connect by whitelisting trusted sources and blocking every other connection. CSP makes it easier to reduce the attack vectors by specifying the domains that the browser should consider to be valid sources of executable scripts.
Missing File Integrity Check: Subresource Integrity (SI) validates the integrity of files by enabling the website to block external scripts when this file integrity changes. This involves hashing the file contents using SHA and storing that hash within the HTML script tag. If the browser identifies that the hash within the HTML script tag is not the same, it would block the request.
Third-party Code: Linking to third-party code is not out of the ordinary, but reducing the number of servers hosting your JavaScript should be considered.
Advertisement and Analytics on Payment Page: Using analytics and advertisement on payment pages increases the risk to those pages being impacted by card skimming given they use external sources. It is better to have less JavaScript on critical flows.
Isolated Payment Flow: The payment flow was not found to be isolated which can result in malicious JavaScript capturing user credit card data. Isolating the payment flow in an iframe prevents scripts from executing entirely, which would prevent any card skimming JavaScript.
Remediation
To remediate findings related to malicious JavaScript prevention:
Missing Content Security Policy (CSP): Enabling CSP can break advertisements unless the advertisements are all coming from domains that you can specify. The recommended header setting is: Content-Security-Policy: script-src ‘self’ which would prevent any JavaScript from making outbound requests. To review the possible use cases and how it can apply to your environment, please visit the following link for more information.
Missing File Integrity: There are multiple ways to enable this and it could be combined with CSP. One way involves using a hash that can be obtained from SRI Hash for any externally hosted files. The hash would then be used within the integrity parameter within the script tag. Mozilla has a great resource on Subresource Integrity that is very helpful.
Third-party Code: Review all external JavaScript links and try to reduce the number of them. Any third-party services such as chat should also be included in security testing.
Advertisement and Analytics on Payment Page: Remove analytics and advertisements from the payment flow.
Isolated Payment Flow: Create an iframe sandbox with the sandbox attribute set. For more information, please review W3schools for more information.
Organizations usually exclude third-parties from their scope when conducting a penetration test. At Packetlabs, we identify third-party dependencies, notify our clients, and include them in our testing to ensure all areas of the web application are tested. Each critical flow is audited against the five issues identified above as part of our robust methodology. Contact us if you would like to hear more about our services.