Let's admit it: Many of us who first included/upgraded Spring Security to 4.x+ were shocked when all of a sudden even our simplest login page starts giving 302s and bouncing back like this question in StackOverflow . More often then not, you will find this evil hack in the solution which works like a charm:
@Configuration
@EnableWebSecurity
public class CustomWebSecurityConfigurerAdapter extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http.csrf().disable()
...
}
}
Yea, Spring security is always complaining you're missing that dreadful CSRF token unless you disable it. I admit the above code is almost a given in my past projects. But let's take some time to get this sorted: what is this CSRF token anyway and what should we do to make it work in a modern architecture?
It's all about your Browser
Somehow, in the countless articles that describes the CSRF attack, I feel that there is something which is either too obvious or just not emphasised enough: Most of the well-known attacks (which we were always being asked by the CyberSecurity team to remediate) are based on the assumption that the end users use a trusted, modern up-to-date browser to perform their daily activities. These "trusted browsers" all have a set of rules which disallow certain functionality by default, for instance:
- If you're logged in devdojo.com and it gives you a cookie, the browser will only set the cookie when you perform actions with devdojo.com. You would be able to retrieve that cookie if you're on some other site (meaning, your address bar is at somewhere different)
- If you're on devdojo.com, you can't write scripts that go to any other site. The call will still fire, the browser will stamp your Origin (the site in your address bar) in the header but the server will reject it by comparing the current site address against the origin -- This is called the Same Origin Policy. The only exception is that if the server gives a specific called CORS (Cross-Site Resource Sharing) which we will discuss later.
Many of the discussions around forums revolve around some "what-if" scenarios such as whether the Origin could be forged and the server would not be able to distinguish whether a call is legitimately coming from the Origin specified or not -- this is why I think a "trusted Browser" is so critical in the discussion: If you don't believe the browser enforces the rules properly, then all the protection breaks down and any hack is possible. So, rule of thumb, use a good browser to surf the internet :)
CSRF attack in Simple Terms
There are numerous examples out there, and this is not the focus of this article. I read this to make myself familiar with the topic, so it might help you too. In simple terms, CSRF tricks you to do something unintended on a site that you are logged into, by utilising your session (cookie). Say I logged into Devdojo (assuming it just uses session cookies and nothing else) and in another tab I wondered into some hack site -- the hack site has an auto-load link to Devdojo which posts an offensive post using my account. If Devdojo doesn't have CSRF protection, it will succeed because
- I am logged into Devdojo (hence an active session)
- Devdojo will not be able to distinguish the request from the hack site VS a legitimate request if there is nothing apart from the session cookie to verify
Hence there is this CSRF token to guard against unintended actions: this token must be included either as a specific header (e.g. "X-CSRF-TOKEN" for Spring Security) or in the body, not as a cookie, for the server to verify. Being not in the cookie means that it will not be included automatically by default, so some scripting must be made to fetch and put the token at the correct place. This hack would not be easy if you are using a trusted browser, in which the browser's rules are upheld properly (which I will go through below).
CSRF endpoint -- is this safe?
The first question to solving the CSRF token problem is, how do I get the token at the first place? Traditionally, the tokens could be obtained and injected easily if you are using server-rending pages like JSP which you could just embed the token in some hidden field. But if you are using more AJAX libraries like React, then the problem becomes not so obvious: how do we get that token secure enough as not to get hacked?
Firstly, the answer: Exposing a CSRF endpoint is the easiest way to go, like the following:
@RestController
public class CsrfController {
@RequestMapping("/csrf")
public CsrfToken csrf(CsrfToken token) {
return token;
}
}
Hang on, is this really secure enough? Everybody could get the token! Yes it is, at least I am convinced by this article. Why? remember, the attack happens when we are on some other site and some malicious link exists to utilize our existing session. But that is not enough. It needs to script the following:
View Website
View Website
View Website
- a call to get the CSRF token
- extract the token and put it in header of the malicious call
- fire the call
Now, again, with a trusted browser , it would never allow scripts at the bad site to make the first call to the good site (a cross site call) to get that CSRF token at the first place! So we are safe. The only exceptions are:
- you enabled CORS allowing any origin for the CSRF token, or
- this bad script is actually somehow injected in your site, which is a completely different problem called XSS (cross site scripting).
So you mustn't let the above two cases happen.
Client/Server Implementation code
Now with the above in place, the client side code is relatively straightforward -- just to make a call to get the token, put it in headers before the real call is done (I'm using axios here):
import axios from 'axios';
function post(path, data) {
return axios.get("/csrf")
.then(tokenResp => {
let config = {
headers: {
'X-CSRF-TOKEN': tokenResp.data.token,
}
}
return axios.post(path, data, config);
})
.then(res => res.data)
}
I would also add the below to the Web Security Configuration:
@Configuration
@EnableWebSecurity
public class CustomWebSecurityConfigurerAdapter extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.csrf().ignoringAntMatchers("/login")
.ignoringAntMatchers("/perform_login")
.and()
.authorizeRequests()
.antMatchers("/login").permitAll()
....
}
}
My reasoning: It makes no sense to validate CSRF tokens if you are not even logged in.
Developing with React
One last thing before I end the article (phew, this is a long one). When developing with React, most likely you will be doing npm start which opens http://localhost:3000 and proxy all your requests to a backend server (Spring's localhost:8080 in my case). Now localhost:3000 => localhost:8080 is cross origin and all the calls would fail!
What you would see is something like this in your browser's Developer Tools console:
Access to XMLHttpRequest at 'http://localhost:8080/login' (redirected from 'http://localhost:3000/api/version') from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
So how do you fix this? Earlier I mentioned browsers have a "Same Origin Policy" that could be overridden with something called CORS (Cross Origin Resource Sharing). So now this is where it comes into picture. You could allow localhost:3000 as an "allowed origin" so that it won't be blocked by the browser -- now use this carefully, you might you yourself up to a variety of security issues if used wrongly:
@Bean
public WebMvcConfigurer corsConfigurer() {
return new WebMvcConfigurer() {
@Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/**").allowedOrigins("http://localhost:3000");
}
};
}
There is also the ultimate permitAll() weapon which you could just expose your app completely in the open sea... there will be no cross origin warning whatsoever and the browser won't complain :)
@Configuration
@EnableWebSecurity
public class CustomWebSecurityConfigurerAdapter extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http.anyRequest().permitAll()
}
}
To have any practical sense, this should be used only with a local development configuration -- or better, never use it at all (unless a deadline is pretty close ;) )
Next I'll drill into JWT (Java Web Tokens). Stay tuned!
Comments (0)