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), kimlik sağlayıcılarının (IdP) hizmet sağlayıcılarına (SP) yetkilendirme kimlik bilgilerini göndermesine olanak tanır ve tek oturum açma (SSO) işlemini kolaylaştırır. Bu yaklaşım, bir dizi kimlik bilgisi kullanarak birden fazla web sitesinde oturum açmayı yönetmeyi basitleştirir. IdP'ler ve SP'ler arasında standartlaştırılmış iletişim için XML kullanır ve kullanıcı kimliğinin doğrulanmasını hizmet yetkilendirmesi ile ilişkilendirir.
SAML, işletmelere SSO oturum açma güvenliği üzerinde daha fazla kontrol sağlamak için tasarlanmıştır.
OAuth, daha mobil dostu olacak şekilde tasarlanmış, JSON kullanır ve Google ve Twitter gibi şirketlerin ortak çabasıdır.
Daha fazla ayrıntı için https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/ adresindeki tam gönderiyi kontrol edin. Bu bir özet:
SAML kimlik doğrulama süreci, şemada gösterildiği gibi birkaç adım içerir:
Kaynağa Erişim Denemesi: Kullanıcı korumalı bir kaynağa erişmeye çalışır.
SAML İsteği Oluşturma: SP, kullanıcıyı tanımaz ve bir SAML İsteği oluşturur.
IdP'ye Yönlendirme: Kullanıcı, SAML İsteği kullanıcının tarayıcısından geçerek IdP'ye yönlendirilir.
IdP İsteği Alır: IdP, SAML İsteğini alır.
IdP'de Kimlik Doğrulama: IdP, kullanıcıyı kimlik doğrular.
Kullanıcı Doğrulaması: IdP, kullanıcının talep edilen kaynağa erişim yetkisini doğrular.
SAML Yanıtı Oluşturma: IdP, gerekli beyanları içeren bir SAML Yanıtı oluşturur.
SP'nin ACS URL'sine Yönlendirme: Kullanıcı, SP'nin Beyan Tüketim Servisi (ACS) URL'sine yönlendirilir.
SAML Yanıtı Doğrulama: ACS, SAML Yanıtını doğrular.
Kaynağa Erişim Verildi: İlk talep edilen kaynağa erişim verilir.
Bir kullanıcının https://shibdemo-sp1.test.edu/secure/ adresindeki güvenli bir kaynağa erişim talep ettiği senaryoyu düşünün. SP, kimlik doğrulamanın eksikliğini tespit eder ve bir SAML İsteği oluşturur:
Ham SAML İsteği şu şekilde görünür:
Key elements of this request include:
AssertionConsumerServiceURL: IdP'nin kimlik doğrulama sonrası SAML Yanıtını göndermesi gereken yeri belirtir.
Destination: Talebin gönderildiği IdP'nin adresi.
ProtocolBinding: SAML protokol mesajlarının iletim yöntemini tanımlar.
saml:Issuer: Talebi başlatan varlığı tanımlar.
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: Bu bölüm, bir XML İmzasıdır ve beyanın vericisinin bütünlüğünü ve doğruluğunu sağlar. Örnekteki SAML yanıtı, bir mesaj için ve diğeri beyan için olmak üzere iki ds:Signature öğesi içerir.
saml:Assertion: Bu kısım, kullanıcının kimliği ve muhtemelen diğer nitelikler hakkında bilgi tutar.
saml:Subject: Beyandaki tüm ifadelerin ana konusunu belirtir.
saml:StatusCode: İlgili talebe yanıt olarak işlemin durumunu temsil eder.
saml:Conditions: Beyanın geçerlilik süresi ve belirtilen Hizmet Sağlayıcı gibi koşulları detaylandırır.
saml:AuthnStatement: IdP'nin Beyanın konusunu kimlik doğruladığını onaylar.
saml:AttributeStatement: Beyanın konusunu tanımlayan nitelikleri içerir.
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 İmzaları çok yönlüdür, bir XML ağacını veya içindeki belirli öğeleri imzalamak için kullanılabilirler. Herhangi bir XML Nesnesine, yalnızca Yanıt öğelerine değil, uygulanabilirler. Aşağıda XML İmzalarının ana türleri bulunmaktadır:
An XML Signature consists of essential elements as shown:
Her Reference elementi, URI niteliği ile tanımlanabilen, imzalanan belirli bir kaynağı belirtir.
Enveloped Signature: Bu tür imza, imzaladığı kaynağın bir alt kümesidir, yani imza, imzalanan içerikle aynı XML yapısı içinde yer alır.
Örnek:
Enveloped signature'da, ds:Transform elementi, imzanın enveloped-signature algoritması ile sarıldığını belirtir.
Enveloping Signature: Enveloped signature'ların aksine, enveloping signature'lar imzalanan kaynağı sarar.
Örnek:
Detached Signature: Bu tür, imzaladığı içerikten ayrıdır. İmza ve içerik bağımsız olarak var olur, ancak ikisi arasında bir bağlantı korunur.
Örnek:
Sonuç olarak, XML İmzaları, XML belgelerini güvence altına almak için esnek yollar sunar; her tür, farklı yapısal ve güvenlik ihtiyaçlarını karşılar.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
