1

I'm really confused about a CSRF token implementation in a Spring web app that I've inherited. Basically, everyone can request the token by looking at what Spring Security filters do:

        http
        .exceptionHandling()
        .authenticationEntryPoint(new RestAuthenticationEntryPoint())
        .and()

        .authorizeRequests()

        .antMatchers(HttpMethod.GET,"/token").permitAll()

Initially I tought that the protection comes from the SOP, but the creator of the implementation told me that is not SOP that grant protection without specifying further. So, in a few words, is it correct to prevent CSRF in this way? Because I feel that something is missing, but I can't realize what.

0

This is a quite normal way of protection against CSRF.

What is CSRF? It is when an attacker tricks your user to click a link/button and trigger a function in your application that user otherwise would not like to trigger. For instance, an attacker tricks a user to place an order in your application with the attackers delivery address.

It is considered a good practice that any operations that change any data are only triggered via POST, PUT, PATCH, DELETE and that GET does not change anything. Then what will happen if an attacker tricks a user to trigger some GET operation? User will receive the data from your application that he can anyway see. There is nothing harmful in this. That's why there is usually no sense in protecting GET requests against CSRF.

Update:

After comments from the author below it seems that it is a single page application, because if HTML was rendered on server, server could inject the token and it would be not needed to request the token separately.

The case with SPA is addressed already, for instance, see here:

It is not wrong to get token in such way. But permitAll() should no be used, otherwise an attacker can create a request with a correct token.

2
  • I explained myself wrong, sorry. The GET for /token isn't a resource that I want to protect, is used to retrive a X-Csrf-Token that will be attached as header to protect future POST requests against CSRF. What I miss is, if the access to this token is allowed to anyone, what blocks an attacker to ask for and attach this token in his malicious POST request? – phantasos Sep 8 '19 at 19:29
  • So what I wanted to say was that it is not even required for a user that visits a malicious website to click anything. Just by visiting a website could trigger and HTTP PORT request to the target application and perform the CSRF attack. – Jeroen Sep 8 '19 at 19:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.