Tried to implement CSRF protection on the latest Spring Boot.
All the examples on internet are based on user login and authentication, which I do not need.
My site does not have any sections requiring authentication.
I would like
1) Rest requests come from within site. No direct request from outside with wget to be allowed.
2) All pages (routes) must be requested from the index page (/)
Included the security dependency in pom.xml
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
-- Defined users in application.properties (even though, I do not need)
-- App creates _csrf.token .
-- Created class extending WebSecurityConfigurerAdapter with "configure" method overriding.
Tried all suggested filters in "configure". It did not work and finally left it blank.
The problem is that Wget can get api pages directly.
How to prevent it?
I've quickly put together a POC of this configuration:
#Configuration
#EnableWebSecurity
#SpringBootApplication
public class StackoverflowQ40929943Application extends WebSecurityConfigurerAdapter{
public static void main(String[] args) {
SpringApplication.run(StackoverflowQ40929943Application.class, args);
}
#Override
protected void configure(HttpSecurity http) throws Exception {
http.authorizeRequests().antMatchers("/**").permitAll();
}
}
The gist of it is Spring Boot + Security will secure all endpoints automatically. Here we explicitly allow requests to all endpoints. But, Spring Boot + Security automatically configures CSRF out of the box which we've left enabled. Thus you get the best of both worlds.
NOTE: You'll probably need to refine this configuration further to meet your needs.
Full Example on GitHub
Related
I'm working on a Java application where a user registers a password for his/her account. The following are being used:
Spring Boot
Spring MVC
Spring Web Flow
Spring Security
Thymeleaf
Interceptor (for checking the session in the preHandle method)
For the Spring Security part, there's really no authentication required. I just use it to handle CSRF and the configuration is as follows:
#Configuration
#EnableWebSecurity
#EnableGlobalMethodSecurity(securedEnabled = true, prePostEnabled = true)
public class SecurityConfig extends WebSecurityConfigurerAdapter {
#Override
protected void configure(HttpSecurity http) throws Exception {
// CSRF feature only
http.authorizeRequests().anyRequest().permitAll();
}
}
Now, this is where things get messy. When I deploy it to Tomcat in a Unix environment, ;jsessionid gets appended to the URL and Spring Security is not happy. I have scrounged the Internet and found the following solutions to remove it (alongside my results).
server.servlet.session.tracking-modes=cookie in application.properties does nothing.
web.xml
<session-config>
<tracking-mode>COOKIE</tracking-mode>
</session-config>
or
#Configuration
public class WebConfig implements WebApplicationInitializer {
#Override
public void onStartup(ServletContext servletContext) {
HashSet<SessionTrackingMode> set = new HashSet<>();
set.add(SessionTrackingMode.COOKIE);
servletContext.setSessionTrackingModes(set);
}
}
yields an IllegalArgumentException: The session tracking mode [COOKIE] requested for context [/<context-name>] is not supported by that context
I'm about to pull what remains of my hair off so I reverted any cookie-related changes and thought of just allowing semicolons in the URL (I know, I know, not secure) using the snippet below in the same SecurityConfig class.
#Bean
public HttpFirewall allowUrlSemicolonHttpFirewall() {
StrictHttpFirewall firewall = new StrictHttpFirewall();
firewall.setAllowSemicolon(true);
return firewall;
}
#Override
public void configure(WebSecurity web) throws Exception {
super.configure(web);
web.httpFirewall(allowUrlSemicolonHttpFirewall());
}
And voila! The web flow runs on an infinite redirect.
Questions:
Has anyone ever encountered IllegalArgumentException: The session tracking mode [COOKIE] requested for context [/<context-name>] is not supported by that context before? I've searched far and wide and the closest that I could find is this.
Could the reason behind server.servlet.session.tracking-modes=cookie not working be the same as above?
Could the infinite redirect be caused by http.authorizeRequests().anyRequest().permitAll()? I tried using anonymous() but the result was the same.
Is it possible to know which part exactly is causing the infinite redirect?
Please note that allowing semicolons in the URL is working fine and dandy in my localhost, so I have a hunch that what's causing the redirects is SSL-related. In the same way that locally ;jsessionid is not being appended to the URL.
My next step is to try configuring SSL locally in an attempt to replicate the issue. In the meantime, any help would be highly appreciated. My apologies if there's too much information here; I'm willing to repost it as multiple questions if that's necessary.
Spring Boot 2.6.3 with Springdoc.
<dependency>
<groupId>org.springdoc</groupId>
<artifactId>springdoc-openapi-ui</artifactId>
<version>1.6.5</version>
</dependency>
In applicaton.yaml, when I set the path as /v3/api-docs or remove it, that means use the default path "/v3/api-docs".
The Swagger UI page shows up correctly with the APIs
http://localhost:8080/swagger-ui/index.html
But I want to overite the path as below
api-docs.path: /bus/v3/api-docs
then Swagger UI displays the "Failed to load remote configuration" error:
Make sure to add "/v3/api-docs/**" in configure method.
#Configuration
public class WebSecurityConfiguration extends WebSecurityConfigurerAdapter {
#Override
public void configure(WebSecurity web) throws Exception {
web.ignoring().antMatchers("/swagger-ui/**", "
/v3/api-docs/**");
}
}
If you are using Spring Security in your app, you must include the URL in the configs.
Add the code below please to your project.
#Configuration
public class WebSecurityConfiguration extends WebSecurityConfigurerAdapter {
#Override
public void configure(WebSecurity web) throws Exception {
web.ignoring().antMatchers("/swagger-ui/**", "/bus/v3/api-docs/**");
}
}
I had the same problem, If you are behind a reverse proxy, the fix was to add the following property in application.yml
server:
forward-headers-strategy: framework
this is needed due to the following
Swagger relies on internal routing to make requests from the clients perspective. Putting the service behind a reverse-proxy without providing the X-Forwarded headers will result in the user not being able to use the documentation as intended
source -> https://medium.com/swlh/swagger-spring-boot-2-with-a-reverse-proxy-in-docker-8a8795aa3da4
Perform "Empty cache and hard refresh" in your browser.
I think I have solved the problem (thanks to #Ivan Zaitsev), just wanted to add more clarification to the answer.
I too have changed the api-docs.path property and I had the same problem. When I inspect the requests on swagger UI page, swagger-config request returns 404 since it was still trying to get the config from the old URL.
Even though I have changed api-docs.path property, here is the request URL that tries to retrieve swagger-config.
http://localhost:8080/api/v3/api-docs/swagger-config
It turned out to be a problem related to openapi-ui, because I was able to solve it when I cleared the browser cache and cookies. It is better do to the tests with incognito browser since it does not hold any data on the session.
If you are using SpringBoot v3, you must use springdoc-openapi v2:
https://springdoc.org/v2/
With gradle, for example:
implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.0.2'
I want to manage security policy like below. ( HTTP Basic Authorization)
Apply authentication following URLs.
"/foo/", "/bar/"
Ignore anything else URLs. ( Even though requests have Authorization field in header)
I know permitall(). But permitall() is not suitable because it apply security policy when request has Authorization field in headers.
If you want ignore particular url then you need to implement this method.
#Configuration
#EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
#Override
public void configure(final WebSecurity web) throws Exception {
web.ignoring()
.antMatchers("/static/**");
}
}
You can put your url in place of /static/** in which you want no authentication apply.
Your example means that Spring (Web) Security is ignoring URL patterns
that match the expression you have defined ("/static/**"). This URL is
skipped by Spring Security, therefore not secured.
Read the Spring Security reference for more details:
Click here for spring security details
EDIT:
After several days of trying various Security configuration changes, I punted and put .permitAll() on every endpoint which should authorize/authenticate any request. But even then, although I could freely "browse" any page without authenticating, my device clients were still unable to submit PUT requests to their normal application endpoint.
So now the question is, why can the remote clients successfully submit PUT requests to my app running on the 1.5.4 Spring Boot version but not when "the same app" is running at Spring Boot 2.0.2?
I get a successful "health check" response ("up and running as usual...") when I hit the same "device" endpoint with a GET request from my browser. But the client devices just get ERR_CONNECTION_REFUSED (or similar) when they try to PUT.
/EDIT
This question is related to one I asked about Web Socket migration a couple of days ago, but the web socket part turned out to be a red herring.
The real issue I'm facing is related to Spring Security in SB 2.0.2.
springBootVersion = '2.0.2.RELEASE'
springVersion = '5.0.13.RELEASE'
springSecurityVersion = '5.2.1.RELEASE'
Everything was working the way we needed at SB 1.5.4, but at 2.0.2 I can't seem to restore the necessary behavior. What I need is my custom Form Login applied to all endpoints except /input and /input/auth
This is the only configurer adapter we were using at 1.5.4 (with ACCESS OVERRIDE)
#Configuration
#EnableWebSecurity
//#Order(SecurityProperties.ACCESS_OVERRIDE_ORDER)
#Order(1)// highest priority
class WebSecurityConfig extends WebSecurityConfigurerAdapter {
#Autowired
SimpleAuthenticationManager sam;
#Override
protected void configure(HttpSecurity http) throws Exception {
// false means go to original destination page after login success
boolean alwaysRedirectToSuccessUrl = false;
http.headers().cacheControl().disable();
http.headers().frameOptions().sameOrigin();
http.csrf().ignoringAntMatchers("/input/auth/**");// ignoring WebSocket endpoints (secured by other means)
http.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.ALWAYS);
http.authorizeRequests()
.antMatchers('/widgetInfo/**', '/stats', '/errorCodes').hasAuthority('USER').anyRequest().fullyAuthenticated()
http.formLogin()
.loginPage('/widgetInfo/login')
.loginProcessingUrl("/widgetInfo/fooInfo")
.defaultSuccessUrl("/widgetInfo/fooInfo", alwaysRedirectToSuccessUrl)
.failureUrl("/widgetInfo/login?status=LOGIN_FAILURE").permitAll()
}
#Override
public void configure(WebSecurity web) throws Exception {
web.ignoring().antMatchers('/webjars/**', '/static/**', '/css/**', '/js/**', '/input/**');
}
#Autowired
public void configureGlobal(AuthenticationManagerBuilder auth) throws Exception {
auth.parentAuthenticationManager(sam)
}
}
The above configuration works in 2.0.2, except that it is not allowing free access to the /input endpoints. After chasing the red herring for a couple of days, and realizing my misunderstanding, I tried adding another much more lenient configurer adapter as more-or-less described at the bottom of this page
#Configuration
#EnableWebSecurity
#Order(11)// lowest priority
class LenientWebSecurityConfig extends WebSecurityConfigurerAdapter {
#Override
protected void configure(HttpSecurity http) throws Exception {
http.csrf().ignoringAntMatchers("/input/auth/**");// ignoring WebSocket endpoints (secured by other means)
http.authorizeRequests().antMatchers('/input', 'input/auth', '/input/**').permitAll()
}
}
But it's not working, the /input endpoint is not yet freely accessible. What is the issue?
If I swap the #Order, then nothing goes through my custom Form Login.
Answering here just to close loop for future users who might land here.
The problem turned out to be that Spring Boot 1.5.4 would accept "HTTP1.1" requests, but Spring Boot 2.0.2 will not.
Our app sits behind an F5 device that rejects inbound requests if/when the application "healthcheck" requests fail. This is the "healthcheck" request that was working at 1.5.4
GET /myGateway/input HTTP/1.1\r\n
But at 2.0.2, that request was failing. At 2.0.2 the healthcheck request needs to be
GET /myGateway/input \r\n
Therefore, "Spring Security" configuration issues were also a red herring.
EDIT: Apparently, this is/was a known issue with 2.0.x that was fixed in Spring Boot 2.2.x (summer 2019)
I don't know what I'm doing wrong, but when I try to secure some REST resources using a ResourceServerConfigurerAdapter it doesn't work. I can only accomplish my goal using #PreAuthorize or setting the security on the WebSecurityConfigurerAdapter.
Actually, the WebSecurityConfigurerAdapter is stealing all possibilities on HttpSecurity settings. I believe that it have something to do with filtering order. I searched for information on the documentation but found it quite vague. I know that on the Spring Boot version 1.5+ the filtering order of ResourceServerConfigurerAdapter has been changed, and I only managed to get it to work after setting a new order on the properties: security.oauth2.resource.filter-order=3
Being more specific, this code (on ResourceServerConfigurerAdapter) doesn't have any result:
#Override
public void configure(HttpSecurity http) throws Exception {
http.requestMatcher(new OAuthRequestedMatcher())
.anonymous().disable()
.authorizeRequests()
.antMatchers(HttpMethod.OPTIONS).permitAll()
.antMatchers("/api/hello").access("hasAnyRole('USER')")
.antMatchers("/api/me").hasAnyRole("USER", "ADMIN");
}
It is only possible to protect "/api/hello" and "/api/me" annotating #PreAuthorize on the controller methods:
#PreAuthorize("hasAnyRole('USER','ADMIN')")
#GetMapping("/api/hello")
public ResponseEntity<?> hello() {
String name = SecurityContextHolder.getContext().getAuthentication().getName();
String msg = String.format("Hello %s", name);
return new ResponseEntity<Object>(msg, HttpStatus.OK);
}
It is working, however, I fear that it could be done in a better way. Any ideas?
After some digging, I found the solution. The problem is indeed related to the filtering order. The guys at Pivotal changed the Oauth2 Resource Filter Order, as you can see in this passage taken from Spring Boot 1.5 release note:
OAuth 2 Resource Filter
The default order of the OAuth2 resource filter has changed from 3 to
SecurityProperties.ACCESS_OVERRIDE_ORDER - 1. This places it after the
actuator endpoints but before the basic authentication filter chain.
The default can be restored by setting
security.oauth2.resource.filter-order = 3
However, as pointed by #ilovkatie on this thread, the order of the WebSecurityConfigurerAdapter was also changed to 100, taken precedence over ResourceServerConfigurerAdapter.
So, instead of changing ResourceServerConfigurerAdapter's order on properties, a more elegant solution would be to use #Order(SecurityProperties.ACCESS_OVERRIDE_ORDER) on WebSecurityConfigurerAdapter.
This will make the resources configuration take precedence over WebSecurityConfigurerAdapter and it will be possible to set security using HttpSecurity on the ResourceServerConfigurerAdapter, making unnecessary to use #PreAuthorize annotation.