A client-side perspective on web security

Threats to web security are explained in this first of a three-part article series, and client-side security is shown to address a commonly missed class of cyber attack exemplified by Magecart. Traditional solutions to web security are outlined, including a new approach to web security based on client-side standards such as content security policy and subresource integrity. These emerging approaches are explained in the context of a representative client-side security platform.

Introduction

Perhaps the most salient aspect of cybersecurity as a professional discipline is its continuous cycle of change. That is, as cyber attacks emerge that challenge the confidentiality, integrity, or availability of some on-line resource, corresponding protection solutions are invented to reduce the risk. Once these solutions become integrated into the underlying fabric of the resource of interest, new cyber-attacks emerge, and new solutions are invented – and the cycle continues.

In some cases, new protective cyber solutions have the side-benefit anticipating new forms of malicious attacks – and in cases where this works, security risks are often avoided in a wide range of different scenarios. Two-factor authentication, for example, was created in response to password guessing, but is now an important component in the design of new Internet of Things (IoT) machine-to-machine application protocols to reduce risk.

Nowhere is this process of introducing and mitigating cyber risk more obvious than in web security – also referred to as web application security. With valuable assets being provisioned and managed increasingly through web-based interfaces, the value of web-based exploits continues to rise. One consequence of this rise is that despite the many technologies available to protect web resources, the gap between offense and defense is growing.

A main premise in this technical series is that this web security gap stems from the fact that most application execution occurs on the modern browser. The web security community has long recognized the need to deploy functional controls to safeguard the server-side vulnerability of web servers delivering content and capability to client browsers. Too little attention, however, has been placed on this client-side vulnerability, which is attractive to attackers and largely ignored by today’s security infrastructure.

The three parts that follow in our series are intended to help address this oversight. In Part 1, we offer an introduction to the most common cyber attacks that target websites today. Part 2 then provides an overview of the web security solutions that are deployed in most production environments today. Finally, Part 3 offers an introduction to how a representative client-side security solution can help rectify the client-side weaknesses exploited by bad actors today.

Common attacks to websites

Commensurate with Tim Berners-Lee’s idea in the mid-1990’s to layer hypertext protocols and markup languages onto the Internet protocol (IP) came the emergence of offensive means to attack the infrastructure, systems, and applications that make up the now-called web. And thus was born the discipline of web security, which can be defined as the set of protective measures required to manage the security risk of web-based computing.

As one would expect, the taxonomy of web security issues quickly grew in several directions, but early focus was on avoiding denial of service attacks, protecting hosting infrastructure, and ensuring free flow of web content to users. Such focus on availability corresponded to the observation that if a website was down or not working properly, then eCommerce transactions would not occur – which had obvious revenue implications.

In addition to these infrastructure concerns, however, came a growing observation that application-level security issues might have severe consequences – often to the privacy of customers visiting a website. Thus was born the so-called web applications threat, which quickly evolved from a small concern to a massive security challenge. Even today, finding sites with exploitable vulnerabilities in their web applications is an easy task.

Several standard attack strategies have emerged in recent years that have been difficult to eradicate. These nagging problems prey on the complexity of many web application designs, and on the relative inexperience and ignorance of many web software administrators. Below, we describe these strategies – four in total – that continue to drive risk into eCommerce infrastructure and to cause challenges for many enterprise security teams:

Cross-Site Scripting (XSS)

The most common application-level web security attack is called cross-site scripting or just XSS. A cross-site attack involves a technique known as injection – where the attacker finds a way to get scripts running on a target website. The ultimate goal is for that targeted web application to send the attacker’s code to some unknowing user’s browser. The XSS attack works best when a website accepts, processes, and uses input without much checking.

The end goal is that the attacker has managed to inject code into someone’s browser. That user will expect any downloaded scripts to be fine, since they came as dynamic content from the visited, and presumably trusted website. Their browser will then execute this code, often JavaScript, thus exposing sensitive information such as session tokens or cookies to the original attacker. The XSS code can also redirect a user to some infected website.

Figure 1. XSS Attack Schema

Organizations such as Open Web Application Security Project (OWASP) suggest various defenses against XSS attacks. Their suggestions, many of which continue to be ignored by practitioners, involve common-sense coding and web administrative procedures that improve the processing of data from users. Most involve better validation of input data on the server side, which is a welcome security control and should be present in any web ecosystem.

Content and Ad injection

The challenge of dealing with content and ad injection attacks, also known as malvertising, has increased substantially in recent years. This should come as no surprise given the rise of the on-line advertising ecosystem as a force in modern business. Some estimates have the size of on-line advertising now reaching aggregate levels as high as $100B. Hackers and criminals understand this trend – and take advantage of exploitable weaknesses.

The way malvertising works follows a similar pattern to XSS attacks: Malicious actors find ways to inject their code onto websites through legitimate advertising networks. The goal, again similar to XSS, is to target visitors to the site, usually with the intent to redirect their browsers to some targeted website that has been planted with malware and that forms the basis for whatever attack is desired, such as credential theft.

Many observers have referenced the injection process as involving something called a drive-by download. This term references a user viewing an advertisement using a browser with an exploitable vulnerability (which is sadly a common scenario). While the user interacts with the ad, a redirection process is initiated whereby the malicious software finds its way to the unsuspecting visitor to the site.

Figure 2. Drive-By Download via Malvertising

The traditional solution to this problem involves placing a control such as a web application firewall (WAF) in-line with the access. The WAF would be programmed to use signature or behavioral analysis to stop malicious code execution from untrusted sources. As with XSS security, this server-side protection is commonly found in advertising ecosystems as a primary control. Such emphasis can address malvertising, but might not work for all forms of attacks.

Magecart

The hacking group Magecart emerged several years ago, terrorizing websites with an attack known as card skimming. Normally, hacking groups tend to come and go quickly, but Magecart hit a nerve with their targeted breaches of enterprise websites and web applications. Wide ranges of different organizations saw their sites formjacked, and security solutions were not immediately evident to most victims.

The man-in-the-middle attack from Magecart is quite simple to explain: It begins with malicious code added to the JavaScript served to clients from a website. The malicious code then watches for and collects sensitive data such as credit card information from legitimate users visiting the site with their browser. The data is exfiltrated to a malicious drop site and is unloaded in the usual illegal manner. It’s that simple.

Figure 3. Magecart Card Skimming

The nagging issue, however, is that common server-side security tools don’t account for this man-in-the-browser (MITB) attack because it occurs on the client side. Web application firewalls (WAFs), for example, don’t see the JavaScript activity and have no means for scanning libraries for code insertions. And when this attack is served from third or fourth-party hosted sites, the cascading result is something called piggy-backing.

Contributing author: Aanand Krishnan, CEO, Tala Security.