Don't become a Web Security Dinosaur!

On the left, you can see a screenshot of the Yahoo! search engine back in 1999. On the right, a screenshot of Netscape Navigator from 1999, the dominant browser at the time.

The reason I started out this article by going back to the previous century is to remind you how the web has changed over the years. But even back in the 90s, web security was already and important topic (did you know that the first article about SQL injection is from 1998?). Vulnerabilities such as SQL injection and command injection were already a reality in the 90s, and developers had to actively implement countermeasures to prevent these vulnerabilities from being exploited. The defenses against these attacks are not very difficult to implement, and have gotten even better over the years. Unfortunately, even today we still struggle to get security right, and we’re talking about issues that we’ve known how to fix for over a decade. Plenty of applications still suffer from these vulnerabilities today, and server-side injection attacks still rank first in the OWASP top 10.

Traditional server-side vulnerabilities still rank highly in the OWASP Top 10, a list of the 10 most dangerous Web security issues.

The Attacker’s Unfair Advantage

Traditional attacks, such as SQL injection and command injection, are focused on the server-side components of the application. Over the years, the focus of attacks has shifted towards the client-side context as well, opening up a totally new range of capabilities. Take cross-site scripting (XSS) for example. In an XSS attack, the attacker puts malicious code somewhere in a data field of the application, which will trick an unsuspecting user’s browser to execute this code. When the code is executed, the attacker can perform actions from within the victim’s browser, with potentially devastating effects. Another example is a man-in-the-middle attack on the victim’s network, giving the attacker full control over each request and response that is being sent. This allows the attacker to manipulate the data, take over the user’s session, etc. A third and last example is a clickjacking attack, where the attacker tricks the user into clicking on a specific button in any web application by using invisible transparent overlays using transparent overlays, causing unintended actions to be executed.

Naturally, as these new attack vectors where discovered, refined and actively being exploited, numerous new countermeasures and defenses were proposed. Traditionally, countermeasures against these attacks were implemented in the server-side components. For example, to protect against XSS, the server must encode very output in a context-sensitive way, and to prevent network-level attacks, HTTPS should be used. Protecting against clickjacking is not even possible by adding some server-side logic, which means that without cooperation from the browser, there is no way to prevent such an attack from happening. This is definitely an unfair advantage, which has been addressed by enhancing modern browsers with various client-side security features.

Enhancing the Developer’s Security Toolbox

Adding security measures at the server-side only gets you so far, especially because of vulnerabilities such as clickjacking, cookie stealing and SSL stripping, which happen entirely on the client-side. These vulnerabilities are exploited without the involvement of the server in any way, so there are no server-side defenses against these attacks.

Such a situation has inspired many researchers in the field of web security to develop client-side security measures, such as a security-enhancing proxy or browser add-on. Eventually, these kind of countermeasures have lead to an important new security paradigm: server-driven browser-enforced security policies, where the server can dynamically configure a specific security feature in the browser. For example, with HTTP Strict Transport Security (HSTS), the server can eliminate the risk of SSL stripping attacks, a simple trick that greatly enhances the security of your HTTPS deployment.

Did you know that between the introduction of SSL Stripping in 2009, and the implementation of HSTS in 2012, websites could not protect their users against this attack? And since 2012, only a very small amount of sites has actually enabled HSTS support.

Essentially, as browsers advanced, and became full-fledged application platforms, they also gained various new security features. These security features allow the developer to dynamically enable security measures at the client-side. The most simple example of such a server-driven security policy are the cookie flags HttpOnly and Secure, which allow the developer to restrict access to cookies in certain situations. Today, browsers support numerous client-side security policies, which offer a high degree of configurability over various security aspects of the application.

• HTTP Strict Transport Security (HSTS) and HTTP Public Key Pinning (HPKP) give you the possibility to enhance the security of your HTTPS connections, preventing attacks such as SSL stripping or man-in-the-middle attacks with rogue certificates.
• X-FRAME-OPTIONS (XFO) gives you control over who can frame you, to prevent clickjacking attacks.
• Subresource Integrity (SRI) allows you to verify the integrity of script and style files you include from a CDN, to prevent someone from injection malicious code through these files.
• Content Security Policy (CSP), the most extensive client-side security policy of this time, gives you fine-grained control over the resources that are being loaded into the browser context, along with various other features. CSP also allows you to restrict framing, thereby deprecating the X-FRAME-OPTIONS header.

Avoid Becoming a Web Security Dinosaur

Virtually all of these new security features have been introduced in the last 5 years, which brings me back to the title of this post. Most developers have followed the evolution in web technology in the past few years, but few are aware of how web security has changed recently. If you still think the same about Web security as you did 5 years ago, it’s time to take action and get up to speed with these new technologies, which give you a tremendous amount of power. Today, the security toolbox of a web developer is better than ever, so it’s up to you to build better and more secure web applications!

I’ve been going around the country to raise awareness about these changes in the web security landscape. I’ve talked at various meetups (NodeJS Belgium, JavaScript Lab, Ixor Tech Talks), and have been invited by several companies to talk at one of their internal events or conferences. If you want to help me spread the message and invite me to your organization, don’t hesitate to get in touch. Apart from spreading awareness, imec-DistriNet also gives immersive hands-on trainings on these topics, so subscribe to the mailing list to receive notifications of these events.

Did this come as a wake-up call for you, or have you already implemented these new security technologies? Let me know in the comments!