org.sonar.l10n.java.rules.java.S5679.html Maven / Gradle / Ivy
The Security Assertion Markup Language (SAML) is a widely used standard in single sign-on systems. In a simplified version, the user authenticates
to an Identity Provider which generates a signed SAML Response. This response is then forwarded to a Service Provider for validation and
authentication.
Why is this an issue?
If the Service Provider does not manage to properly validate the incoming SAML response message signatures, attackers might be able to manipulate
the response content without the application noticing. Especially, they might be able to alter the authentication-targeted user.
What is the potential impact?
By exploiting this vulnerability, an attacker can manipulate the SAML Response to impersonate a different user. This, in turn, can have various
consequences on the application’s security.
Unauthorized Access
Exploiting this vulnerability allows an attacker with authenticated access to impersonate other users within the SAML-based SSO system. This can
lead to unauthorized access to sensitive information, resources, or functionalities the attacker should not have. By masquerading as legitimate users,
the attacker can bypass authentication mechanisms and gain unauthorized privileges, potentially compromising the entire system. By impersonating a
user with higher privileges, the attacker can gain access to additional resources. Privilege escalation can lead to further compromise of other
systems and unauthorized access to critical infrastructure.
Data Breaches
With the ability to impersonate other users, an attacker can gain access to sensitive data stored within the SAML-based SSO system. This includes
personally identifiable information (PII), financial data, intellectual property, or any other confidential information. Data breaches can result in
reputational damage, legal consequences, financial losses, and harm to individuals whose data is exposed.
How to fix it in Spring
Code examples
The following code examples are vulnerable because they explicitly include comments in signature checks. An attacker is able to change the field
identifying the authenticated user with XML comments.
Noncompliant code example
import org.opensaml.xml.parse.StaticBasicParserPool;
import org.opensaml.xml.parse.ParserPool;
public ParserPool parserPool() {
StaticBasicParserPool staticBasicParserPool = new StaticBasicParserPool();
staticBasicParserPool.setIgnoreComments(false); // Noncompliant
return staticBasicParserPool;
}
import org.opensaml.xml.parse.BasicParserPool;
import org.opensaml.xml.parse.ParserPool;
public ParserPool parserPool() {
BasicParserPool basicParserPool = new BasicParserPool();
basicParserPool.setIgnoreComments(false); // Noncompliant
return basicParserPool;
}
Compliant solution
import org.opensaml.xml.parse.StaticBasicParserPool;
import org.opensaml.xml.parse.ParserPool;
public ParserPool parserPool() {
return new StaticBasicParserPool();
}
import org.opensaml.xml.parse.BasicParserPool;
import org.opensaml.xml.parse.ParserPool;
public ParserPool parserPool() {
return new BasicParserPool();
}
Resources
Documentation
- OpenSAML API - Class
BasicParserPool
- OpenSAML API - Class
StaticBasicParserPool
- W3C Recommendation - Canonical XML Version 1.1
- W3C Recommendation - XML Signature Syntax and Processing Version 1.1
Articles & blog posts
- Cisco Duo - Duo Finds SAML Vulnerabilities
Affecting Multiple Implementations
- Spring blog - Spring Security SAML and this
week’s SAML Vulnerability
- Spring Security SAML - Issue #228 Multiple SAML libraries may
allow authentication bypass via incorrect XML canonicalization and DOM traversal
- CVE - CVE-2017-11427
- CVE - CVE-2017-11428
- CVE - CVE-2017-11429
- CVE - CVE-2017-11430
- CVE - CVE-2018-0489
- CVE - CVE-2018-7340
Standards