There are more than 1.8 billion websites online today, and almost 98% of them are powered by JavaScript. There’s a good reason for this: JavaScript’s flexibility and portability enable the rich online functionality we’ve all come to know and love. But what happens when that same functionality becomes a significant vector for cyberattacks?
Retail websites have more JavaScript-based services executing on the client-side than any other industry, with 83% of them third-party. This presents the greatest risk of a compromise in original tag JavaScript. Learn more about the state of security in eCommerce in this new report.
Websites integrate code and resources from multiple – sometimes hundreds – of third-party service providers. The marketing tags, chatbots, user analytics and rich content resources that enhance user experience have essentially transformed today’s websites into collections of web-enabled assets. The massive global supply chain of applications and code that websites draw from contains a potential downside: many of these assets operate outside the security control of the website owner. If they’re not properly secured, they can introduce vulnerabilities that enable client-side attacks. This type of attack presents its own set of risks, some of which can reach deep into your IT environment and threaten sensitive data.
Portable, scalable, hackable
Enterprise websites have long been a major target for attackers looking to steal assets of obvious value such as credit card data, privileged credentials or sensitive information. Vulnerabilities in the website supply chain are an attractive target for achieving this end, not least because of their scalability: a single compromise of a widely used component allows attackers to hit multiple users on multiple sites, all by exploiting the exact same vulnerability. One well-chosen attack on a widely used application gives attackers access to thousands of sites around the world simultaneously.
While ‘skimming’ and ‘Magecart’ attacks dominate the headlines, there are many different ways attackers can exploit JavaScript to access sensitive data – and many different types of information they can steal. Increasingly, web application attacks have become stepping stones in more complex attacks, where attackers exploit the application to steal credentials, which are then used to access the broader network and execute malware or exfiltrate sensitive data: 20% of malware directly installed by attackers was dropped from a web application. Why stop at payment card data when you can target the kind of data that impacts operations – very useful for developing future ransomware attacks that carry a far greater potential payout? Compromised web applications can be repurposed to distribute malware or help with Distributed Denial of Service (DDoS) attacks.
Needle meets haystack
As website supply chains become more complex and opaque, it’s difficult for organizations to establish precisely how many of these integrations are running on their websites – or who owns and manages them. A lot of the time, they’re added by marketing or web teams, outside the software development lifecycle, often bypassing code reviews and testing. When security teams are rarely part of the development cycle, they lack insight into when/where third-party code is used. What happens to the scripts no one’s using any more? Or the apps running on long-forgotten landing pages? When multiple different teams, with multiple different goals and skills are each working on the same websites and applications, it’s hardly surprising that they could be out of step. It’s a fair assumption that there’s a lot of untrusted, untested code running on enterprise websites that no one knows is there – and that’s the kind of place client-side attackers like to hang out.
Cross-site scripting, formjacking, cryptojacking, content injection, malicious ad injection, keylogging, session redirects, and data skimming can all exploit or hide in complex or forgotten web applications – most attacks can execute using less than 25 lines of code. For example, one recent high-profile Magecart attack used just 22 lines of JavaScript to steal 380,000 customer payment card details. Tailor-made to blend in with the victimized website, like all Magecart attacks, it had the capacity to avoid detection because all the nefarious activity takes place in the user’s browser (a.k.a. the client side). Transactions aren’t impeded in any way, the customers carry on entering their data, the retailer receives their payment and no one notices anything wrong. Until they do.
What can you do about it? Wake up and smell the Java[Script]
For many security teams, managing the client-side risk posed by JavaScript, third-party integrations and other web apps is a genuine challenge. Most organizations end up with a blind spot regarding the very services they’re supposed to protect.
Imperva’s Client-Side Protection provides security teams with visibility into JavaScript services executing on your website at any given moment. It automatically scans for existing and newly added services, eliminating the risk of them being a blind-spot for security. Imperva handles the difficult part of Content-Security-Policy for your organization, making it a viable part of mitigation. The domain risk score adds a credibility rating for each service, making it easier for security to determine the nature of each service, and determine whether it should be allowed to run or not. Simplified actions let you allow approved domains while blocking unapproved ones. Client-Side Protection ensures your customers’ sensitive information doesn’t end up being transferred to unauthorized locations and that no fraudsters are exploiting your visitors.
Client-Side Protection is a part of Imperva’s Application Security Suite. Start your Application Security free trial today.
Try Imperva for Free
Protect your business for 30 days on Imperva.
