Güven sınırı ve tehdit modeli

Her web isteği bir sınırı geçer. Dışarıdan gelen veri, senin denetlemediğin taraftan senin denetlediğin tarafa girer. Saldırıların çoğu tam bu geçişte olur: sunucu, sınırın öbür yanından gelen bir değere sorgusuz güvenir.

Tehdit modelleme (threat modeling) bu geçişleri kod yazılmadan önce bulmanın yoludur. OWASP Top 10:2025'teki güvensiz tasarım kategorisi (A06) de ekiplerden tam olarak bunu ister. Bu derste önce güven sınırını tanıyacaksın.

Sonra dört temel soruyla bir modelin iskeletini kuracak ve Altay Kargo portalının veri akış şemasını çizeceksin. Ardından STRIDE ile her akışta neyin ters gidebileceğini soracaksın. En son tehditleri önceliklendirip her birine bir kontrol eşleyeceksin.

Güven sınırı, bir sistemde denetimin değiştiği çizgidir. Sınırın bir yanında veri ya da isteğin sahibi sensin, öbür yanında başkası.

Tarayıcıdaki JavaScript kullanıcının elindedir; kullanıcı onu değiştirir, kapatır, hatta hiç çalıştırmaz. Sunucudaki kod ise senin elindedir. İkisi arasındaki çizgi bir güven sınırıdır. Sınırı geçen her veriyi karşı tarafta yeniden doğrularsın.

Tarayıcıdaki form denetimi kullanıcının işini kolaylaştırır, ama güvenlik getirmez; aynı denetim sunucuda bir kez daha yapılır. Bunu unutmak, bir sonraki modülde göreceğin bozuk erişim denetiminin de kök nedenidir. İstekte gelen müşteri numarasını ya da rol alanını doğrulamadan kabul eden sunucu, sınırı kendi eliyle kaldırmış olur.

Güven sınırı yalnız tarayıcı ile sunucu arasında olmaz. Uygulama başka bir servisi çağırdığında, iki sunucu arasında da yeni bir sınır doğar. Bir ödeme servisi başka bir şirkete aitse, ondan gelen yanıt da dışarıdan gelen veri sayılır ve doğrulanır.

Bir yönetim panelinin normal kullanıcı panelinden ayrı bir sunucuda çalışması da aynı mantıktan gelir: iki panel arasına ayrı bir sınır konur, biri ele geçse bile öbürü etkilenmez. Mikroservis mimarisinde sınır sayısı hızla artar. Tek bir sipariş isteği kimlik, stok, ödeme ve bildirim servislerinden geçebilir.

Her geçiş ayrı bir soru doğurur: bu servis öbürünün söylediğine neden güvensin? Sınırı çizmek, hangi tarafın verisine ne kadar güveneceğine karar vermektir.

Şemadaki ilk durak tarayıcıdır ve tamamen kullanıcının elindedir; içindeki hiçbir değere güvenilmez. DNS ile güvenlik duvarı ağın sınırını çizer, ama isteğin içeriğini okumaz. Asıl güven sınırı web sunucusunda geçilir: istek burada ilk kez uygulama koduna girer ve işlenir. Veritabanı ise en içteki katmandır, sunucunun ürettiği sorguya güvenir.

Saldırgan yalnız ilk durağı, yani tarayıcıyı, doğrudan denetler. Geri kalan her durak onun elinden çıkar; sunucu bu yüzden hiçbir alanı, hiçbir başlığı, hiçbir çerezi sorgusuz kabul etmez.

Sınırı geçen veriyi doğrulamadan güvenilir tarafa almanın bir adı var. MITRE bu hatayı CWE-501, güven sınırı ihlali (trust boundary violation) olarak tanımlar. Tanıma göre uygulama güvenilir ve güvenilmeyen veriyi aynı veri yapısında karıştırır.

Klasik örnek, kullanıcı adını istekten alıp doğrulamadan oturum nesnesine yazmaktır. Oturum sunucu tarafında durduğu için geliştirici ona güvenir. Oysa içine dışarıdan gelen, henüz doğrulanmamış bir değer girmiştir.

Başka bir dosyadaki kod “oturumda ne yazıyorsa odur” diye düşünür ve yetki kararını bu değere dayandırır. OWASP Top 10:2025, CWE-501'i A06 güvensiz tasarım kategorisinde listeler. Hata tek bir satırda değil, verinin nereden gelip nereye aktığına dair bir tasarım kararında doğar. Aşağıdaki sadeleştirilmiş kod bu durumu gösteriyor.

