All Vulnerability Reports

CVE-2016-5007 Spring Security / MVC Path Matching Inconsistency


Severity

Medium

Vendor

Spring by Pivotal

Versions Affected
  • Spring Security 3.2.x, 4.0.x, 4.1.0
  • Spring Framework 3.2.x, 4.0.x, 4.1.x, 4.2.x
  • Other unsupported versions are also affected
Description

Both Spring Security and the Spring Framework rely on URL pattern mappings for authorization and for mapping requests to controllers respectively.

Differences in the strictness of the pattern matching mechanisms, for example with regards to space trimming in path segments, can lead Spring Security to not recognize certain paths as not protected that are in fact mapped to Spring MVC controllers that should be protected.

The problem is compounded by the fact that the Spring Framework provides richer features with regards to pattern matching as well as by the fact that pattern matching in each Spring Security and the Spring Framework can easily be customized creating additional differences.

Mitigation

Users of affected versions should apply the following mitigation:

  • To address these issues comprehensively Spring Security provides URL authorization that can delegate pattern matching to the Spring Framework. To take advantage of this option applications should upgrade to Spring Security 4.1.1+ and Spring Framework 4.3.1+ and use the MvcRequestMatcher.
  • Starting with Spring Framework 4.3.0+ the AntPathMatcher is configured with trimTokens set to “false” which aligns with Spring Security. Therefore simply using Spring Framework 4.3.0+ can eliminate some causes of path matching inconsistencies.
  • Users of Spring Framework 3.2.x, 4.0.x, 4.1.x, 4.2.x can use the MVC Java config or the MVC namespace to set trimTokens property of AntPathMatcher to “false”.
  • In addition, applications should always complement URL-based authorization with additional authorization at the business layer of the application using one of Spring Security’s mechanisms such as adding @Secured annotations.
Credit

The vulnerability was reported responsibly by Clément Notin from INTRINSEC.

References
History

2016-July-07: Initial vulnerability report published