0

I've looked at the following SO example which says that a unique token must be placed in the URL posting data.

That way if anyone creates a url like http://example.com/vote/30 it won't work because it does not contain the unique token.

I'm also reading through this tutorial which places a XSRF-TOKEN in the header. I'm just curious as to how this provides protection because if the user is logged in and clicks on http://example.com/vote/30 won't that request still pass?

In other words if I'm logged in and someone sends me the http://example.com/vote/30 link in an email and I click on it, wont that link still pass the the CSRF check, or will the browser not send the required headers since the the link will most likely open in a new tab?

It seems like the when the link is clicked the new tab will request the page. However the new browser window will not have the same XSRF-TOKEN that the logged in browser window has? Am I understanding this correctly?

Community
  • 1
  • 1
Ole
  • 41,793
  • 59
  • 191
  • 359

1 Answers1

4

CSRF

This above article offers a good explanation of what a CSRF attack looks like. The basic premise is you don't want a malicious website to make use of a valid session you have on another website. You prevent this by using a CSRF token. The malicious website doesn't have access to this token so they won't be able to make any POST requests on your behalf.

Spring Security CSRF

When using Spring Security, CSRF protection is enabled by default. The token is automatically configured when using supported HTML templating engines like Thymeleaf, but you can easily set it up on your own by following the documentation.

Kyle Anderson
  • 6,801
  • 1
  • 29
  • 41
  • Hi I edited my question a bit to make it more specific. I understand how the protection works, but from my understanding it seems like the URLs have to have the time dependent token attached to them. For example the SO link I provided in the question attaches the time dependent token to the end of the URL. – Ole Nov 22 '16 at 20:44
  • The default CSRF configuration provided by Spring Security (remember you can always customize the configuration) stores the CSRF token within the Users session. So the tokens validity is bound the validity of the session. Also, the example above uses GET requests for operations that change application state. You should reserve GET requests for read-only operations and use POST (or PUT, PATCH, DELETE, etc.) to make changes. Does that answer your question? – Kyle Anderson Nov 22 '16 at 21:13
  • What if I have a controller that responds to post request for the http://example.com/vote/30 URL - won't that still go through? – Ole Nov 22 '16 at 23:13
  • @Ole Not without the Session Cookie and CSRF Token. That is the default setup for Spring Security. That's how it protects you. It takes your Session Cookie, looks it up on the backend, finds the related CSRF Token on the backend and compares it to the CSRF Token sent with the request. It only goes through if it matches. Take a look at the docs, as they go into more detail. Anything else? – Kyle Anderson Nov 22 '16 at 23:47