// giris.js (sadeleştirilmiş)
1  oturum.kullanici = istek.govde.kullanici   // parola denetiminden önce yazılıyor
2  if (!parolaDogru(istek.govde)) return hata(401)
3  ...
4  // yonetim.js
5  if (oturum.kullanici === "admin") return paneliGoster()

Birinci satır, istekten gelen değeri parola denetiminden önce oturuma yazar. İkinci satırda parola yanlışsa işlem durur, ama değer oturumda kalmıştır. Beşinci satır ise oturumdaki adı sorgusuz kabul eder. Oturum saklandığı sürece yanlış parolayla yapılmış bir deneme bile sonraki isteklerde yönetici gibi görünebilir.

Düzeltme sırayı ve kaynağı değiştirir. Oturuma yalnız doğrulama başarılı olduktan sonra yazarsın. Yazdığın değer de formdan değil, veritabanından okunan kullanıcı kaydından gelir.

Kod incelemesinde bu hatayı tek bir soruyla ararsın: istekten gelen bir değer, doğrulanmadan güvenilir bir depoya yazılıyor mu? Tehdit modelinde ise oturum deposunu güvenilir tarafa, istek gövdesini güvenilmeyen tarafa çizersin. Aradaki her ok bir doğrulama adımı olur.

Güven sınırını bulduktan sonra sıradaki soru şudur: o sınırda neler ters gidebilir? Tehdit modellemede yaygın kabul gören dört soru bu işi sadeleştirir. Adam Shostack'in yaygınlaştırdığı ve Tehdit Modelleme Manifestosu'nun benimsediği sorular şunlardır: Ne inşa ediyoruz, neler ters gidebilir, bunun için ne yapacağız, iyi bir iş çıkardık mı. Manifesto ilk soruyu “ne üzerinde çalışıyoruz” diye sorar; anlam aynıdır.

Sorular sırayla sorulur, atlanmaz. Birinci soru sistemi tarif eder, ikincisi tehdidi bulur, üçüncüsü önlemi seçer, dördüncüsü sonucu sınar. Sırayı atlayan ekip, henüz tarif edilmemiş bir sistem için önlem yazmaya kalkar.

İlk soruyu cevaplamak için üç unsuru yazarsın: varlık, saldırgan ve giriş noktası. Varlık korunması gereken şeydir: müşteri verisi, oturum kimliği, ödeme bilgisi. Saldırgan varlığa ulaşmak isteyen taraftır; iç kullanıcı, eski çalışan ya da internetteki herkes olabilir.

Giriş noktası saldırganın sisteme dokunduğu yerdir: bir form alanı, bir API ucu, bir dosya yükleme kutusu. Bu üçlüyü çıkarmadan ikinci soruya, yani nelerin ters gidebileceğine geçemezsin. Listeyi yazarken iç kullanıcıyı unutma.

Kargo şirketinde bir çağrı merkezi çalışanı da müşteri adreslerine erişir. Onun hesabı ele geçerse saldırgan artık dışarıda değil, içeridedir.

Birinci soruyu cevaplamanın en yaygın aracı veri akış şemasıdır (DFD, data flow diagram). Şema beş öğeden kurulur. Dış varlık, senin denetlemediğin bir aktördür: müşteri, kurye, ödeme sağlayıcısı. Süreç, veriyi işleyen koddur: web uygulaması, API.

Veri deposu, verinin durduğu yerdir: veritabanı, dosya deposu, önbellek. Veri akışı, iki öğe arasında hareket eden veridir ve bir okla çizilir. Güven sınırı ise kesikli bir çizgidir.

Bir akış bu çizgiyi kestiği anda orada bir tehdit sorusu doğar. Şemanın güzel olması gerekmez. Bir beyaz tahta çizimi ya da düz metin yeterlidir, yeter ki her akışın yönü ve sınırları doğru olsun.

Altay Kargo portalı: veri akış şeması (düz metin)

[Müşteri tarayıcısı] --(1) takip no + oturum çerezi--> (Portal uygulaması)
- - - - - Sınır A: internet | şirket - - - - -
(Portal uygulaması)  --(2) SQL sorgusu-->              [[Gönderi veritabanı]]
- - - - - Sınır B: uygulama | veri katmanı - - - - -
(Portal uygulaması)  --(3) ödeme isteği-->             [Ödeme sağlayıcısı]
[Ödeme sağlayıcısı]  --(4) "ödendi" bildirimi-->       (Portal uygulaması)
- - - - - Sınır C: şirket | üçüncü taraf - - - - -
[Kurye uygulaması]   --(5) teslim fotoğrafı-->         (Yükleme servisi)
(Yükleme servisi)    --(6) dosya-->                    [[Nesne deposu]]

