Angular2 and Spring — fighting CSRF in the wild.
In web security, cross-site request forgery (CSRF, also XSRF) is one of the most common attack scenarios. This article describes how to protect an Angular2 application that is served by a Spring backend. Good news: one line of code enables the so-called Cookie-to-Header Token protection strategy–if you’re on the attacking team, that’s bad news, of course.
CSR-what-the-f?
Let’s take a glance at a bit of knowledge. If you’re just interested in securing your Angular2 ♥ Spring application just skip to the next paragraph.
By design choice, CSRF is a built-in security hole in web standards. What sounds like a bold statement, should be taken seriously. It means every web application needs to protect against it and eliminate CSRF attack surfaces.
If you’re entirely new to the topic, I recommend watching the following video. While it takes ~22 minutes of your life-time, Dave Smith explains how the attack vector works, explains it by examples, and shows a live demonstration.
Cookies and Tokens
A token-based approach is shown in the video above. Beside that another handful of (more or less) reliable mitigations exists. One specific technique of a t0ken-based CSRF protection is the so-called Cookie-to-Header Token pattern.
Easy life for Angular2 developers: that strategy is built-in and enabled by default in Angular’s Http API.
Hard working days for Spring developers: you need to enable the strategy by instructing Spring security to use a so-called CookieCsrfTokenRepository.
The strategy was already implemented in AngularJS (Angular version 1) and Spring’s implementation was intended to be compatible with AngularJS in default configuration.
The important stuff is on lines 7 and 8.
We configure CSRF protection by setting a .crsfTokenRepository().
Such a repository implements a protection strategy and CookieCsrfTokenRepository is an implementation of the Cookie-to-Header Token technique.
We create the repository .withHttpOnlyFalse() so that cookies are readable by a JavaScript application in the web browser.
Ok, but that’s two lines of code?
Yeah, sure. If you’ve got the love, you’ll be able to write the whole security config on one line! You’ve got it:
Security matters. Security isn’t too hard. Just do it!
It’s live.
To better understand what is going on, we will look at a demonstration of the protection technique in action. The HTTP traffic was captured in HAR file format from a real-world application.
On application boot, the web browser requests GET index.html — the static HTML page that serves the Angular2 application.
Spring security is going to intercept the request and call through to CookieCsrfTokenRepository. The repository will create a new token that is sent in a cookie to the web browser.
On each subsequent request, the Angular2 application is going to read the token value from the cookie XSRF-TOKEN. It then supplies that token value in a HTTP header called X-XSRF-Token.
For HTTP requests that modify data–i.e., POST, PUT, DELETE, PATCH–Spring is going to verify the token. In our example, POST /foo-baris intercepted by Spring security and the token provided in the custom header is compared to the token provided in the cookie.
If one token values equals the other token value, the request is served and responds with a 200 Ok. If the two token values do not match, the response is a 403 Forbiddenand an error message tells you that the provided CSRF token was invalid.
Summary
Even if you never ever heard of CSRF, you’re able to protect an Angular2 and Spring web application in just a few minutes. Both frameworks go well together thanks to the Cookie-to-Header Token strategy.
In such an application set-up, the strategy presented above is a sufficient protection. At its heart, that strategy relies on the same-origin policy (SOP) applied by web browsers. Since CSRF attackers are considered to come from a cross-origin source, it’s impossible for them to read or intercept token values.
Update (2016–12–13): References and Knowledge on CSRF:
Adam Barth, Collin Jackson, and John C. Mitchell. 2008. Robust defenses for cross-site request forgery. In Proceedings of the 15th ACM conference on Computer and communications security(CCS ‘08). ACM, New York, NY, USA, 75–88. DOI: http://dx.doi.org/10.1145/1455770.1455782
William Zeller, and Edward W. Felten. 2008. Cross-Site Request Forgeries: Exploitation and Prevention. Department of Computer Science, Center for Information Technology Policy, Woodrow Wilson School of Public and International Affairs, Princeton University. URL: http://citp.princeton.edu/research/csrf/
