# 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.

<details>

<summary>SAML Basic Overview</summary>

### SAML Components

SAML consists of three core components:

1. **Identity Provider (IdP):** the system responsible for authenticating users. After authentication, it issues **SAML assertions** containing identity and authorization information.
2. **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.
3. **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:

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

<figure><img src="/files/avMWb4fEPQcpbvEmZ88a" alt="" width="563"><figcaption><p>Source: <a href="https://www.researchgate.net/figure/SAML-20-Sequence-Diagram-12_fig1_282775938">https://www.researchgate.net/figure/SAML-20-Sequence-Diagram-12_fig1_282775938</a></p></figcaption></figure>

</details>

## 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](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e)

{% hint style="success" %}
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.
{% endhint %}

***

## 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](https://www.samltool.com/decode.php) to ***Base64-decode and inflate*** the XML data, to show the complete XML `SAMLRequest` data

{% hint style="success" %}
Note: when you successfully authenticate with SAML, the `SAMLResponse` **does not need to be inflated, but just URL and base64 decoded.**
{% endhint %}

***

## Signature Exclusion Attack <a href="#signature-exclusion-attack" id="signature-exclusion-attack"></a>

Signature Exclusion is an attack that manipulates the `SAMLResponse` data by removing its signature.&#x20;

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:

1. Login via SAML with a valid user, **URL-decode and Base64-decode** the `SAMLResponse` to check its data.
2. 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>`
3. Remove all signatures from the SAML response, which are the `ds:Signature` XML elements
4. **Base64-encode and URL-encode** the entire `SAMLResponse` you just edited
5. Login to the application again, intercept your request containing the `SAMLResponse` parameter and change the data with what you previously produced.

***

## Signature Wrapping Attack <a href="#signature-wrapping-attack" id="signature-wrapping-attack"></a>

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.&#x20;

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:

1. Login via SAML with a valid user, **URL-decode and Base64-decode** the `SAMLResponse` to check its data.
2. From the obtained XML, copy the `saml:Assertion` node and remove its `ds:Signature` nodes
3. Change the new `saml:Assertion` identifier by using any value, such as `ID=_any`
4. Edit the copied assertion by changing the data attributes you are interested in changing. For example, you can change your username to admin.
5. Inject the copied assertion into the SAML before the signed, original and unchanged assertion
6. 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 <a href="#xxe-injection" id="xxe-injection"></a>

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
<?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
<?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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://notes.sfoffo.com/web-applications/web-attacks/saml-attacks.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.