It is strange to think that not that long ago the Internet was a very different place. A place filled with static text content and marked up in HTML, served up alongside a few image files, and mostly consumed by a small population of persons with specific interests. Today’s Internet consumer demands a vibrant and responsive user experience customized to their individual interests—a localized cornucopia of options from around the globe, available on demand. While many advancements in platforms and networking have contributed to this evolution, the ability to execute script code in the browser is perhaps the most significant both in terms of user functionality and potential for security exposures. And its this ability to execute code within the browser that has raised the issue of the client-side attack surface and client-side security to the forefront.
What Is a Client-Side Attack?
A “Client-Side Attack” occurs when a user (the client) downloads malicious code from the server, which is then interpreted and rendered by the client browser. The classic example of such an attack is Cross-Site Scripting, which has been a staple of the OWASP Top Ten since its inception. These flaws are pervasive. A 2019 report from Feroot CX Security and Privacy, the 2019 Feroot User Security and Privacy Report concluded that the hidden activities of third-party tools and scripts expose up to 97% of organizations to theft of customer data. More recently, the 2021 Hacker Report showed significant year over year increases in reported web-related security vulnerabilities and that 96% of hackers are working on hacking web applications.
Sadly, these figures are far from surprising. According to that same 2019 Feroot report, modern web applications load an average of 21 third-party scripts as part of the user experience. This integration of third-party code creates a software supply chain that is assembled and executed on the client’s machine in near real time. The risk that one or more of the included scripts has been tampered with by threat actors at any given point in time is real and can have significant consequences as many organizations impacted by “web skimming” or “Magecart” attacks have learned. These attacks occur when an attacker inserts malicious script code, or a reference to include such code, into a payment or other transactional page. The code is downloaded and executed on the client browser which typically sends a copy of the sensitive information to a location of the attacker’s choice. Because of the subtle nature of these campaigns, they can be difficult to detect. For example, Warner Music recently disclosed that a number of the company’s on-line stores had fallen victim to such a campaign that lasted for several months.They are not alone. Many companies have been impacted by such campaigns and given the surge of online transactions as a result of the COVID-19 pandemic, it is no surprise that threat actor groups are increasingly focused on exploitation and monetization of such vulnerabilities.
Human Error Contributes to the Attack Surface
Even in the absence of malicious intent, simple human error can result in security impacting disclosures. If developers are passing sensitive details in the URL parameters or the page title of a web resource, analytics platforms may receive those elements. These may include usernames, credentials, or other information that could be considered personally identifiable information (PII). Legitimate scripts may collect sensitive data from the website for analysis without the full understanding of the developers or security teams responsible for site operations. If the third-party script provider is hosting operations internationally then the data may be routed to geographies that are of concern.
Three Ways to Defend the Client-Side Attack Surface
Traditional approaches to securing web applications and their supporting infrastructure are useful but fall short of addressing most client-side security risks. Endpoint security solutions are likewise useful, but do not extend to addressing the issues discussed here.
Regardless, since it is the reputation of the enterprise on the line, relying on a client to self-secure is a not a viable strategy even if there were a solution in that space. Given the nature of these issues, how can security professionals guard against them in their environment? The following are things to consider:
Educate developers: Training developers on security related issues is already occurring to some degree in most organizations. Incorporate the concept of third-party script inclusion as a dynamic attack surface and provide some targeted awareness training around the resulting risks.
Implement Runtime Application Self-Protection (RASP) solutions: Embedding a RASP solution into the code authored by your organization can provide highly accurate abilities to identify when other third-party embedded scripts attempt to take unsafe actions and prevent it from occurring.
Monitor for unauthorized script activity: Using a purpose-built solution to monitor for suspect script activity on an ongoing basis is the best way to detect if you have a problem in your software supply chain and minimize any impact to your customers or organizational reputation in a timely manner. Incorporating this data into SOC and incident response processes is also important. Tools like Feroot’s Inspector and PageGuard products provide visibility into web page blind spots, identify security issues and deviations from a baseline within third-party scripts. They also prevent future incidents from occurring by enabling in-app runtime JavaScript execution controls and shielding policies. Inspector and PageGuard easily integrate into developer and runtime environments so the SDLC continues uninterrupted.
Attack surfaces evolve, and as security professionals our solutions to address ensure the confidentiality, integrity and availability of enterprise operations must keep pace. If you would like to learn more about client-side security check out https://www.feroot.com/.
