<summary><strong>AWS hacklemeyi sıfırdan kahraman olmak için öğrenin</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Kırmızı Takım Uzmanı)</strong></a><strong>!</strong></summary>
* Şirketinizi HackTricks'te **reklamınızı görmek** veya **HackTricks'i PDF olarak indirmek** için [**ABONELİK PLANLARI**](https://github.com/sponsors/carlospolop)'na göz atın!
[**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor): Bir URL veya URL listesi alabilen ve SAML tüketim URL'sini geri döndürebilen bir araç.
XML'de XML'in imzalı kısmı bellekte saklanır, ardından bazı kodlama/çözme işlemleri gerçekleştirilir ve imza kontrol edilir. İdeal olarak, bu kodlama/çözme işlemi veriyi değiştirmemelidir, ancak bu senaryoya dayanarak, **kontrol edilen veri ve orijinal veri aynı olmayabilir**.
**XML İmza Sarma saldırıları (XSW)**, düşmanlar XML belgelerinin iki farklı aşamada işlendiği durumlarda ortaya çıkan bir zafiyeti sömürür: **imza doğrulama** ve **işlev çağrısı**. Bu saldırılar XML belge yapısını değiştirmeyle ilgilidir. Özellikle, saldırgan, XML İmza'nın geçerliliğini tehlikeye atmayan **sahte öğeler** enjekte eder. Bu manipülasyon, **uygulama mantığı** tarafından analiz edilen öğeler ile **imza doğrulama modülü** tarafından kontrol edilen öğeler arasında bir uyumsuzluk yaratmayı amaçlar. Sonuç olarak, XML İmza teknik olarak geçerli ve doğrulamayı geçerken, uygulama mantığı**sahte öğeleri** işler. Sonuç olarak, saldırgan XML İmza'nın **bütünlük korumasını** ve **köken doğrulamasını** etkili bir şekilde atlayarak, tespit edilmeden **keyfi içerik enjekte etmeyi** mümkün kılar.
Aşağıdaki saldırılar **[bu blog yazısına](https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/) ve [bu makaleye](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf)** dayanmaktadır. Daha fazla ayrıntı için bunları kontrol edin.
- **Strateji**: İmza içeren yeni bir kök öğe eklenir.
- **Sonuç**: Doğrulayıcı, meşru "Response -> Assertion -> Subject" ve saldırganın "kötü yeni Response -> Assertion -> Subject" arasında karışabilir, veri bütünlüğü sorunlarına yol açabilir.
- **Strateji**: Kopyalanan Assertion'ın bir çocuğu olarak bir Uzantılar öğesi eklenir.
- **Sonuç**: Bu, özellikle OpenSAML gibi kütüphanelerde şema doğrulama karşı önlemlerini atlamak için Uzantılar öğesinin daha az kısıtlayıcı şemasını istismar eder.
SAML isteğini ayrıştırmak, istediğiniz herhangi bir XSW saldırısını uygulamak ve başlatmak için Burp uzantısı [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e)'ı kullanabilirsiniz.
SAML Yanıtları, **sıkıştırılmış ve base64 kodlanmış XML belgeleri** olup XML Dışı Varlık (XXE) saldırılarına karşı hassas olabilir. SAML Yanıtının XML yapısını manipüle ederek, saldırganlar XXE zafiyetlerini istismar etmeye çalışabilir. İşte böyle bir saldırının nasıl görselleştirilebileceği:
Ayrıca, olası XXE zafiyetlerini ve SAML zafiyetlerini test etmek için bir SAML isteğinden POC oluşturmak için Burp eklentisi [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) kullanabilirsiniz.
Genişletilebilir Stil Şablonu Dönüşümleri (XSLT), XML belgelerini HTML, JSON veya PDF gibi çeşitli formatlara dönüştürmek için kullanılabilir. Önemli olan nokta, **XSLT dönüşümlerinin dijital imzanın doğrulanmasından önce gerçekleştirilmesidir**. Bu, geçerli bir imza olmadan bile saldırının başarılı olabileceği anlamına gelir; kendinden imzalı veya geçersiz bir imza yeterlidir.
Ayrıca, olası XSLT zafiyetlerini test etmek için bir SAML isteğinden POC üretmek için Burp eklentisi olan [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) kullanabilirsiniz.
**XML İmza Hariç Tutma**, İmza öğesi bulunmadığında SAML uygulamalarının davranışını gözlemlemektedir. Bu öğe eksik olduğunda, **imza doğrulaması gerçekleşmeyebilir**, bu da zafiyete neden olur. Bu, genellikle imza tarafından doğrulanan içerikleri değiştirerek test edilebilir.
Sertifika Sahteciliği, bir **Hizmet Sağlayıcının (SP) bir SAML İletisinin güvenilir bir Kimlik Sağlayıcı (IdP) tarafından imzalandığını** doğru bir şekilde doğrulayıp doğrulamadığını test etmek için bir tekniktir. Bu, SAML Raider Burp eklentisini kullanarak bir ***kendinden imzalı sertifika** kullanarak SAML Yanıtını veya İddia'yı imzalamayı içerir ve SP ve IdP arasındaki güven doğrulama sürecini değerlendirmede yardımcı olur.
2. Yanıt bir imza içeriyorsa, sertifikayı SAML Raider Certs'e `Sertifikayı SAML Raider Certs'e Gönder` düğmesini kullanarak gönderin.
3. SAML Raider Sertifikaları sekmesinde, içe aktarılan sertifikayı seçin ve orijinal sertifikanın kendinden imzalı bir klonunu oluşturmak için `Kaydet ve Kendinden İmzala` düğmesine tıklayın.
4. Burp'un Proxy'sindeki yakalanan isteğe geri dönün. XML İmza açılır menüsünden yeni kendinden imzalı sertifikayı seçin.
5.`İmzaları Kaldır` düğmesiyle mevcut imzaları kaldırın.
6. İletiyi veya iddiayı yeni sertifika ile imzalayın, uygun olan **`(Yeniden) İleti İmzala`** veya **`(Yeniden) İddia İmzala`** düğmesini kullanarak.
7. İmzalı iletiyi ileterek işlemi tamamlayın. Başarılı kimlik doğrulama, SP'nin kendinden imzalı sertifikanızla imzalanan iletileri kabul ettiğini gösterir ve SAML iletilerinin doğrulama sürecindeki potansiyel zafiyetleri ortaya çıkarır.
Token Alıcı Karışıklığı ve Hizmet Sağlayıcı Hedef Karışıklığı, bir **Hizmet Sağlayıcının yanıtın amaçlanan alıcısını doğru bir şekilde doğrulayıp doğrulamadığını** kontrol etmeyi içerir. Temelde, bir Hizmet Sağlayıcı, yanıtın başka bir sağlayıcı için mi yoksa kendisi için mi olduğunu belirlemeli ve yanıt başka bir sağlayıcı içinse kimlik doğrulamasını reddetmelidir. Buradaki kritik unsur, bir SAML Yanıtının **SubjectConfirmationData** öğesinin içinde bulunan **Alıcı** alanıdır. Bu alan, İddianın gönderilmesi gereken bir URL'yi belirtir. Gerçek alıcı, amaçlanan Hizmet Sağlayıcıyla eşleşmiyorsa, İddia geçersiz kabul edilmelidir.
Bir SAML Token Alıcı Karışıklığı (SAML-TRC) saldırısının gerçekleştirilebilmesi için belirli koşulların sağlanması gerekmektedir. İlk olarak, bir Hizmet Sağlayıcıda (SP-Legit olarak adlandırılır) geçerli bir hesap olmalıdır. İkinci olarak, hedeflenen Hizmet Sağlayıcı (SP-Target), SP-Legit'e hizmet veren aynı Kimlik Sağlayıcıdan tokenları kabul etmelidir.
Bu koşullar altında saldırı süreci basittir. Paylaşılan Kimlik Sağlayıcı aracılığıyla SP-Legit ile otantik bir oturum başlatılır. Kimlik Sağlayıcıdan SP-Legit'e yönelik SAML Yanıtı yakalanır. Bu SP-Legit için orijinal olarak amaçlanan SAML Yanıtı, SP-Target'e yönlendirilir. Bu saldırıda başarı, SP-Target'in İddiayı kabul etmesi ve SP-Legit için kullanılan aynı hesap adı altında kaynaklara erişimi sağlamasıyla ölçülür.
Bu, `base` parametresinin bir URL kabul ettiğini ortaya çıkardı. Buna göre, URL'yi `javascript:alert(123);` ile değiştirerek XSS (Cross-Site Scripting) saldırısı başlatma girişiminde bulunma fikri ortaya çıktı.
`uberinternal.com` alt alan adlarını analiz etmek için [**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor) aracı kullanıldı ve aynı kütüphaneyi kullanan alan adları tespit edildi. Ardından, `oidauth/prompt` sayfasını hedefleyen bir betik geliştirildi. Bu betik, veri girişi yaparak çıktıda yansıtılıp yansıtılmadığını kontrol ederek XSS (Cross-Site Scripting) testi yapar. Giriş yansıtılıyorsa, betik sayfayı savunmasız olarak işaretler.
* Şirketinizi HackTricks'te **reklamınızı görmek** veya **HackTricks'i PDF olarak indirmek** için [**ABONELİK PLANLARI**](https://github.com/sponsors/carlospolop)'na göz atın!
* Özel [**NFT'lerden**](https://opensea.io/collection/the-peass-family) oluşan koleksiyonumuz [**The PEASS Family**](https://opensea.io/collection/the-peass-family)'yi keşfedin
* 💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) **katılın** veya bizi **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**'da takip edin.**