hacktricks/pentesting-web/saml-attacks/saml-basics.md

{% hint style="success" %}
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Support HackTricks</summary>

* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>
{% endhint %}


# SAML Overview

**Security Assertion Markup Language (SAML)** umożliwia wykorzystanie dostawców tożsamości (IdP) do przesyłania poświadczeń autoryzacyjnych do dostawców usług (SP), co ułatwia jednolity dostęp (SSO). To podejście upraszcza zarządzanie wieloma logowaniami, pozwalając na użycie jednego zestawu poświadczeń na wielu stronach internetowych. Wykorzystuje XML do standaryzowanej komunikacji między IdP a SP, łącząc uwierzytelnienie tożsamości użytkownika z autoryzacją usługi.

## Comparison between SAML and OAuth

- **SAML** jest dostosowany do zapewnienia przedsiębiorstwom większej kontroli nad bezpieczeństwem logowania SSO.
- **OAuth** jest zaprojektowany z myślą o większej przyjazności dla urządzeń mobilnych, używa JSON i jest wspólnym wysiłkiem firm takich jak Google i Twitter.

# SAML Authentication Flow

**For further details check the full post from [https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/)**. This is a summary:

Proces uwierzytelniania SAML obejmuje kilka kroków, jak pokazano w schemacie:

