1

I'm trying to leverage spring security's built in CSRF protection. These are the spring versions i'm using:

Spring Framework version - 4.2.1

Spring security - 4.0.2

The spring security documentation mentions that the login page must also be protected against CSRF attacks. I see that my login does not work when i enable CSRF protection (and no token is passed) - as expected.

My login page is a pure HTML page (not a JSP) and i cannot make use of any Spring or JSTL tags. I'm thinking about implementing a solution similar to the one described here -

With Spring Security 3.2.0.RELEASE, how can I get the CSRF token in a page that is purely HTML with no tag libs

The solution as explained in the above link(the author's blog linked in the comment to the accepted answer) is to make a AJAX call on the login page that will get the value of the CSRF token and to then include it in the login request

However, the spring documentation also mentions that a new HttpSession will be created as soon as the csrfToken is accessed. I have a couple of concerns-

  1. My ajax call to get the csrf token will not be secured since i have to invoke it before the login.

  2. The fact that a new HttpSession is generated as soon as the CSRF token is accessed is also cause for concern given that the ajax call is not secured.

The rest of the application only makes AJAX or REST calls and I plan on implementing client interceptors to include the CSRF token in the header once the user is logged in.(As i understand it, there is one CsrfToken for the user session)

Does anyone have an idea on securing a purely HTML login page with spring's CSRF protection?

Community
  • 1
  • 1
jazzkookie
  • 110
  • 1
  • 10
  • why does it matter if the plain html or token fetch is "not secured", and what does it mean to be "not secured"? (neither one has to be a POST, and i can't see the harm in requesting that resource without the user's knowledge.) – dandavis Oct 16 '15 at 21:26
  • or in other words, if your app crashes because a robot hits the login page or requests a few-too-many tokens, your app is poorly written. – dandavis Oct 16 '15 at 21:36
  • or put another way, you don't need a buzzer on the gate if you have a strong front door. – dandavis Oct 16 '15 at 22:04
  • You are right in that there's no harm in requesting the resource. But creating how many ever HttpSessions even before login, would be a concern no? There are ways to detect and prevent DOS attacks like this and so maybe i'm overthinking this. I was wondering if this approach is acceptable or there are other ways that i haven't thought of. – jazzkookie Oct 16 '15 at 22:41
  • CSRF protection is to keep a form (usually) deep within your site from being filled out and submitted without the user's knowledge.you don't need it for urls without side-effects, like static html pages... – dandavis Oct 17 '15 at 01:06
  • @dandavis - This is to prevent forging login requests - https://en.wikipedia.org/wiki/Cross-site_request_forgery#Forging_login_requests – jazzkookie Oct 19 '15 at 13:00
  • in that case, you should be able to simply echo the token out into the html of the login page; it need not be secret. as long as each login request needs a unique piece of info that's impossible to guess, you won't get any CSRF attacks. – dandavis Oct 19 '15 at 20:16

1 Answers1

1

1) If you study about the CSRF vulnerability closely, you'll find that there would be no loophole in getting the token through a GET request.

2) After login/logout etc, when a new session is created, the token will change, and you may need to fetch it again. It's discussed more in this post.

Spring Lemon's source code would be a good reference on how to use AJAX+CSRF. See also this official guide.

Community
  • 1
  • 1
Sanjay
  • 8,755
  • 7
  • 46
  • 62