3

I am using Spring Boot, Spring Security and jdk 1.8. When I am trying to open any secured Thymleaf page in iframe on Chrome, then it is redirecting me to login page every time. It is working fine on Firefox and IE.

And when I try to open the same URL without iframe, it is working fine. Below are my Spring Security conf file code. One more thing: both domains are different.

@Override
    protected void configure(HttpSecurity http) throws Exception {
        http
                .headers()
                .frameOptions().disable()
                .and()
                .csrf().disable()/*disbaling csrf here*/
                .authorizeRequests()
                .antMatchers("/","/login","/css/**", "/js/**", "/fonts/**","/img/**").permitAll()/*do not use spring security on this path*/
                .and()
                .formLogin()
                .successHandler(successHandler) /*after success login on web we are handling the success event*/
                .permitAll()
                .and()
                .logout().logoutRequestMatcher(new AntPathRequestMatcher("/logout")).logoutSuccessUrl("/login/?logout") /*defining logout and login url here*/
                .permitAll()
                 /*
                 * This is for authentication failure handling
                 * */
                 http.exceptionHandling().authenticationEntryPoint(authenticationEntryPoint)
                 /*Token based authentication we are handling here*/
                 http.addFilterBefore(new StatelessAuthenticationFilter(tokenAuthenticationService), BasicAuthenticationFilter.class);
                 http.addFilterAfter(new SameSiteFilter(), BasicAuthenticationFilter.class)
    }

How can I fix it?

halfer
  • 19,824
  • 17
  • 99
  • 186
Deepak Gupta
  • 45
  • 1
  • 7

1 Answers1

4

To start off, I would advise you against disabling the "X-Frame-Options" header and using your appication in an iframe.
This poses a security risk, which you can read more about in this answer.

Now to explain the behaviour you are seeing.
Spring Security uses a Session cookie to store the user's session.
Cookies are associated with domains, so if, for example, there is a cookie associated with the domain stackoverflow.com then that cookie will be included in any request to stackoverlow.com.

In order to control that behaviour, cookies also have an attribute called SameSite.
The SameSite attribute can have 3 values, None, Lax, Strict or it can be unset and have no value.
When the value is None, it behaves as described above (included in all requests).
When the value is Lax, then the cookie will only be included in top level navigation GET requests.

The Session cookie that Spring Security uses does not set the SameSite attribute.
At this time (March 2020), some browsers, like Firefox and Edge, treat the unset attribute the same as None.
However, Chrome is experimenting with treating the unset attribute the same as Lax.
You can read more about that in the Chrome Platform Status.

In summary, when using Chrome, the Session cookie is treated as if it had SameSite set to Lax.
Since rendering an application in an iframe is not a top level navigation, the Session cookie is not included in the request from the iframe, and the application has no way of knowing that a user is signed in.

You can explicitly set the SameSite attribute to None by using Spring Session.
Again, I would caution against this, since it can make your application vulnerable to CSRF and clickjacking attacks.
If, after consider the security implications, you deem it necessary to set the SameSite attribute to None, you can do so by including Spring Session in your dependencies and creating a custom CookieSerializer.