CSRF is disabled, any plans to enabled this?

[kramik1]

I noticed that CSRF is disabled in the code. I know there are a number of code snippets out there to add csrf support to angular etc. Does this require glue code as well? I am looking at a number of various front-end javascript frameworks to overhaul our current web based product manager and this example is pretty comprehensive.

[geowarin]

Hi @kramik1 !

Very good question. Since the application doesn't use cookies (no sessions) I don't think it is vulnerable to CRSF attacks (in which the attacker uses hidden forms to usurp your site's cookies).

However, since the authentication token is stored in local storage, it is indeed vulnerable to XSS (in which the attacker injects a malicious script into your application, can therefore run code in the client's browser and have access to its local storage).

If you decide to use the application as-is (no extra script from CDN or other locations, no unsanitized data in your html) you should do ok defending yourself against XSS attacks.

If you are looking for a bulletproof authentication mechanism, I think you should do as this guy says: JWT + secure cookie.

I'm not a security specialist so please correct me if I said something wrong. Implementing JWT is a piece of cake, I started implementing it a while ago but somehow figured it would add a bit of unnecessary complexity to the application.

What do you think ?

[kramik1]

Thanks for responding back with a detailed answer. I think we are on the same page. I just needed to do some more background reading.

I read up on SpringSession in some free time and understand what you are referring to now. SpringSession implements its own sessio not being explicit enough. n mechanisms to replace the standard HTTP session built into each Servlet implementation. It also by default sets up a repository to store that information; this makes it portable between application servers. The session token is stored in localStorage which has mostly upsides over cookies (cookies need to be marked as secure and httponly). The typical browser session is replaced with a token referring to the session data kept on the backend. This is a compromise between an entirely stateless API and hopeful increases in response times.

So turning off sessions with SpringSecurity is only being replaced by SpringSession for scale, portability and extendability (can do JMS also for example). I need to look at JWT. It looks really interesting but we intend most of our application to be accessed by machine to machine RESTful; not sure if applies to that scenario.