Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 21:24:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/saml-attacks/saml-basics.md
Translator workflow 5e0daf0e23 Translated to Polish
2024-02-11 01:46:25 +00:00

9.6 KiB
Raw Blame History

Dowiedz się, jak hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

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

  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/. 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 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. 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:

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

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

  1. Podpis otaczający: W przeciwieństwie do podpisów osadzonych, podpisy otaczające owijają podpisywany zasób.

Przykład:

<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
<samlp:Response ... ID="..." ... >
...
</samlp:Response>
</ds:Signature>
  1. 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:

<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

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks: