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

<details>

<summary><strong>Dowiedz się, jak hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Inne sposoby wsparcia HackTricks:

* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLAN SUBSKRYPCJI**](https://github.com/sponsors/carlospolop)!
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Podziel się swoimi trikami hakerskimi, 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>


# Przegląd SAML

**Security Assertion Markup Language (SAML)** umożliwia dostawcom tożsamości (IdP) wykorzystanie uwierzytelniania jednokrotnego logowania (SSO) do przesyłania poświadczeń autoryzacji dostawcom usług (SP). Ta metoda upraszcza zarządzanie wieloma logowaniami, umożliwiając użycie jednego zestawu poświadczeń na wielu stronach internetowych. Wykorzystuje XML do standaryzowanej komunikacji między IdP a SP, łącząc uwierzytelnianie tożsamości użytkownika z autoryzacją usługi.

## Porównanie między SAML a OAuth

- **SAML** jest dostosowany do zapewnienia przedsiębiorstwom większej kontroli nad bezpieczeństwem logowania SSO.
- **OAuth** jest zaprojektowany tak, aby był bardziej przyjazny dla urządzeń mobilnych, korzysta z JSON i jest wspólnym wysiłkiem firm takich jak Google i Twitter.

# Przebieg uwierzytelniania SAML

**Aby uzyskać więcej szczegółów, sprawdź pełny post na stronie [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/)**. Oto streszczenie:

Proces uwierzytelniania SAML obejmuje kilka kroków, jak pokazano na 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 zostaje przekierowany do IdP, a żądanie SAML przechodzi przez przeglądarkę użytkownika.
4. **Odbiór żądania przez IdP**: IdP odbiera żądanie SAML.
5. **Uwierzytelnianie w IdP**: IdP uwierzytelnia użytkownika.
6. **Walidacja użytkownika**: IdP sprawdza legalność użytkownika w celu uzyskania dostępu do żądanego zasobu.
7. **Generowanie odpowiedzi SAML**: IdP generuje odpowiedź SAML zawierającą niezbędne twierdzenia.
8. **Przekierowanie do URL ACS SP**: Użytkownik zostaje przekierowany do URL usługi odbiorcy twierdzeń (ACS) SP.
9. **Walidacja odpowiedzi SAML**: ACS sprawdza odpowiedź SAML.
10. **Przyznanie dostępu do zasobu**: Dostęp do początkowo żądanego zasobu jest udzielany.

# Przykład żądania SAML

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

Po wygenerowaniu żądania SAML, SP odpowiada za przekierowanie **302**, kierując przeglądarkę do IdP z zakodowanym żądaniem SAML w nagłówku HTTP odpowiedzi **Location**. Parametr **RelayState** utrzymuje informacje o stanie transakcji, zapewniając, że SP rozpoznaje początkowe żądanie zasobu po otrzymaniu SAML Response. Parametr **SAMLRequest** to skompresowana i zakodowana wersja surowego fragmentu XML, wykorzystująca kompresję Deflate i kodowanie base64.


# Przykład odpowiedzi SAML

Pełną odpowiedź SAML można znaleźć [tutaj](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/). Kluczowe składniki odpowiedzi obejmują:

- **ds:Signature**: Ta sekcja, podpis XML, zapewnia integralność i autentyczność nadawcy twierdzenia. Odpowiedź SAML w przykładzie zawiera dwa elementy `ds:Signature`, jeden dla wiadomości, a drugi dla twierdzenia.
- **saml:Assertion**: Ta część zawiera informacje na temat tożsamości użytkownika i ewentualnie innych atrybutów.
- **saml:Subject**: Określa podmiot główny wszystkich oświadczeń w twierdzeniu.
- **saml:StatusCode**: Reprezentuje status operacji w odpowiedzi na odpowiadające żądanie.
- **saml:Conditions**: Szczegóły warunków, takich jak ważność twierdzenia i określony dostawca usług.
- **saml:AuthnStatement**: Potwierdza, że IdP uwierzytelnił podmiot twierdzenia.
- **saml:AttributeStatement**: Zawiera atrybuty opisujące podmiot twierdzenia.

Po odpowiedzi SAML proces obejmuje przekierowanie 302 z IdP. Prowadzi to do żądania POST do usługi Assertion Consumer Service (ACS) URL dostawcy usług. Żądanie POST zawiera parametry `RelayState` i `SAMLResponse`. ACS jest odpowiedzialny za przetwarzanie i weryfikację odpowiedzi SAML.

Po otrzymaniu żądania POST i zweryfikowaniu odpowiedzi SAML, dostęp jest udzielany do chronionego zasobu, który początkowo został żądany przez użytkownika. Ilustruje to żądanie `GET` do punktu końcowego `/secure/` i odpowiedź `200 OK`, wskazującą udane uzyskanie dostępu do zasobu.


# Podpisy XML

Podpisy XML są wszechstronne i mogą podpisywać całe drzewo XML lub konkretne elementy w nim. Mogą być stosowane do dowolnego obiektu XML, nie tylko elementów Response. Poniżej przedstawiamy kluczowe typy podpisów XML:

### Podstawowa struktura podpisu XML
Podpis XML składa się z podstawowych elementów, jak pokazano:
```xml
<Signature>
<SignedInfo>
<CanonicalizationMethod />
<SignatureMethod />
<Reference>
<Transforms />
<DigestMethod />
<DigestValue />
</Reference>
...
</SignedInfo>
<SignatureValue />
<KeyInfo />
<Object />
</Signature>
```
Każdy element `Reference` oznacza określony zasób, który jest podpisany i identyfikowany przez atrybut URI.

### Rodzaje podpisów XML

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

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

W przypadku podpisu osadzonego, 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ą podpisywany zasób.

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

3. **Podpis odłączony**: Ten rodzaj podpisu jest oddzielony od podpisywanej zawartości. Podpis i zawartość istnieją niezależnie, ale utrzymywane jest połączenie między nimi.

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 zapewniają elastyczne sposoby zabezpieczania dokumentów XML, przy czym każdy rodzaj spełnia różne wymagania strukturalne i dotyczące bezpieczeństwa.


## Odwołania
* [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/)

<details>

<summary><strong>Naucz się hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Inne sposoby wsparcia HackTricks:

* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLAN SUBSKRYPCJI**](https://github.com/sponsors/carlospolop)!
* Uzyskaj [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Podziel się swoimi trikami hakerskimi, przesyłając PR do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>