![https://epi052.gitlab.io/notes-to-self/img/saml/saml-flow.jpg](https://epi052.gitlab.io/notes-to-self/img/saml/saml-flow.jpg)

1. **Próba dostępu do zasobu**: Użytkownik próbuje uzyskać dostęp do chronionego zasobu.
2. **Generowanie żądania SAML**: SP nie rozpoznaje użytkownika i generuje żądanie SAML.
3. **Przekierowanie do IdP**: Użytkownik jest przekierowywany do IdP, a żądanie SAML przechodzi przez przeglądarkę użytkownika.
4. **IdP odbiera żądanie**: IdP odbiera żądanie SAML.
5. **Uwierzytelnienie w IdP**: IdP uwierzytelnia użytkownika.
6. **Walidacja użytkownika**: IdP weryfikuje legalność użytkownika do uzyskania dostępu do żądanego zasobu.
7. **Tworzenie odpowiedzi SAML**: IdP generuje odpowiedź SAML zawierającą niezbędne asercje.
8. **Przekierowanie do URL ACS SP**: Użytkownik jest przekierowywany do URL usługi konsumpcji asercji (ACS) SP.
9. **Walidacja odpowiedzi SAML**: ACS weryfikuje odpowiedź SAML.
10. **Dostęp do zasobu przyznany**: Przyznano dostęp do początkowo żądanego zasobu.

# SAML Request Example

Rozważmy scenariusz, w którym użytkownik żąda dostępu do zabezpieczonego zasobu na [https://shibdemo-sp1.test.edu/secure/](https://shibdemo-sp1.test.edu/secure/). SP identyfikuje brak uwierzytelnienia i generuje żądanie SAML:
```
GET /secure/ HTTP/1.1
Host: shibdemo-sp1.test.edu
...
```
Surowe żądanie SAML wygląda tak:
```xml
<?xml version="1.0"?>
<samlp:AuthnRequest ...
</samlp:AuthnRequest>
```
Key elements of this request include:
- **AssertionConsumerServiceURL**: Określa, gdzie IdP powinien wysłać SAML Response po uwierzytelnieniu.
- **Destination**: Adres IdP, do którego wysyłane jest żądanie.
- **ProtocolBinding**: Definiuje metodę przesyłania wiadomości protokołu SAML.
- **saml:Issuer**: Identyfikuje podmiot, który zainicjował żądanie.

Following the SAML Request generation, the SP responds with a **302 redirect**, directing the browser to the IdP with the SAML Request encoded in the HTTP response's **Location** header. The **RelayState** parameter maintains the state information throughout the transaction, ensuring the SP recognizes the initial resource request upon receiving the SAML Response. The **SAMLRequest** parameter is a compressed and encoded version of the raw XML snippet, utilizing Deflate compression and base64 encoding.


# SAML Response Example

You can find a [full SAML response here](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/). The key components of the response include:

- **ds:Signature**: Ta sekcja, będąca podpisem XML, zapewnia integralność i autentyczność wystawcy asercji. Odpowiedź SAML w przykładzie zawiera dwa elementy `ds:Signature`, jeden dla wiadomości, a drugi dla asercji.
- **saml:Assertion**: Ta część zawiera informacje o tożsamości użytkownika i ewentualnie inne atrybuty.
- **saml:Subject**: Określa główny podmiot wszystkich stwierdzeń w asercji.
- **saml:StatusCode**: Reprezentuje status operacji w odpowiedzi na odpowiadające żądanie.
- **saml:Conditions**: Szczegóły dotyczące warunków, takich jak czas ważności Asercji i określony Dostawca Usług.
- **saml:AuthnStatement**: Potwierdza, że IdP uwierzytelnił podmiot Asercji.
- **saml:AttributeStatement**: Zawiera atrybuty opisujące podmiot Asercji.

Following the SAML Response, the process includes a 302 redirect from the IdP. This leads to a POST request to the Service Provider's Assertion Consumer Service (ACS) URL. The POST request includes `RelayState` and `SAMLResponse` parameters. The ACS is responsible for processing and validating the SAML Response.

After the POST request is received and the SAML Response is validated, access is granted to the protected resource initially requested by the user. This is illustrated with a `GET` request to the `/secure/` endpoint and a `200 OK` response, indicating successful access to the resource.


# XML Signatures

XML Signatures are versatile, capable of signing an entire XML tree or specific elements within it. They can be applied to any XML Object, not just Response elements. Below are the key types of XML Signatures:

### Basic Structure of XML Signature
An XML Signature consists of essential elements as shown:
```xml
<Signature>
<SignedInfo>
<CanonicalizationMethod />
<SignatureMethod />
<Reference>
<Transforms />
<DigestMethod />
<DigestValue />
</Reference>
...
</SignedInfo>
<SignatureValue />
<KeyInfo />
<Object />
</Signature>
```
Każdy element `Reference` oznacza konkretny zasób, który jest podpisywany, identyfikowalny za pomocą atrybutu URI.

### Typy podpisów XML

1. **Podpis osadzony**: Ten typ podpisu jest potomkiem zasobu, który podpisuje, co oznacza, że podpis jest zawarty w tej samej strukturze XML co podpisana treść.

Przykład:
```xml
<samlp:Response ... ID="..." ... >
...
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>
...
</samlp:Response>
```

W podpisie osadzonym element `ds:Transform` określa, że jest on osadzony za pomocą algorytmu `enveloped-signature`.

2. **Podpis otaczający**: W przeciwieństwie do podpisów osadzonych, podpisy otaczające owijają zasób, który jest podpisywany.

Przykład:
```xml
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
<samlp:Response ... ID="..." ... >
...
</samlp:Response>
</ds:Signature>
```

3. **Podpis oddzielony**: Ten typ jest oddzielony od treści, którą podpisuje. Podpis i treść istnieją niezależnie, ale utrzymywany jest między nimi link.

Przykład:
```xml
<samlp:Response ... ID="..." ... >
...
</samlp:Response>
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>
```

Podsumowując, podpisy XML oferują elastyczne sposoby zabezpieczania dokumentów XML, z każdym typem spełniającym różne potrzeby strukturalne i bezpieczeństwa.


## Odniesienia
* [https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/)

{% hint style="success" %}
Ucz się i ćwicz Hacking AWS:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Ucz się i ćwicz Hacking GCP: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Wsparcie dla HackTricks</summary>

* Sprawdź [**plany subskrypcyjne**](https://github.com/sponsors/carlospolop)!
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Dziel się trikami hackingowymi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repozytoriów github.

</details>
{% endhint %}