Home » Cybersecurity » Threats & Breaches » Vulnerabilities » From Feature to Vulnerability: a spring-security-oauth2-client Story
From Feature to Vulnerability: a spring-security-oauth2-client Story
Spring Security provides security services for the Spring IO Platform, available on their Github repository. Today we focus on the “oauth2” client, which provides an application with the capability to have users log in using their existing account at an OAuth 2.0 Provider, i.e Github and Google, among others.
But what happens when we allow a single greedy user to tie up all of our resources with all of their requests? The short answer is CVE-2021-22119:
Name/Vulnerability Identifier: CVE-2021-22119
Type of Vulnerability: Uncontrolled Resource Consumption
Severity:
CVSS 3.1 Score: 7.5 / High
CVSS 3.1 Metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Components Affected:
Maven:
Org.springframework.security:spring-security-oauth2-client
Org.apache.servicemix.bundles:org.apache.servicemix.bundles.spring-security-oauth2-client
Versions:
[5.1.0.RELEASE, 5.2.11.RELEASE)
[5.3.0.RELEASE, 5.3.10.RELEASE)
[5.4.0, 5.4.7)
[5.5.0, 5.5.1)
The Long Answer
The greedy user we mentioned? They can repeatedly send authorization requests to the application, one after another, or even write a simple script to quickly and easily fire off thousands. The application will attempt to blindly store all of them, disregarding details such as origin, state of current session, or rate.
The trick to exploiting this issue is exiting the authorization flow before it finishes, and thus leaving the request abandoned in the `AuthorizationRequestRepository.` The request will stay there until it expires but, at the moment, expiration is not enforced by the component. This leads to all abandoned requests being stored indefinitely. And eventually you’ll see system resources exhausted, ultimately resulting in a Denial of Service (DoS) condition.
The Fix
Resolving this vulnerability is relatively straightforward. The developers essentially reverted the vulnerable functionality, currently allowing only one authorization request per session by default. Still, the option remains to enable functionality, assuming (Read more...)
*** This is a Security Bloggers Network syndicated blog from Sonatype Blog authored by Juan Aguirre. Read the original post at: https://blog.sonatype.com/from-feature-to-vulnerability-a-spring-security-oauth2-client-story