org.sonar.l10n.java.rules.java.S4601.html Maven / Gradle / Ivy
Spring Framework, and, more precisely, the Spring Security component, allows setting up access control checks at the URI level. This is done by
adding request matchers to the security configuration, each authorizing access to some resources depending on the incoming request entitlement.
Similarly to firewall filtering rules, the order in which those matchers are defined is security relevant.
Why is this an issue?
Configured URL matchers are considered in the order they are declared. Especially, for a given resource, if a looser filter is defined before a
stricter one, only the less secure configuration will apply. No request will ever reach the stricter rule.
This rule raises an issue when:
- A URL pattern ending with
** precedes another one having the same prefix. E.g. /admin/** is defined before
/admin/example/**
- A pattern without wildcard characters is preceded by another one that matches it. E.g.:
/page-index/db is defined after
/page*/**
What is the potential impact?
Access control rules that have been defined but cannot be applied generally indicate an error in the filtering process. In most cases, this will
have consequences on the application’s authorization and authentication mechanisms.
Authentication bypass
When the ignored access control rule is supposed to enforce the authentication on a resource, the consequence is a bypass of the authentication for
that resource. Depending on the scope of the ignored rule, a single feature or whole sections of the application can be left unprotected.
Attackers could take advantage of such an issue to access the affected features without prior authentication, which may impact the confidentiality
or integrity of sensitive, business, or personal data.
Privilege escalation
When the ignored access control rule is supposed to verify the role of an authenticated user, the consequence is a privilege escalation or
authorization bypass. An authenticated user with low privileges on the application will be able to access more critical features or sections of the
application.
This could have financial consequences if the accessed features are normally accessed by paying users. It could also impact the confidentiality or
integrity of sensitive, business, or personal data, depending on the features.
How to fix it in Spring
Code examples
The following code is vulnerable because it defines access control configuration in the wrong order.
Noncompliant code example
protected void configure(HttpSecurity http) throws Exception {
http.authorizeRequests()
.antMatchers("/resources/**", "/signup", "/about").permitAll()
.antMatchers("/admin/**").hasRole("ADMIN")
.antMatchers("/admin/login").permitAll() // Noncompliant
.antMatchers("/**", "/home").permitAll()
.antMatchers("/db/**").access("hasRole('ADMIN') and hasRole('DBA')") // Noncompliant
.and().formLogin().loginPage("/login").permitAll().and().logout().permitAll();
}
Compliant solution
protected void configure(HttpSecurity http) throws Exception {
http.authorizeRequests()
.antMatchers("/resources/**", "/signup", "/about").permitAll()
.antMatchers("/admin/login").permitAll()
.antMatchers("/admin/**").hasRole("ADMIN")
.antMatchers("/db/**").access("hasRole('ADMIN') and hasRole('DBA')")
.antMatchers("/**", "/home").permitAll()
.and().formLogin().loginPage("/login").permitAll().and().logout().permitAll();
}
Resources
Documentation
- Spring Documentation - Authorize
HttpServletRequests
Standards