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) inaruhusu watoa kitambulisho (IdP) kutumika kwa kutuma ithibati za ruhusa kwa watoa huduma (SP), ikirahisisha kuingia mara moja (SSO). Njia hii inarahisisha usimamizi wa kuingia kwa mara nyingi kwa kuruhusu seti moja ya ithibati kutumika kwenye tovuti nyingi. Inatumia XML kwa mawasiliano ya viwango kati ya IdPs na SPs, ikihusisha uthibitishaji wa kitambulisho cha mtumiaji na ruhusa ya huduma.
SAML imeandaliwa kutoa udhibiti mkubwa kwa makampuni juu ya usalama wa kuingia SSO.
OAuth imeundwa kuwa rafiki zaidi kwa simu, inatumia JSON, na ni juhudi ya ushirikiano kutoka kwa kampuni kama Google na Twitter.
Kwa maelezo zaidi angalia chapisho kamili kutoka https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/. Hii ni muhtasari:
Mchakato wa uthibitishaji wa SAML unajumuisha hatua kadhaa, kama inavyoonyeshwa kwenye mpango:
Jaribio la Kupata Rasilimali: Mtumiaji anajaribu kufikia rasilimali iliyo na ulinzi.
Uundaji wa Ombi la SAML: SP haimtambui mtumiaji na unaunda Ombi la SAML.
Kuelekeza kwa IdP: Mtumiaji anapelekwa kwa IdP, huku Ombi la SAML likipitia kivinjari cha mtumiaji.
IdP Inapokea Ombi: IdP inapokea Ombi la SAML.
Uthibitishaji kwa IdP: IdP inathibitisha mtumiaji.
Uthibitishaji wa Mtumiaji: IdP inathibitisha uhalali wa mtumiaji kufikia rasilimali iliyohitajika.
Uundaji wa Jibu la SAML: IdP inaunda Jibu la SAML linalojumuisha uthibitisho muhimu.
Kuelekeza kwa URL ya ACS ya SP: Mtumiaji anapelekwa kwa URL ya Huduma ya Kuthibitisha ya SP (ACS).
Uthibitishaji wa Jibu la SAML: ACS inathibitisha Jibu la SAML.
Ruhusa ya Kupata Rasilimali: Ruhusa ya kufikia rasilimali iliyohitajika awali inatolewa.
Fikiria hali ambapo mtumiaji anahitaji kufikia rasilimali salama kwenye https://shibdemo-sp1.test.edu/secure/. SP inatambua ukosefu wa uthibitishaji na inaunda Ombi la SAML:
Ombi la SAML la msingi linaonekana kama hili:
Key elements of this request include:
AssertionConsumerServiceURL: Inabainisha mahali ambapo IdP inapaswa kutuma SAML Response baada ya uthibitisho.
Destination: Anwani ya IdP ambayo ombi linatumwa.
ProtocolBinding: Inaelezea njia ya usafirishaji wa ujumbe wa SAML protocol.
saml:Issuer: Inatambua chombo kilichozindua ombi hilo.
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.
You can find a full SAML response here. The key components of the response include:
ds:Signature: Sehemu hii, ni Saini ya XML, inahakikisha uadilifu na ukweli wa mtoaji wa uthibitisho. SAML response katika mfano ina vipengele viwili vya ds:Signature, kimoja kwa ujumbe na kingine kwa uthibitisho.
saml:Assertion: Sehemu hii ina habari kuhusu utambulisho wa mtumiaji na labda sifa nyingine.
saml:Subject: Inaelezea somo kuu la taarifa zote katika uthibitisho.
saml:StatusCode: Inawakilisha hali ya operesheni katika majibu ya ombi husika.
saml:Conditions: Inatoa maelezo kuhusu masharti kama muda wa uhalali wa Uthibitisho na Mtoa Huduma aliyetajwa.
saml:AuthnStatement: Inathibitisha kwamba IdP ilithibitisha somo la Uthibitisho.
saml:AttributeStatement: Inashikilia sifa zinazofafanua somo la Uthibitisho.
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 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:
An XML Signature consists of essential elements as shown:
Kila Reference kipengele kinamaanisha rasilimali maalum inayosainiwa, inayoweza kutambulika kwa sifa ya URI.
Saini ya Enveloped: Aina hii ya saini ni kizazi cha rasilimali inayosainiwa, ikimaanisha saini inapatikana ndani ya muundo sawa wa XML kama yaliyomo yaliyosainiwa.
Mfano:
Katika saini ya enveloped, kipengele ds:Transform kinabainisha kuwa inafanywa kupitia algorithm ya enveloped-signature.
Saini ya Enveloping: Ikilinganishwa na saini za enveloped, saini za enveloping zinapakia rasilimali inayosainiwa.
Mfano:
Saini ya Detached: Aina hii ni tofauti na yaliyomo inayosainiwa. Saini na yaliyomo yanakuwepo kwa uhuru, lakini kiungo kati ya hizo mbili kinahifadhiwa.
Mfano:
Kwa kumalizia, Saini za XML zinatoa njia za kubadilika za kulinda hati za XML, kila aina ikihudumia mahitaji tofauti ya muundo na usalama.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
