SAML SSO Güvenlik Testi: Assertion, İmza ve Tenant Eşlemesi

Kısa cevap

SAML SSO testi, XML imzası geçerli mi sorusundan ibaret değildir. Service Provider (SP), doğrulanmış assertion’ın doğru IdP’den geldiğini, kendisi için üretildiğini, güncel olduğunu ve giriş yapılacak tenant/kullanıcıya doğru eşlendiğini kanıtlamalıdır. İmzalı bir response içindeki yanlış assertion’ı uygulamanın kullanması, imza doğrulamasının var olduğu halde hesap ele geçirmeye yol açabilir.

SAML, kurumsal müşterilerin SaaS’a kimlik taşıdığı kritik bir güven sınırıdır. Metadata, sertifika, XML parser, browser binding ve kullanıcı provisioning akışlarının tamamı değerlendirilmelidir. Testi yalnızca IdP’nin “başarılı login” verdiği senaryoyla sınırlamayın.

SP-initiated ve IdP-initiated akışları ayırın

Önce uygulamanın desteklediği akışları ve her tenant için Entity ID, ACS URL, IdP issuer ve sertifika kaynağını çıkarın. SP-initiated akışta login isteği ile dönen assertion arasında InResponseTo bağı aranmalıdır. IdP-initiated SSO kullanılıyorsa unsolicited response riskini ve bunun neden gerekli olduğunu ayrıca değerlendirin; mümkünse bu akışı kapatın veya ek kontrollerle sınırlandırın.

Assertion içindeki Destination, Recipient, Audience, NotBefore, NotOnOrAfter ve subject confirmation alanlarının beklenen değerlerle tam eşleştiğini kontrol edin. Farklı SP’ye yönelik assertion, başka ACS’ye gönderilen response, gelecekte geçerli olacak assertion ve süresi dolmuş message reddedilmelidir. Saat toleransı tanımlı ve sınırlı olmalıdır.

XML imzası ve parser davranışı

İmza doğrulaması yapılan XML elementiyle uygulamanın kimlik için kullandığı assertion aynı olmalıdır. XML Signature Wrapping senaryosunda imzalı geçerli assertion bırakılıp yanına saldırgan kontrollü başka bir assertion eklenebilir; uygulama yanlış node’u seçerse doğrulama yanıltıcı biçimde başarılı görünür. Schema validation yerel ve güvenilir şemalarla yapılmalı; parser dış entity veya beklenmeyen remote schema yüklememelidir.

SP yalnızca tenant’ın kayıtlı IdP sertifikasına güvenmelidir. Assertion içindeki KeyInfo ile key seçimini saldırganın belirlemesine izin vermeyin. İzin verilen imza ve digest algoritmalarını açıkça belirleyin; SHA-1 gibi eski algoritmaların kabul edilmediğini, sertifika validity ve rollover sürecinin işlendiğini test edin.

Replay ve tenant/user eşlemesi

Aynı assertion’ı farklı browser session’ında ve ikinci kez kullanmayı deneyin. Response ID veya assertion ID için replay cache/işaretleme mekanizması, süre penceresi boyunca tekrar kullanımı engellemelidir. Bir tenant’a ait sertifikayla imzalanmış assertion, başka tenant’ın SSO bağlantısında kabul edilmemelidir.

E-posta eşleşmesi tek başına hesap birleştirme veya tenant üyeliği kanıtı değildir. issuer + subject gibi kararlı kimlikleri tenant bağlamında nasıl sakladığınızı inceleyin. SSO domain eşleşmesi, davet, just-in-time provisioning ve SCIM senaryolarında rol varsayılanlarının ayrıcalık vermediğini doğrulayın. Kullanıcı IdP’de silindiğinde veya tenant bağlantısı kaldırıldığında erişim ve mevcut oturumların ne zaman iptal edildiği tanımlı olmalıdır.

Metadata, sertifika rotasyonu ve operasyon

Metadata URL’si otomatik çekiliyorsa kaynağı, TLS doğrulamasını, update sıklığını ve değişikliğin kim tarafından onaylandığını inceleyin. Uzaktan gelen metadata’nın beklenmedik endpoint veya sertifika ekleyerek güven sınırını genişletmesine izin vermeyin. Sertifika rollover için eski ve yeni anahtarın birlikte kabul süresi planlanmalı; süresiz trust listesi bırakılmamalıdır.

SAML response ve assertion’lar kişisel veri içerebilir. Debug loglarında ham XML tutulması, auth hatasını teşhis etmeyi kolaylaştırırken token ve kullanıcı verisi sızıntısı yaratır. Loglarda correlation ID, tenant, doğrulama sonucu ve hata kodu bulunsun; assertion içeriği ve imza değeri redakte edilsin.

Test planı

1. Her tenant’ın SP/IdP konfigürasyonunu ve desteklenen SSO akışlarını envanterleyin.
2. Doğru response’u kaydedip audience, destination, recipient, zaman ve request bağı alanlarını değiştirin.
3. İmza wrapping, duplicate assertion, yanlış key ve algoritma senaryolarını güvenli test ortamında deneyin.
4. Replay, tenant çaprazlaması, hesap eşleme ve provisioning davranışını doğrulayın.
5. Metadata/sertifika rotasyonunu ve IdP kesintisi durumunu test edin.
6. Raporu ham assertion paylaşmadan, etkilenen kullanıcı/tenant ve giriş etkisiyle tamamlayın.

Logout ve oturum eşzamanlılığı

SAML Single Logout kullanılıyorsa SP ve IdP’nin hangi oturumları kapattığını, logout mesajının imza/destination kontrollerini ve bağlantı kopması davranışını test edin. IdP oturumu kapanırken SaaS’ın yerel session’ı açık kalabilir; bu davranış ürün politikasında net olmalıdır. Kullanıcı tenant’tan çıkarıldığında açık browser session, refresh/session cookie ve uzun yaşayan API token’larının ne zaman etkisiz kaldığını ölçün.

Aynı IdP ile birden çok tenant’a giren kullanıcıları da test edin. Callback’in tenant konfigürasyonu e-posta domain’inden tahmin edilmemeli; request state veya açık tenant seçimiyle güvenli belirlenmelidir. Doğru assertion imzasına rağmen yanlış tenant’a yönlendirme, yetki sınırı ihlalidir.

SP tarafında ACS endpoint’inin yalnızca beklenen HTTP binding ve content type’ları kabul ettiğini, response boyutu ve XML derinliğinin sınırlandığını da kontrol edin. Büyük ya da aşırı iç içe XML, kimlik doğrulama yolunu kaynak tüketimi saldırısına çevirebilir. Hata logları XML parse hatasını teşhis etmeye yetecek correlation bilgisi taşımalı ancak assertion içeriğini kaydetmemelidir.

SAML ve diğer login akışlarını uygulama kontrolleriyle beraber değerlendirmek için uygulama güvenliği testimize bakabilirsiniz.