Web design New York

As should be evident to anyone in the cyber security industry, the wide range of available web security solutions from commercial vendors will necessarily have varying degrees of effectiveness against different threats.

A premise of this article is that client-side security has been under-represented in these solutions – and to see this, it helps to briefly examine the specifics of the well-known web security solutions in use today, and their respective emphases.

Web Application Firewalls (WAFs)

The design of web application firewalls (WAFs) addressed the fact that the target of most malicious activity is not always the infrastructure surrounding a web hosting environment, but rather the application itself. By manipulating or exploiting security weaknesses in the critical applications of a business, bad actors could gain access to the most valuable assets.

WAFs are built to track the specifics of an application protocol versus the most foundational focus of an IDS/IPS. A WAF has the great advantage of being able to line up closely with the back-and-forth between user and application so that weird commands or other unusual behavior can be identified easily. Doing this properly is easier said than done, but a WAF positioned on the server side of an application architecture can be helpful.

Figure 1. WAF architecture

One challenge to WAF operation is the complexity of dealing with the incessant pace of change for applications in a modern DevOps environment. Another challenge, however, is a WAF’s inability to detect and mitigate client-side security exploits. Like an IDS/IPS, when exploit code finds its way to the user’s browser, mitigation of subsequent attack behavior is no longer in the purview of the server-side controls.

Secure Sockets Layer (SSL)

The use of Secure Sockets Layer (SSL) is an important contribution to secure eCommerce because it provides strong protection for the provision of user credential information – and, in particular, credit card numbers over the Internet. Virtually all eCommerce purchases today require some form of credit card exchange, and SSL has been invaluable in reducing the risk of this data being inappropriately observed in transit.

The infrastructure supporting SSL is surprisingly complex, and has required cooperation between various different organizations including the eCommerce vendor, the hosting provider, the browser companies, and security entities known as Certification Authorities (CAs.) Nevertheless, the SSL infrastructure for modern on-line transactional business is strong, and has benefited companies such as Amazon.com in a profound manner.

Figure 2. SSL architecture

While SSL has been a great success, its focus has been on the confidentiality of credentials, and not on the prevention of malicious attacks – especially on the client-side. Sadly, too much user training has incorrectly advised users that if they see evidence of SSL in action, that the “security issues” are covered. This might be true for avoidance of credit card sniffing attack in transit, but it is definitely not true for most web attacks, including client-side exploits.

Intrusion Detection Systems (IDS)

The most traditional means for protecting endpoints and infrastructure from security attacks involves insertion of an intrusion detection system (IDS) or intrusion prevention system (IPS) in-line with access to these components. The earliest IDS/IPS systems were built to detect attacks based on signatures of known methods, but more recent systems have been designed to include some more behavioral attributes.

Nevertheless, all IDS/IPS platforms inspect live session traffic to determine whether a given activity should be prevented from starting or terminated while on-going. This man-in-the-middle (MITM) approach its respective benefits and drawbacks, but it is common – especially since such functionality is regularly integrated into a next-generation firewall or gateway. The resulting architectural set-up for most enterprise looks as follows:

Figure 3. IDS/IPS architecture for web security

One challenge with any inspection-based solution is that encrypted communications traverse the MITM security with impunity. Another is that normal downloads to the client are not easily differentiated from malicious ones. Once a bad script finds its way past the IDS/IPS onto a client browser, the malware can run without the gateway security having any idea it is occurring. This does not remove the need for MITM security, but it does highlight a major weakness.

Client-side security

The provision of security for client-side attacks requires a new type of focus, one not found in many commercial solutions. It requires that security protections either pre-install on the client, or travel to the client in a dynamic manner based on the transaction being protected – usually a user with a browser visiting a website. The traditional deployment of client-side security for enterprise users has involved the following types of solutions:

Traditional anti-malware – The use of signatures as the basis for detecting malware continues to be a mainstay of modern enterprise security – and this extends to web application security. Many CISO-led teams rely on their anti-malware vendor to help reduce the risk of malware that might have been downloaded from a website. As one might expect, even with behavioral enhancements, this remains a weak control.

Virtual containers – The use of virtualized client computing environments, sometimes referred to generally as virtual containers, supports the idea that if malware finds its way to the endpoint, then it cannot reach real assets. This approach requires deployment of endpoint virtualized software, which often requires some work to minimize impact to application performance or use.

Web isolation – This technique involves a MITM gateway being positioned between the client and the website. Such processing can be software-only, or for higher assurance, implemented in hardware. The use of MITM gateways is shown here as a client-side protection because it extends the virtualization concept to the gateway.

Off-line detonation – The use of virtualized, off-line detonation is a useful means for detecting downloadable malware, and is commonly found in protection schemes for email attachments. It is also implemented frequently as part of a MITM gateway, and like isolation, complements the use of controls more specifically designed to protect the browsing session from website-born malware.

That such an assortment of methods exists is both good news and bad news for enterprise security managers: On the one hand, it is good news because these are all sensible controls, each with successful vendors supporting a range of enterprise customers. But it is also bad news in the sense that none address the problem of flexible, policy-based security policy enforcement for applications executing on the client browser.

In the next article, we’ll describe several standard application-specific controls that have emerged to address the risk of attacks such as Magecart, card skimming, and other web application and eCommerce-born exploits. The technology will be explained in the context of a typical client-side security platform, which implements content security policies, subresource integrity, and other security safeguards that should be of interest to the security team.