Pentest Kapsamını URL Listesinden Attack-Surface Graph'a Dönüştürme

Bir sızma testinin değeri çoğu zaman ilk gün, henüz tek bir istek gönderilmeden belirlenir: kapsamın nasıl tanımlandığı anda.

Yaygın senaryo şudur: müşteri birkaç URL ve bir giriş bilgisi paylaşır, tedarikçi bu listeyi test eder, rapor teslim edilir. Teknik olarak kusursuz görünen bu akış, en değerli güven sınırlarını sessizce kapsam dışında bırakabilir.

Bu yazıda, kapsamı düz bir URL listesinden bir saldırı-yüzeyi grafına (attack-surface graph) nasıl dönüştürdüğümüzü adım adım anlatıyoruz. Bu yaklaşım, aynı test bütçesinde neden daha fazla ve daha yüksek etkili bulgu ürettiğini de açıklıyor.

1. URL listesi neden yetersiz kalır?

Düz liste üç şeyi göstermez:

• Kim erişiyor — roller, kiracılar (tenant), servis kimlikleri. Aynı endpoint, farklı roller için farklı güven sınırı taşır.
• Ne akıyor — kimlik değişimi, ödeme, yetki devri gibi iş akışları. Bir BOLA zafiyeti tek endpoint'te değil, akışın bütününde ortaya çıkar.
• Nereye bağlanıyor — partner API'leri, webhook'lar, kimlik sağlayıcılar, mobil arka uçları. Saldırgan çoğu zaman doğrudan uygulamayı değil, bu güven köprülerini kullanır.

Sonuç: liste tabanlı test, her endpoint'i tek tek "yeşil" işaretleyip akıştaki zinciri kaçırabilir. Oysa kritik risk genellikle zincirlenmiş saldırı yolundan doğar.

2. Saldırı-yüzeyi grafı: düğümler ve kenarlar

Grafı iki temel öğeyle kurarız:

Bir zafiyet, tek bir düğümde değil, çoğu zaman bir kenardaki güven varsayımının yanlış olmasından çıkar: "bu isteği yalnız yetkili tenant gönderebilir" varsayımı gibi.

3. Grafı adım adım kurmak

Adım 1 — Giriş noktalarını çıkar

Yalnız verilen URL'ler değil; alt alan adları, API sürümleri, GraphQL/REST uçları, WebSocket kanalları, dosya yükleme yüzeyleri, e-posta/SMS callback'leri ve mobil arka uç uçları. OpenAPI veya trafik kaydından "shadow endpoint" farkları çıkarılır.

Adım 2 — Kimlikleri ve rolleri modelle

Her rol ayrı bir güven bağlamıdır. Çok kiracılı sistemlerde her tenant ayrı düğümdür. Servisten servise kimlikler (service-to-service token) ve delege yetkiler (OAuth 2.0 / PKCE, SCIM) de modele girer.

Adım 3 — Güven sınırlarını işaretle

İki düğüm arasında güvenin "verildiği" her yer bir sınırdır: tarayıcı ↔ backend, uygulama ↔ partner API, on-prem ↔ bulut kimlik. Kritik sınırlar kırmızıyla işaretlenir; test önceliği buradan başlar.

Adım 4 — İş akışlarını kenar olarak ekle

Kimlik değişimi, hesap kurtarma, yüksek riskli işlem onayı, ödeme/iade, yetki devri. Bu akışlar endpoint listesinde görünmese de saldırının asıl hedefidir.

4. Kapsamı iş sonucundan geriye kur

Grafı kurduktan sonra kapsamı belirleyen soru URL sayısı değildir:

Cevap "başka bir kiracının ödeme verisine erişim" ise, testin merkezine tenant izolasyonu ve nesne yetkilendirme akışları alınır; ilgili düğüm ve kenarlar önceliklenir. Kapsam, listeden değil, korunması gereken sonuçtan türetilir.

5. Sık kaçırılan düğümler

1. 1Legacy admin host — ana uygulamadan ayrı, eski bir yönetim alanından yapılan kritik yetki değişiklikleri.
2. 2Partner/webhook güven köprüleri — imza doğrulaması zayıf callback'ler (replay ve canonical body).
3. 3Mobil arka uç — web'den farklı, daha eski güven varsayımları taşıyan API sürümleri.
4. 4Kimlik sağlayıcı sınırı — SAML imza kapsamı, OIDC dynamic client registration.
5. 5Servisten servise kimlikler — mikroservisler arası aşırı geniş token yetki yayılımı.

6. Graftan test planına

Her kritik kenar için üç şey tanımlanır: test edilecek güven varsayımı, başarı kriteri (hangi iş sonucu kanıtlanırsa bulgu geçerli) ve gerekli rol/kimlikler. Böylece test, "endpoint tarama" değil, "graf üzerinde saldırı yolu doğrulama" hâline gelir.

Özet

URL listesi bir başlangıç girdisidir, kapsam değil. Kapsamı varlık, rol, kiracı, entegrasyon ve güven sınırlarından oluşan bir grafa dönüştürmek; aynı bütçeyle daha fazla kritik bulgu, daha net iş etkisi ve daha uygulanabilir düzeltme üretir.

Ürününüzün kapsamını bu grafla birlikte çıkarmak isterseniz, 25 dakikalık bir kapsam görüşmesiyle başlayabiliriz.