Series · 5 partsExternal Perimeter IntelligencePart 5 · You are here
- 1Dış Çevre İstihbarat Grafiği: Varlık İlişkilerini Haritalandırmak
- 2Domain Sahipliği ve Varlık Atıf Kanıtı: Dış Yüzeyde Yanılgılar
- 3Üretici Kapsam Dışıydı. Güven Sınırı Değildi: 3. Taraf Entegrasyonları
- 4Servis Gözlemlendi. Uygulama Hâlâ Bilinmiyordu: Dış Keşif
- 5Giriş Sayfası Kamusaldı. Kimlik Sınırı Başka Bir YerdeydiYou are here
60 saniyede kimlik sınırı haritalama
Halka açık bir uygulama tarayıcıyı bir kimlik sağlayıcıya (identity provider - IdP) yönlendirir. Kullanıcı giriş yapar, /callback uç noktasına geri döner ve bir uygulama cookie’si alır. Bu sürece bakıp “OIDC ile giriş yapıyor” notunu düşüp yola devam etmek cazip gelebilir. Ancak kullanıcının gördüğü o giriş sayfası, arkada çalışan çok daha uzun bir yetki karar zincirinin yalnızca ilk karesidir.
Uygulamanın şu kararları hâlâ bağımsız olarak vermesi gerekir:
- Bu gelen yanıt hangi issuer’a ve client’a aittir?
- Callback, tam olarak bu tarayıcının başlattığı akışa mı aittir?
- Hangi token türü, imza algoritması, anahtar, audience, nonce ve geçerlilik süresi kabul edilebilir?
- Hangi harici kimlik, hangi yerel hesaba dönüştürülecektir?
- Bu yerel hesap hangi organizasyonu, kiracıyı (tenant), rolü ve izinleri alacaktır?
- Yeni bir yerel oturum ne zaman oluşturulacak, rotate edilecek, yenilenecek, iptal edilecek veya kurtarılacaktır?
- Oturumu kapatma (logout), parola sıfırlama, hesabı devre dışı bırakma ve rol değişiklikleri mevcut aktif oturumları anında etkiliyor mu?
İşte kimlik sınırı tam olarak bu zincirin kendisidir; giriş formu değil. Bir kimlik sağlayıcı bir kişinin kimliğini kusursuz bir şekilde doğrulayabilir; ancak müşteri uygulaması bu kimliği yanlış kiracıya bağlayabilir, başka bir istemci (client) için üretilmiş bir token’ı kabul edebilir, kimlik doğrulama öncesi oturumu (pre-authentication session) koruyabilir veya sıradan bir claim’i yönetimsel bir yetkiye dönüştürebilir.
Dolayısıyla harici bir pentester’ın görevi sağlayıcıya (IdP altyapısına) saldırmak değildir. Asıl görev, müşteri tarafından kontrol edilen kimlik sözleşmesini (identity contract) yeniden inşa etmek ve onaylanmış test kimliklerini kullanarak yerel yetkiyi doğuran kararları denetlemektir.
Kimlik doğrulama ile yetkilendirme aynı karar değildir
Kimlik doğrulama (authentication) dar bir soruyu yanıtlar: Güvenilir bir kimlik doğrulayıcı hangi kimliği tespit etti? İş uygulamasının ise bambaşka bir problemi vardır: Bu kimlik burada, bu kiracıda, bu nesne üzerinde, iş akışının tam bu anında ne yapabilir?
OpenID Connect bu ayrımı çok net ortaya koyar. Bir ID Token, bir kimlik doğrulama olayına ve son kullanıcıya dair claim’ler taşır. Güvenen tarafın (relying party) yine de token’ı doğrulaması ve bu claim’lerin yerel duruma nasıl eşleneceğine karar vermesi gerekir. Özellikle OpenID Connect Core spesifikasyonu, iss, sub ve aud değerlerini birbirinden bağımsız kimlik koordinatları olarak tanımlar. Bir subject (sub) değeri yalnızca belirli bir issuer bünyesinde yerel olarak benzersizdir; farklı bir issuer altındaki aynı sub değeri tamamen farklı bir kimliktir. Audience (aud) ise token’ın hangi client için üretildiğini tanımlar. Bu politika kontrolleri olmadan yalnızca geçerli bir imzanın varlığı asla yeterli değildir.
JWT güvenlik en iyi uygulamaları rehberi (RFC 8725), uygulamanın sorumluluğunu açıkça ortaya koyar: Anahtarlar güvenilen issuer’a ait olmalı, issuer-subject çifti uygulama açısından geçerli bulunmalı ve token’ların birden fazla uygulamaya hizmet edebildiği yerlerde doğrudan alıcıyı hedefleyen bir audience bulunmalı ve denetlenmelidir.
Bu durum şu modeli ortaya çıkarır:
Sağlayıcı harici bir kimliği tespit eder. Uygulama ise bu kimliğin kabul edilebilir olup olmadığına, hangi yerel süjeye dönüşeceğine ve bu süjenin hangi yetkiyi alacağına karar verir.
Bu üç adım “SSO çalışıyor” denilerek tek bir potada eritildiğinde, müşteri kontrolündeki en kritik kararlar test planından silinmiş olur.
Görünen akış yedi karar noktasını gizler
Bu yedi nokta birbirinden farklı kanıtlar gerektirir:
| Karar noktası | Saklanacak kanıt | Güvenlik sorusu |
|---|---|---|
| Giriş başlangıcı | Uygulama rotası, parametreler, cookie’ler, yanıt, zaman damgası | Uygulama bu tarayıcı için spesifik tek bir akış başlattı mı? |
| Yetkilendirme talebi | Issuer host, client ID, redirect URI, scope’lar, state, nonce, PKCE | İstek doğru sağlayıcıya, istemciye ve dönüş rotasına bağlı mı? |
| Callback | Dönüş yolu, response mode, authorization code/assertion, korelasyon state | Yanıt başka bir akışla değiştirilebilir, replay edilebilir veya iliştirilebilir mi? |
| Token doğrulaması | Token türü, header, claim’ler, anahtar kaynağı, doğrulama sonucu | İmza, issuer, audience, nonce, süre ve token amacı zorunlu tutuluyor mu? |
| Hesap bağlama | Issuer-subject çifti ve yerel hesap tanımlayıcısı | İki harici kimlik çakışabilir veya aynı yerel hesaba bağlanabilir mi? |
| Yetki dönüştürme | Tenant, organizasyon, rol, grup, scope, hak kaynağı | Hangi claim veya yerel kayıt yetkiyi veriyor ve hangisi öncelikli? |
| Yerel oturum ve eylemler | Cookie yaşam döngüsü, hesap bağlamı, API çağrıları, nesne etkileri | Yetki; giriş, yenileme, değişiklik ve çıkış boyunca doğru kalıyor mu? |
Test etmeden önce kimlik sözleşmesini haritalandırın
İlk geçiş salt gözleme dayalı olmalıdır. Onaylanmış uygulama giriş noktasından başlayın ve sağlayıcı kiracılarını (tenants) numaralandırmaya veya gerçek kullanıcı hesaplarını kurcalamaya çalışmadan yönlendirme zincirini kaydedin. Kamuya açık meta veriler, müşteri yapılandırması, tarayıcı istekleri, yanıt başlıkları ve sağlanan test hesapları bu sözleşmeyi kurmak için genellikle fazlasıyla yeterlidir.
Her uygulama için şunları kaydedin:
- Giriş noktası: Bölgesel, iş ortağı, yönetici, mobil ve kurtarma varyantları dahil olmak üzere girişi başlatan müşteri URL’si.
- Protokol rolü: Relying party (RP) veya client, yetkilendirme sunucusu (authorization server) veya kimlik sağlayıcı (IdP), kaynak sunucusu (resource server) ve aralarındaki herhangi bir aracı broker.
- Issuer ve uç noktalar: Tam issuer tanımlayıcısı, authorization ve token uç noktaları, anahtar kaynağı (JWKS), callback rotaları, logout rotaları ve hesap kurtarma rotaları.
- İstemci bağlamı: Client ID, redirect URI, response type, response mode, scope’lar ve PKCE,
stateilenonceparametrelerinin varlığı. - Kimlik anahtarı: Sağlayıcı kimliğini yerel hesaba bağlamak için kullanılan alanlar. İdeal olan, değiştirilebilir bir e-posta veya görünen ad değil; kararlı issuer-subject çiftidir.
- Yetki kaynağı: Yerel veritabanı, sağlayıcı grubu, uygulama rolü, kiracı üyeliği, davetiye, destek müdahalesi veya bunların birleşimi.
- Oturum modeli: Giriş öncesi cookie, giriş sonrası cookie, token yenileme davranışı, boşta kalma ve mutlak geçerlilik süreleri, eşzamanlı oturumlar, logout, iptal ve cihaz/kiracı değiştirme.
- Yaşam döngüsü kenarları: İlk giriş, davet kabulü, hesap bağlama, e-posta değişikliği, rol değişikliği, kiracıdan çıkarılma, parola sıfırlama, MFA kurtarma, hesabı dondurma ve silme.
Bu envanter, “SSO kullanıyor” cümlesini yanlışlanabilir bir sistem modeline dönüştürür. Bilinmeyen alanlar “bilinmiyor” olarak işaretlenir; asla sağlayıcının varsayılan değerleriyle sessizce doldurulmaz.
Protokol doğruluğu zorunludur, ancak sınırı politika çizer
OAuth 2.0 Güvenlik En İyi Güncel Uygulamaları (RFC 9700); kayıtlı redirect URI’lerinin tam (exact) eşleşmesini, access token’ların tarayıcı URL’lerinde ifşa edilmemesi için Authorization Code akışının kullanılmasını ve kod enjeksiyonuna karşı PKCE gibi korumaları önerir. Bu kontroller kritiktir; ancak protokole harfiyen uyan bir veri değişimi bile güvensiz bir yerel karara yol açabilir.
Dört örneği ele alalım:
Güvenilen issuer, yanlış audience. İmza gerçektir ve token günceldir; ancak aynı kimlik havuzundaki başka bir istemci için üretilmiştir. Uygulama yalnızca imzayı doğrularsa, kendisine asla verilmemiş bir yetkiyi kabul edebilir.
Doğru kullanıcı, yanlış tenant. Issuer ve subject geçerlidir; ancak organizasyon tanımlayıcısı doğrulanmış üyelikten değil, girişten sonra tarayıcıdan gelen bir parametreden alınır. Kimlik doğrulama başarılıdır; kiracı yetkilendirmesi çöker.
Doğru claim, yanlış anlam. Sağlayıcı tarafındaki billing-admin adlı bir grup, bir uygulamada bilgilendirme amaçlıyken diğerinde ayrıcalıklı bir rol olabilir. Tehlike claim’in sahte olması değildir. Tehlike, geniş kapsamlı bir dizin grubunun belgelenmemiş bir şekilde yerel bir yönetici rolüne dönüştürülmesidir.
Doğru giriş, bayatlamış yerel oturum. Hesap sağlayıcı tarafında devre dışı bırakılmış veya kiracıdan çıkarılmıştır; ancak uygulama oturumu önbelleğe alınmış yetkilerle çalışmaya devam eder. Kimlik doğrulama gerçekleştiği anda doğruydu; ancak sonrasındaki yaşam döngüsü sözleşmesi başarısız olmuştur.
Bu nedenle test planı iki katmanı birbirinden ayırmalıdır:
- Protokol kabulü: Bu yanıt, token veya assertion bu istemci tarafından kabul edilebilir mi?
- İş yetkisi: Kabul edildikten sonra hangi yerel hesap, kiracı, rol, nesneler ve etkiler erişilebilir hale gelir?
Yalnızca ilk katmanı test etmek ortaya bir token kontrol listesi çıkarır. Her iki katmanı birden test etmek ise gerçek bir kimlik değerlendirmesi üretir.
Oturum, harici kimliğin yerel kalıcılığa dönüştüğü yerdir
Federe kimlik doğrulama, uygulamanın oturum güvenliği ihtiyacını ortadan kaldırmaz. Kimlik doğrulama anını başka bir sisteme devreder; ardından müşteri uygulamasından yerel durumu oluşturmasını ve sürdürmesini ister.
Giriş yapmadan önce doğrulanmamış oturum cookie’sini kaydedin ve callback sonrasındaki kimliği doğrulanmış cookie ile karşılaştırın. Ayrıcalıklı bir geçiş, saldırgan tarafından önceden bilinen bir giriş öncesi durumu meşrulaştırmamalıdır. OWASP’ın session fixation test rehberi, temel soruyu netleştirir: Uygulama başarılı kimlik doğrulamasından sonra yepyeni bir oturum tanımlayıcısı üretiyor mu?
Giriş anında oturumu yenilemek (rotation) yalnızca ilk kontroldür. Aynı analiz her yetki değişikliği için geçerlidir:
| Geçiş | Beklenen yerel davranış |
|---|---|
| Anonim → Kimlik doğrulanmış | Oturumu değiştirin veya güvenle rotate edin; doğrulanmış süjeye bağlayın |
| Kullanıcı → Yönetici | Yetkiyi yeniden değerlendirin ve uygun yerlerde hassas oturum durumunu rotate edin |
| Kiracı A → Kiracı B | Kiracı bağlamını açıkça değiştirin; nesne ve önbellek sızıntılarını engelleyin |
| Oturum yenileme (Refresh) | Doğru issuer, client, subject, tenant ve scope kısıtlamalarını koruyun |
| Parola veya MFA kurtarma | Eski oturumları ve kurtarma verilerini geçersiz kılın veya kontrollü yönetin |
| Rol veya grup çıkarılması | Tanımlanmış, test edilebilir bir zaman aralığında geçerli yetkiyi sonlandırın |
| Hesabın dondurulması | Yeni oturumları engelleyin; mevcut oturumları politikaya göre iptal edin veya süresini doldurun |
| Çıkış (Logout) | Yerel oturumu sonlandırın; yerel çıkış ile IdP genelindeki SSO çıkışını ayırt edin |
Cookie bayrakları (flags) faydalı kanıtlardır, nihai hüküm değildir. Secure, HttpOnly, SameSite, Domain, Path ve geçerlilik süresi ayarları tarayıcının veriyi nasıl ele alacağını belirler. Ancak sunucunun bu oturumu rotate ettiğini, iptal ettiğini, doğru kiracıya bağladığını veya hesap değiştikten sonra kabul etmeyi bıraktığını kanıtlamaz.
Kontrollü kimliklerle rol ve kiracı matrisi oluşturun
Kimlik testleri, her sonucun karşılaştırılabilir bir referansı olduğunda savunulabilir hale gelir. Müşteriden kritik sınırları temsil eden en küçük sentetik kimlik kümesini isteyin: Anonim, standart kullanıcı, aynı kiracıdaki ikinci bir kullanıcı, başka bir kiracıdaki bir kullanıcı ve onaylanmış bir ayrıcalıklı rol. Müşteriye ait test verilerini ve geri alınabilir eylemleri kullanın.
OWASP rol tanımı test rehberi, uygulamanın rollerini tanımlamak ve belgelemekle başlar. Gerçek bir değerlendirmede bu rol listesini kimlik, kiracı, nesne sahipliği, iş akışı durumu ve beklenen etki matrisine genişletin:
| Test kimliği | Kiracı bağlamı | Nesne ilişkisi | İşlev | Beklenen sonuç |
|---|---|---|---|---|
| Anonim | Yok | Yok | Hesap panelini görüntüle | Engelle ve girişe yönlendir |
| Kullanıcı A | Meridian | Sahip | Kendi faturasını oku | İzin ver |
| Kullanıcı B | Meridian | Aynı kiracı | Kullanıcı A faturasını oku | Açıkça paylaşılmadıkça engelle |
| Kullanıcı C | Northwind | Farklı kiracı | Kullanıcı A faturasını oku | Engelle |
| Fatura yöneticisi | Meridian | Kiracı yönetimi | Faturayı onayla | Kaydedilen audit loguyla izin ver |
| Kullanıcı A | Meridian | Sahip | Yönetici rolü ata | Engelle |
En kritik sütun “Beklenen sonuç” sütunudur. Bu olmadan, bir HTTP 200 yanıtı yalnızca sıradan bir gözlemdir. Bu sütun olduğunda ise aynı yanıt, ya hedeflenen meşru erişimi ya da bir yetkilendirme zafiyetini kanıtlar. Sonrasındaki etkiyi de kaydedin: veri döndü mü, kayıt değişti mi, mesaj kuyruğa girdi mi, yetki verildi mi yoksa hiçbir şey olmadı mı?
Negatif kontroller bulguyu inandırıcı kılar
Bir kimlik sonucu tek bir başarılı istekten fazlasını gerektirir. Güçlü bir kanıt; geçerli bir kontrol, geçersiz bir karşılaştırma ve gözlemlenebilir bir etki içerir.
Kullanışlı negatif kontroller şunları içerir:
- Farklı bir onaylı kullanıcıyla aynı nesneye erişim;
- Farklı bir onaylı kiracıda aynı role sahip olma durumu;
- Logout, rol iptali veya hesabın kapatılmasından sonra aynı oturumun kullanılması;
- Kontrollü bir testte eksik veya eşleşmeyen akış korelasyonuyla aynı callback çağrısı;
- Müşteri test ortamında yanlış audience değerine sahip aynı imzalı token;
- UI ve doğrudan API rotaları üzerinden çağrılan aynı işlev;
- Geçersiz bir iş akışı durumunda çağrılan aynı iş eylemi.
Bu matrisi rastgele token tahrifatına (mutation) dönüştürmeyin. Amaç, bir kimlik sağlayıcıyı geçersiz trafikle boğmak değil; müşterinin doğrulama ve yetkilendirme kararlarını mümkün olan en az sayıda istekle izole etmektir.
Sağlayıcıyı ateş hattının dışında tutun
Kimlik sağlayıcı mimari açıdan kritik ve sözleşmesel olarak kapsam dışı olabilir. Bu tamamen olağandır. Değerlendirme; müşteri kontrolündeki relying party’yi, istemci kaydını, callback işleyicisini, hesap bağlama mantığını, yerel rol dönüşümünü, API yetkilendirmesini ve oturum yaşam döngüsünü yine de eksiksiz denetleyebilir.
Aktif teste başlamadan önce sınırları netleştirin:
- Onaylanmış müşteri uygulamaları, callback rotaları, kiracılar, hesaplar, roller ve kaynak IP adresleri;
- Müşterinin bir test kimlik tenant’ı veya izole federasyon yapılandırması sağlayıp sağlayamayacağı;
- İzin verilen giriş denemesi hacmi ve MFA davranışı;
- Parola püskürtme (password spraying), gerçek kullanıcı keşfi, kullanıcılara habersiz MFA bildirimi tetikleme, sağlayıcı kiracılarını tarama veya sağlayıcı altyapısını test etme gibi yasaklanmış eylemler;
- Test nesneleri ve geri alınabilir yan etkiler;
- Hesap kilitlenmesi, kiracılar arası yetkisiz erişim, gerçek prodüksiyon verisiyle karşılaşma veya beklenmeyen sağlayıcı davranışlarında geçerli acil irtibatlar ve durma koşulları.
Bir yönlendirmede sağlayıcının hostname’inin geçmesi, bir güven ilişkisinin kanıtıdır; sağlayıcıyı test etme izni değildir. Bir hipotez yalnızca sağlayıcıya veya gerçek kullanıcılara karşı işlem yaparak kanıtlanabiliyorsa durun; kapsam kararı veya müşteri kontrollü bir test ortamı talep edin.
Kurgusal bir kimlik sınırı incelemesi
Önceki analizin partners.meridian.example adresini onaylanmış güncel bir iş ortağı portalı olarak tanımladığını varsayalım. Halka açık rota kurumsal bir kimlik servisine yönlenir, ardından /auth/callback adresine döner ve yerel bir oturum oluşturur.
- Analist; ilk uygulama cookie’sini, yönlendirme zincirini, tam issuer’ı, client ID’yi, redirect URI’yi, scope’ları,
state,nonceve PKCE parametrelerini kaydeder. Normal müşteri giriş akışının ötesindeki sağlayıcı uç noktaları kurcalanmaz. - Müşteri dokümantasyonu portalın tek bir issuer’a güvendiğini ve iş ortağı üyeliğinin yerel olarak saklanması gerektiğini doğrular. İki sentetik iş ortağı kiracısı ve bir fatura yöneticisi hesabı temin edilir.
- Geçerli akış; issuer, callback, token, yerel hesap, kiracı ve oturum bileşenlerinin beklenen Kullanıcı A panelini üretebildiğini gösterir. Bu pozitif kontroldür.
- Giriş öncesi ve giriş sonrası cookie’lerin karşılaştırılması oturumun yenilendiğini (rotation) gösterir. Kimlik doğrulandıktan sonra giriş öncesi cookie tekrar yollandığında oturum anonim kalır. Session fixation desteklenmez.
- Uygulama harici kimliği değiştirilebilir e-posta adresiyle değil, issuer ve subject ikilisiyle bağlar. Onaylı alternatif test issuer’ı altında aynı sentetik e-postaya sahip ikinci bir kimlik, ilk yerel hesapla çakışmaz.
- Arayüz bir
workspaceparametresi alır; ancak API, geçerli kiracı üyeliğini yerel oturumdan türetir. Tarayıcı parametresini değiştirmek yalnızca görsel sunumu değiştirir; kiracılar arası nesnelere erişim engellenmeye devam eder. - Ancak kritik bir açık tespit edilir: Fatura yöneticisi rolü giriş sırasında oturuma kopyalanır ve müşteri yöneticileri rolü kaldırdıktan sonra oturum boyunca yeniden denetlenmez. Eski oturum, sekiz saatlik süresi dolana kadar sentetik bir faturayı onaylayabilir. Yeni bir oturum açıldığında ise yetki doğru şekilde engellenir.
- Analist; pozitif yönetici kontrolünü, kaldırılan rolün negatif beklentisini, eski ve yeni oturum karşılaştırmasını, sentetik onay olayını, zaman damgalarını ve temizleme adımlarını kaydeder. Bayat yetki penceresini kanıtlayan tek bir geri alınabilir nesne test edildikten sonra işlem durdurulur.
Buradaki bulgu “sağlayıcı bozuk bir token üretti” değildir. Sağlayıcı test kimliğini doğru bir şekilde doğrulamış ve tarif etmiştir. Hata, müşteri uygulamasının o yetkinin kaynağı değiştikten sonra bile yerel yetkiyi elinde tutmaya devam etmesidir. Dolayısıyla düzeltme adımı sağlayıcının giriş ekranında değil; oturum geçersiz kılma (session invalidation), hak yenileme (entitlement refresh) ve yetki iptali mimarisindedir.
Kanıt matrisi
| Gözlem veya test | Neyi destekler | Neyi kanıtlayamaz | Gereken sonraki adım |
|---|---|---|---|
| Halka açık rota bir kimlik sağlayıcıya yönleniyor | Bu tarayıcı akışında bir kimlik ilişkisinin var olduğunu | Sağlayıcı mülkiyetini, kiracı kapsamını veya yetkilendirmeyi | Tam issuer, client, callback ve müşteri onayını kaydedin |
| OIDC meta verisi uç noktaları ve anahtarları açıyor | Bir issuer için yayımlanmış protokol yapılandırmasını | Uygulamanın her alanı doğruladığını veya güvendiğini | Meta veriyi istemci davranışı ve yapılandırmasıyla karşılaştırın |
| Token imzası doğrulanıyor | Seçilen anahtar ve algoritma altında token bütünlüğünü | Güvenilen issuer’ı, hedeflenen audience’ı veya süjeyi | Eksiksiz uygulama kabul politikasını doğrulayın |
| ID Token e-posta, grup, kiracı ve rolleri içeriyor | Issuer’ın bu claim’leri beyan ettiğini | Hangi claim’lerin yerel kimlik veya yetki oluşturduğunu | Hesap bağlama ve rol dönüşümünü izleyin |
| Callback normal bir akışla başarılı tamamlanıyor | Pozitif tek bir kimlik doğrulama yolunun çalıştığını | Değiştirme, replay veya korelasyon hatasına direnci | Sınırlandırılmış negatif kontrolleri çalıştırın |
| Cookie güvenlik bayrakları tanımlanmış | Tarayıcı tarafında işleme kısıtlamalarının olduğunu | Sunucu iptalini, kiracı bağlamını veya güvenli logout’u | Yaşam döngüsü geçişleri boyunca oturum davranışını karşılaştırın |
| Farklı rol farklı bir navigasyon menüsü görüyor | Arayüzün role özel içerik sunduğunu | Sunucu tarafında işlev veya nesne yetkilendirmesini | Doğrudan onaylanmış API isteklerini ve etkilerini karşılaştırın |
| Çapraz kiracı isteği genel bir ret yanıtı dönüyor | Test edilen yolun bir kiracı sınırını uyguladığını | Tüm nesne sınıflarını veya alternatif rotaları | Körlemesine tarama yerine risk ve nesne sınıfına göre genişletin |
| Kaldırılan rol eski oturumda aktif kalmaya devam ediyor | Yerel yetkinin ölçülen süre boyunca kaynağını aştığını | Evrensel hesap ele geçirmeyi veya IdP arızasını | Süreyi, işlevleri, iptal davranışını ve etkiyi sınırlandırın |
| Logout tarayıcı cookie’sini temizliyor | İstemci tarafı oturum verisinin silindiğini | Sunucu tarafı geçersiz kılmayı veya genel SSO çıkışını | Eski cookie’yi güvenle yeniden kullanın ve çıkış alanlarını ayırın |
Savunma ekiplerine teslim edilecek çıktılar
Teslim edilecek rapor kimlik, uygulama ve platform ekiplerinin aynı sınırı görmesini sağlamalıdır:
Kimlik sözleşmesi. Issuer, client, callback, anahtar kaynağı, subject anahtarı, kabul edilen token türleri, audience, korelasyon kontrolleri ve yaşam döngüsü varsayımları.
Yetki dönüşüm haritası. Hesap, kiracı, rol, scope ve istisnai erişimi belirleyen harici claim’ler ve yerel kayıtlar. Çatışmalar ve öncelik kuralları açıkça belirtilmelidir.
Oturum yaşam döngüsü. Oluşturma, rotation, yenileme, süre aşımı, logout, iptal, rol değişikliği, kiracıdan çıkarılma ve dondurulma davranışları; muğlak etiketler yerine ölçülmüş zaman pencereleriyle verilmelidir.
İzin matrisi. Sentetik kimlikler, roller, kiracılar, nesneler, iş akışı durumları, beklenen sonuçlar, gözlemlenen sonuçlar ve kanıt referansları.
Reddedilen hipotezler. Başarıyla çalışan kontroller raporda yer almalıdır: Audience uyumsuzluğunun reddedildiği, giriş öncesi oturumun rotate edildiği, kiracılar arası okumaların başarısız olduğu, hesap kimliklerinin çakışmadığı. Bunlar test edilen sınırı tanımlar ve ekiplerin gelecekte aynı testleri mükerrer yapmasını önler.
Eyleme dönüştürülebilir bulgu. Hata veren en dar politika, uygulama sahibi, tekrarlanabilir kanıt, sınırlandırılmış etki, temizlik adımları ve hem pozitif hem negatif kontrolleri içeren bir yeniden test planı.
Seri, aktif testin nihayet başlayabileceği yerde sona eriyor
Bu seri basit bir iddiayla başladı: Dış çevre bir grafiktir ve port listesi bu grafiğin yalnızca tek bir görüntüsüdür. Her makale tehlikeli bir kestirmeyi ortadan kaldırdı:
- Şirket adı otomatik bir hedef listesine değil, bir tüzel kişilik grafiğine dönüştü.
- Domain ilişkisi varsayılan bir sahipliğe değil, ilişkilendirilmiş bir kanıta dönüştü.
- Üçüncü taraf bir platform sağlayıcıyı test etme iznine değil, müşteri kontrollü bir güven sınırına dönüştü.
- Pasif bir servis gözlemi bir zafiyet iddiasına değil, güncel bir uygulama modeline dönüştü.
- Kamusal bir giriş sayfası yetkilendirmenin anlaşıldığına dair bir yanılsamaya değil; bir kimlik, kiracı, rol ve oturum sözleşmesine dönüştü.
Test ekibi ancak şimdi istihbarattan uygulama hipotezlerine geçmeye hazırdır. Hangi organizasyonun bu yüzeye sahip olduğunu, hangi isim ve servislerin güncel olduğunu, hangi sağlayıcıların yetki taşıdığını, hangi uygulama iş akışlarının kritik olduğunu, hangi kimlik ve kiracıların onaylandığını ve hedeflenen meşru erişimi bir güvenlik zafiyetinden hangi kanıtın ayıracağını artık tam olarak bilir.
Daha sessiz ve metodolojik bir harici sızma testinin gerçek değeri buradadır. Pasif istihbarat aktif testin yerini almaz. Her aktif isteğin müşterinin gerçekten sahip olduğu bir sınıra ulaşmasını, uygulamanın yanıtlayabileceği mantıklı bir soru sormasını ve bir savunucunun gerçekten kullanabileceği kanıtlar üretmesini sağlar.
Bu teknik not ne kadar güncel?
En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.
Birincil kamu kayıtları kontrol edildi. Ortama özgü davranış, ayrıca yeniden üretilmedikçe iddianın dışındadır.