[ ] dış varlık   ( ) süreç   [[ ]] veri deposu   --> veri akışı

Birinci akış internetten gelir ve Sınır A'yı keser. Takip numarası da oturum çerezi de kullanıcının elindedir, ikisi de doğrulanır.

İkinci akış uygulamadan veritabanına iner. Veritabanı sorguya güvenir, bu yüzden sorguyu parametreli kurmak Sınır B'nin kontrolüdür. Üçüncü ve dördüncü akışlar Sınır C'yi iki yönde keser.

Dördüncü akış en çok atlanan akıştır. Ödeme sağlayıcısından gelen bildirim de dışarıdan gelen veridir. Portal bildirimin imzasını doğrular ve tutarı kendi sipariş kaydıyla karşılaştırır. Bunu yapmazsa portala herkes “ödendi” diyebilir.

Beşinci ve altıncı akışlar yeni eklenen kurye özelliğidir ve kendi giriş noktasını getirir. Üçüncü taraf entegrasyonları ve servisler çoğaldıkça sınır sayısı da artar. Her yeni ok, modelde yeni bir satır demektir.

İkinci soru en zor olanıdır, çünkü boş bir sayfaya bakıp tehdit düşünmek kolay değildir. STRIDE bu işi altı başlığa böler. Her harf bir tehdit türünü ve o türün bozduğu güvenlik özelliğini temsil eder. Kimlik sahteciliği (Spoofing) kimlik doğrulamayı bozar.

Kurcalama (Tampering) bütünlüğü bozar. İnkâr (Repudiation) hesap verebilirliği bozar; kullanıcı bir işlemi yaptığını reddeder ve sistem aksini kanıtlayamaz. Bilgi ifşası (Information disclosure) gizliliği bozar. Hizmet engelleme (Denial of service) erişilebilirliği bozar.

Yetki yükseltme (Elevation of privilege) yetkilendirmeyi bozar. Şemadaki her öğeye ve her akışa bu soruları sorarsın. Aşağıdaki tablo her harfi Altay Kargo'dan bir örnekle eşliyor.

Harf  Tehdit              Bozduğu özellik     Altay Kargo örneği
S     Kimlik sahteciliği  kimlik doğrulama    çalınan oturum çereziyle müşteri gibi davranmak
T     Kurcalama           bütünlük            istekteki ağırlığı değiştirip ücreti düşürmek
R     İnkâr               hesap verebilirlik  iade onayını "ben vermedim" diye reddetmek, kayıt yok
I     Bilgi ifşası        gizlilik            başka müşterinin adresini okumak
D     Hizmet engelleme    erişilebilirlik     takip ucuna saniyede binlerce istek
E     Yetki yükseltme     yetkilendirme       müşteri hesabıyla kurye paneline girmek

Her öğeye altı sorunun hepsini sormak zorunda değilsin. Yaygın bir kısayol, öğe türüne göre ilgili harfleri seçmektir. Dış varlıklar için kimlik sahteciliği ve inkâr sorulur, çünkü dış varlığın kim olduğu ve ne yaptığı asıl sorudur. Süreçler altı tehdide de açıktır.

Veri depoları için kurcalama, bilgi ifşası ve hizmet engelleme sorulur; depo bir denetim kaydı tutuyorsa inkâr da eklenir. Veri akışları için de kurcalama, bilgi ifşası ve hizmet engelleme sorulur. Bu yönteme öğe başına STRIDE (STRIDE-per-element) denir. Listenin dışında kalan bir tehdit aklına gelirse onu da yazarsın.

Şimdi dördüncü akışa öğe başına STRIDE uygula. Akış olduğu için kurcalama, bilgi ifşası ve hizmet engelleme sorulur. Bildirimi karşılayan süreç için kimlik sahteciliği de eklenir. Kimlik sahteciliği: biri kendini ödeme sağlayıcısı gibi gösterip sahte bildirim yollayabilir mi?

Kurcalama: yolda tutar alanı değişebilir mi? Bilgi ifşası: bildirimde gereksiz kart verisi var mı, bu veri günlüğe yazılıyor mu? Hizmet engelleme: bildirim ucu binlerce istekle dolarsa gerçek ödemeler işlenebilir mi? Her soru ya “risk yok, çünkü” diye başlayan bir gerekçeyle kapanır ya da tehdit listesine bir satır olarak girer.

