SAML Attacks

Secure Assertion Markup Language (SAML) is an XML-based standard that enables authentication and authorization between parties and can be used to implement SSO. In SAML, data is exchanged in digitally signed XML documents to ensure data integrity.

SAML Basic Overview

SAML Components

SAML consists of three core components:

Identity Provider (IdP): the system responsible for authenticating users. After authentication, it issues SAML assertions containing identity and authorization information.
Service Provider (SP): the application or service the user wants to access. It validates the user's identity by relying on the SAML assertions issued by the IdP.
SAML Assertions: XML-based documents containing the user’s authentication and authorization details. Assertions are digitally signed to ensure integrity and trust.

Authentication Flow

SAML follows a pre-defined flow, which can be described from a high-level as:

A user accesses the Service Provider (SP).
The SP sends a SAML authentication request to the IdP (via browser redirection).
The user authenticates with the IdP.
After authentication, the IdP creates a digitally signed SAML assertion and sends it back to the user’s browser.
The browser forwards the assertion to the SP.
The SP verifies the SAML assertion.
Once verified, the user accesses the requested resource.
The SP provides the resource.

Useful Resources:

Decode and inflate SAML data: https://www.samltool.com/decode.php
https://medium.com/stolabs/how-saml-works-and-some-attacks-on-it-2f62db0ef1d9
Burp Pro SAML Raider Extension

If you own BurpSuite Professional, the SAML Raider extension can greatly simplify the attacks covered here by handling decoding, editing, and resigning of SAML responses.

Identifying SAML authentication

When you authenticate to a web application using SAML, you will be redirected to the identity provider with a request containing the SAMLRequest parameter, an eample redirect location is /saml/idp/SSOService.php?SAMLRequest=<value>

The value of the SAML request can be URL-decoded and then given to SAMLTool to Base64-decode and inflate the XML data, to show the complete XML SAMLRequest data

Note: when you successfully authenticate with SAML, the SAMLResponse does not need to be inflated, but just URL and base64 decoded.

Signature Exclusion Attack

Signature Exclusion is an attack that manipulates the SAMLResponse data by removing its signature.

This only works when a service provider is misconfigured to only verify the signature if one is present and defaults to accepting the SAMLResponse otherwise. This means that an attacker may remove the signature to manipulate the SAMLResponse without invalidating it, and, for example, impersonating other users.

The steps to reproduce this attack are the following:

Login via SAML with a valid user, URL-decode and Base64-decode the SAMLResponse to check its data.
To impersonate a different user, edit the values in the saml:Assertion used by the web application for authentication, for example, you can change your username to another user's by editing: <saml:AttributeValue xsi:type="xs:string">admin</saml:AttributeValue>
Remove all signatures from the SAML response, which are the ds:Signature XML elements
Base64-encode and URL-encode the entire SAMLResponse you just edited
Login to the application again, intercept your request containing the SAMLResponse parameter and change the data with what you previously produced.

Signature Wrapping Attack

Signature Wrapping is a class of attacks against SAML implementations that aims to create a discrepancy between the signature verification logic and the logic used to extract authentication information from the SAML assertion.

This discrepancy is achieved by injecting XML elements into the SAML response that, while not invalidating the signature, potentially confuse the application, causing it to use the injected and unsigned authentication information instead of the signed one.

To do that:

Login via SAML with a valid user, URL-decode and Base64-decode the SAMLResponse to check its data.
From the obtained XML, copy the saml:Assertion node and remove its ds:Signature nodes
Change the new saml:Assertion identifier by using any value, such as ID=_any
Edit the copied assertion by changing the data attributes you are interested in changing. For example, you can change your username to admin.
Inject the copied assertion into the SAML before the signed, original and unchanged assertion
Finally, Base64-encode and URL-encode the resulting SAML response before sending it to the service provider in the following request

Other XML-based Attacks

Since SAML uses an XML data format for data representation, flawed SAML implementations may be vulnerable to attacks on XML-based data

XXE Injection

If a SAML service provider relies on a misconfigured XML parser that loads external entities, it may be vulnerable to XXE injection. To inject a XXE payload, you need to first obtain the XML representation of the SAML response as previously shown, then inject the payload at the beginning of the SAML response, resulting in the following structure:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://127.0.0.1:80"> %xxe; ]>
<samlp:Response>
    [...]
</samlp:Response>

Then, as usual, Base64-encode and URL-encode the XML data to send it via the SAMLResponse parameter

XSLT Server-side Injection

A misconfigured XML parser might be vulnerable to XSLT server-side injection.

To inject a payload, use an XSLT payload, like the following example

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<xsl:copy-of select="document('http://127.0.0.1/')"/>
</xsl:template>
</xsl:stylesheet>

Then, as usual, Base64-encode and URL-encode the XML data to send it via the SAMLResponse parameter