SAML Basics
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Security Assertion Markup Language (SAML) omogućava korišćenje provajdera identiteta (IdP) za slanje autorizacionih kredencijala provajderima usluga (SP), olakšavajući jedinstveno prijavljivanje (SSO). Ovaj pristup pojednostavljuje upravljanje višestrukim prijavama omogućavajući korišćenje jednog skupa kredencijala na više veb sajtova. Koristi XML za standardizovanu komunikaciju između IdP-a i SP-a, povezujući autentifikaciju identiteta korisnika sa autorizacijom usluga.
SAML je prilagođen za pružanje preduzećima veće kontrole nad bezbednošću SSO prijavljivanja.
OAuth je dizajniran da bude više prilagođen mobilnim uređajima, koristi JSON i rezultat je saradnje kompanija kao što su Google i Twitter.
Za više detalja pogledajte ceo post sa https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/. Ovo je sažetak:
Proces SAML autentifikacije uključuje nekoliko koraka, kao što je prikazano u šemi:
Pokušaj pristupa resursu: Korisnik pokušava da pristupi zaštićenom resursu.
Generisanje SAML Zahteva: SP ne prepoznaje korisnika i generiše SAML Zahtev.
Preusmeravanje na IdP: Korisnik se preusmerava na IdP, pri čemu SAML Zahtev prolazi kroz korisnikov pretraživač.
IdP prima zahtev: IdP prima SAML Zahtev.
Autentifikacija na IdP: IdP autentifikuje korisnika.
Validacija korisnika: IdP validira legitimnost korisnika za pristup traženom resursu.
Kreiranje SAML Odgovora: IdP generiše SAML Odgovor koji sadrži potrebne tvrdnje.
Preusmeravanje na SP-ovu ACS URL: Korisnik se preusmerava na SP-ovu URL adresu za uslugu potrošnje tvrdnji (ACS).
Validacija SAML Odgovora: ACS validira SAML Odgovor.
Odobren pristup resursu: Pristup inicijalno traženom resursu je odobren.
Razmotrite scenario u kojem korisnik traži pristup sigurnom resursu na https://shibdemo-sp1.test.edu/secure/. SP identifikuje nedostatak autentifikacije i generiše SAML Zahtev:
Raw SAML zahtev izgleda ovako:
Ključni elementi ovog zahteva uključuju:
AssertionConsumerServiceURL: Određuje gde IdP treba da pošalje SAML odgovor nakon autentifikacije.
Destination: Adresa IdP-a na koju se zahtev šalje.
ProtocolBinding: Definiše metodu prenosa SAML protokol poruka.
saml:Issuer: Identifikuje entitet koji je inicirao zahtev.
Nakon generisanja SAML zahteva, SP odgovara sa 302 preusmeravanjem, usmeravajući pregledač ka IdP-u sa SAML zahtevom kodiranim u Location header-u HTTP odgovora. RelayState parametar održava informacije o stanju tokom transakcije, osiguravajući da SP prepozna inicijalni zahtev za resurs prilikom primanja SAML odgovora. SAMLRequest parametar je kompresovana i kodirana verzija sirovog XML isječka, koristeći Deflate kompresiju i base64 kodiranje.
Možete pronaći puni SAML odgovor ovde. Ključne komponente odgovora uključuju:
ds:Signature: Ovaj deo, XML potpis, osigurava integritet i autentičnost izdavaoca asertacije. SAML odgovor u primeru sadrži dva ds:Signature elementa, jedan za poruku i drugi za asertaciju.
saml:Assertion: Ovaj deo sadrži informacije o identitetu korisnika i moguće druge atribute.
saml:Subject: Određuje glavnog subjekta svih izjava u asertaciji.
saml:StatusCode: Predstavlja status operacije kao odgovor na odgovarajući zahtev.
saml:Conditions: Detalji o uslovima kao što su vremenski okvir važenja asertacije i određeni provajder usluga.
saml:AuthnStatement: Potvrđuje da je IdP autentifikovao subjekat asertacije.
saml:AttributeStatement: Sadrži atribute koji opisuju subjekat asertacije.
Nakon SAML odgovora, proces uključuje 302 preusmeravanje sa IdP-a. To dovodi do POST zahteva ka URL-u usluge potrošnje asertacija (ACS) provajdera usluga. POST zahtev uključuje RelayState i SAMLResponse parametre. ACS je odgovoran za obradu i validaciju SAML odgovora.
Nakon što je POST zahtev primljen i SAML odgovor validiran, pristup se odobrava za zaštićeni resurs koji je prvobitno zahtevao korisnik. Ovo je ilustrovano sa GET zahtevom ka /secure/ endpoint-u i 200 OK odgovorom, što ukazuje na uspešan pristup resursu.
XML potpisi su svestrani, sposobni da potpišu celu XML stablo ili specifične elemente unutar njega. Mogu se primeniti na bilo koji XML objekat, ne samo na elemente odgovora. Ispod su ključne vrste XML potpisa:
XML potpis se sastoji od osnovnih elemenata kao što je prikazano:
Svaki Reference element označava specifičan resurs koji se potpisuje, prepoznatljiv po URI atributu.
Enveloped Signature: Ova vrsta potpisa je potomak resursa koji potpisuje, što znači da je potpis sadržan unutar iste XML strukture kao i potpisani sadržaj.
Primer:
U enveloped potpisu, ds:Transform element specificira da je potpis obavijen kroz enveloped-signature algoritam.
Enveloping Signature: U suprotnosti sa enveloped potpisima, enveloping potpisi obavijaju resurs koji se potpisuje.
Primer:
Detached Signature: Ova vrsta je odvojena od sadržaja koji potpisuje. Potpis i sadržaj postoje nezavisno, ali se održava veza između njih.
Primer:
U zaključku, XML potpisi pružaju fleksibilne načine za osiguranje XML dokumenata, pri čemu svaka vrsta zadovoljava različite strukturne i sigurnosne potrebe.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