İkinci soruda takılırsan CAPEC'e (Common Attack Pattern Enumeration and Classification) bakarsın. MITRE'nin bu kataloğu bilinen saldırı kalıplarını numaralar. CAPEC-66 SQL enjeksiyonu, CAPEC-62 siteler arası istek sahteciliği, CAPEC-593 oturum ele geçirme, CAPEC-162 ise gizli alanları kurcalamadır.

STRIDE sana tehdidin türünü söyler, CAPEC o türün sahada nasıl göründüğünü. Her kalıbın sayfasında ön koşullar, önlemler ve ilişkili zayıflıklar yazar. Böylece “neler ters gidebilir” sorusundan “bunun için ne yapacağız” sorusuna geçerken elinde somut bir önlem listesi olur.

Üçüncü soruya geçmeden tehditleri sıralarsın, çünkü hepsini aynı anda kapatamazsın. En sade yöntem iki soru sormaktır: bu tehdidin gerçekleşme olasılığı ne kadar, gerçekleşirse etkisi ne kadar? İkisine yüksek, orta ya da düşük dersin ve öncelik bu ikisinin birleşiminden çıkar. Bir sonraki derste aynı fikrin puanlı biçimini, OWASP Risk Rating yöntemini ve CVSS'i göreceksin.

Tehdit modelinde amaç hassas bir puan değil, doğru sıralamadır. Sıralamayı yaparken tahminini de yazarsın: “ödeme bildirimi ucu internete açık, imza yok, olasılık yüksek” gibi. Böylece biri itiraz ettiğinde tartışma sayı üzerinden değil, gerekçe üzerinden yürür.

#  Tehdit (STRIDE)                           Olasılık  Etki    Kontrol
1  Sahte ödeme bildirimi (S)                 yüksek    yüksek  imza ve zaman damgası doğrulaması
2  Başka müşterinin gönderisini okuma (I)    yüksek    orta    sorguda sahiplik koşulu
3  Teslim fotoğrafı yerine zararlı dosya (T) orta      yüksek  tür ve boyut denetimi, ayrı depo
4  Takip ucuna istek yağmuru (D)             orta      orta    hız sınırı, önbellek
5  İade onayının inkârı (R)                  düşük     orta    değiştirilemez işlem kaydı

Tablonun her satırı bir tehdidi somut bir kontrole bağlar. Birinci satırdaki imza doğrulaması, bildirimin gerçekten sağlayıcıdan geldiğini kanıtlar.

İkinci satırdaki sahiplik koşulu, erişim denetimi modülünde ayrıntısıyla göreceğin düzeltmedir. Bu tabloyu bir araçta tutmak istersen OWASP Threat Dragon'u kullanabilirsin. Ücretsiz ve açık kaynaklı bu uygulama masaüstünde ya da kendi sunucunda çalışır.

Şemayı aktör, süreç, depo, akış ve güven sınırı öğeleriyle çizersin. Bir öğeye STRIDE, LINDDUN ya da CIA gibi bir yönteme göre tehdit eklersin; araç bazı tehditleri kurallarla kendisi de önerir. Model bir JSON dosyası olarak kaydedilir.

{
  "name": "Ödeme bildirimi ucu",
  "threats": [
    {
      "title": "Sahte ödeme bildirimi",
      "type": "Spoofing",
      "severity": "High",
      "status": "Open",
      "mitigation": "İmza ve zaman damgasını doğrula, tutarı sipariş kaydıyla karşılaştır"
    }
  ]
}

Kayıtta her tehdidin başlığı, STRIDE türü, önem derecesi, durumu ve önlemi durur. Durum alanı modelin yaşayıp yaşamadığını gösterir. “Open” bir tehdit henüz kapatılmamıştır, “Mitigated” ise kapatılmıştır. JSON dosyasını kodun yanında sürüm denetiminde tutarsan model de kodla birlikte değişir.

Yeni bir özellik için açılan çekme isteğinde (pull request) modeldeki değişikliği de görürsün. İnceleme yapan kişi “bu özellik yeni bir akış ekliyor, modelde neden yok?” diye sorabilir. Bu soru, en sık yapılan hatayı yakalar: modeli bir kere yapıp bırakmak.

Yeni bir özellik yeni bir giriş noktası, çoğu zaman yeni bir güven sınırı açar. Dosya yükleme eklenince model güncellenmezse, en tehlikeli sınır tehdit listesinde hiç görünmez. Model, kod değiştikçe yeniden gözden geçirilen yaşayan bir belgedir.