Web vekil aracıyla trafik inceleme; yetki ve kapsam

Tarayıcı sunucuyla doğrudan konuşurken içeride ne olup bittiğini göremezsin. Vekil araç (proxy) tarayıcı ile sunucu arasına girer ve her isteği, her başlığı, her çerezi gözünün önüne serer. Bir önceki derste çıkardığın rapor şablonunun tekrar üretme adımlarını da bu araçla yakalarsın. Bu derste iki ücretsiz aracı temel alacaksın: Burp Suite'in Community sürümü ve ZAP (Zed Attack Proxy).

Önce vekilin nasıl araya girdiğini ve bir isteği nasıl durdurup değiştirdiğini göreceksin. Sonra Repeater ile aynı isteği tekrar göndermeyi, ardından vekil olmadan curl ile aynı işi yapmayı öğreneceksin. Testin yasal kapsamını çıkardıktan sonra şifreli trafiğin nasıl okunduğunu ve test bitince neyi temizleyeceğini göreceksin.

Vekil, tarayıcının bütün trafiğini kendi üzerinden geçirir. Tarayıcı isteği sunucuya değil vekile yollar, vekil isteği sunucuya iletir, yanıtı geri taşır. Burp Suite kurulunca kendi tarayıcısını getirir ve bu tarayıcı vekile bağlı gelir; ayar yapman gerekmez.

Şifreli trafik için gereken sertifika ayarı da bu tarayıcıda hazırdır; nasıl çalıştığını dersin son bölümünde göreceksin. Kendi tarayıcını kullanmak istersen onu vekile yönlendirirsin.

Burp'ün öntanımlı dinleyicisi döngü arayüzünde, yani 127.0.0.1 adresinin 8080 numaralı kapısındadır. ZAP'ta da akış aynıdır; Manual Explore ekranından vekile bağlı bir tarayıcı açarsın. Vekil araya girince isteği bekletebilir, değiştirebilir ve aynı isteği tekrar gönderebilir. Bu üç yetenek testin bütün temelini kurar: durdur, değiştir, gönder.

Vekil aracın işi girdiyi keşfetmek değil, girdiyi görünür kılmaktır. Bir form gönderildiğinde tarayıcı yalnız görünen değeri yollamaz; gizli alanlar, ek başlıklar ve çerezler de gider. Vekil olmadan bu ek veri hiç görünmez.

Test eden kişi bir alanı değiştirip aynı isteği tekrar gönderdiğinde sunucunun nasıl tepki verdiğini ölçer. Bu döngü, kod yazmadan sunucunun girdiye ne kadar güvendiğini test etmenin en hızlı yoludur. Vekil ayrıca her isteği bir geçmiş listesinde tutar. Saatler sonra hangi isteği hangi sırayla gönderdiğini bu listeden okur, raporun tekrar üretme adımlarını buradan çıkarırsın.

İlk yetenek isteği durdurmaktır. Burp'te Proxy sekmesindeki Intercept düğmesini açarsın. Bundan sonra tarayıcıdan çıkan her istek vekilde bekler.

İsteği okur, dilersen bir alanını değiştirir, sonra Forward ile sunucuya yollarsın. İsteğin sunucuya hiç ulaşmasını istemezsen Drop dersin. ZAP'ta aynı işi break (durdurma) düğmeleriyle yaparsın.

Klasik bir örnek şudur: bir alışveriş sepetinde ürünü sepete eklerken isteği durdurur, fiyat alanını 1 yapar ve Forward dersin. Sunucu fiyatı kendisi doğrulamıyorsa ürün bir liraya sepete düşer. Deneme, güven sınırının nerede geçildiğini canlı olarak gösterir: fiyat tarayıcıda hesaplanıp gönderiliyorsa, sunucu ona güvenmemelidir. Bu tür denemeleri yalnız kendi lab ortamında ya da yazılı iznin olan bir hedefte yaparsın.

GET /api/gonderiler/55087 HTTP/1.1
Host: portal.altaykargo.example
Cookie: oturum=Ab3f...
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{"gonderi": 55087, "sahip": "musteri-a", "durum": "dağıtımda"}

Yakalanan isteği satır satır oku. İlk satır yöntemi ve yolu verir: GET ile 55087 numaralı gönderi isteniyor. Host satırı hedef sunucuyu, Cookie satırı oturumu taşır; sunucu seni bu çerezden tanır.

Yanıtın ilk satırındaki 200, isteğin kabul edildiğini söyler. Gövdedeki sahip alanı kaydın sana ait olduğunu gösterir.

Şimdi erişim denetimini sınarsın. İsteği yeniden durdurur, yol içindeki numarayı başka bir numarayla değiştirir, oturum çerezini olduğu gibi bırakırsın. Değişen tek şey numaradır.

Yanıt başka bir müşterinin kaydını dönerse sunucu numarayı sorgusuz kabul ediyor demektir; sorgu, kaydın sahibinin oturumdaki kullanıcı olup olmadığını hiç sormamıştır. Doğru kurulmuş bir sunucu bu isteğe 404 ya da 403 döner. Bu basit deneme, kod okumadan bir nesne düzeyi yetki atlaması (IDOR) bulgusunu ortaya çıkarır.

İkinci yetenek aynı isteği tekrar tekrar göndermektir. Her seferinde isteği durdurmak yorucudur. Burp'te ilgi çekici bir isteğe sağ tıklar ve Send to Repeater dersin.

İstek kendi sekmesine taşınır. Orada Send düğmesiyle isteği yollar, yanıtı görür, bir değeri değiştirip yeniden yollarsın. Repeater her denemeyi bir geçmişte tutar; oklarla ileri geri gezinip hangi girdinin hangi yanıtı verdiğini karşılaştırırsın.

ZAP'ta aynı işi Requester eklentisi ya da Manual Request Editor yapar. Bu araç, güven sınırını sınamanın en verimli yoludur. Gönderi numarasını 55087, 55088, 55121 diye değiştirip her yanıtı görürsün; sunucunun hangi numaralarda başka müşterinin kaydını döndürdüğünü böyle bulursun.

Yanıtları karşılaştırırken küçük farklar önem taşır. Bir yanıt 200, öbürü 403 dönüyorsa aradaki fark sunucunun yetki kararıdır. Yanıtların boyutu ya da içeriği değişiyorsa bu da bir ipucudur. Burp'te iki yanıtı seçip Send to Comparer dersin; araç iki metni yan yana koyar ve farkları vurgular.

Bir değerin nasıl kodlandığını çözmek istersen Send to Decoder ile Base64, URL ya da onaltılık kodlamayı açar ya da uygularsın. Bu araçların hepsi tek bir amaca hizmet eder: sunucunun girdiye verdiği tepkiyi ölçmek. Ölçüm ne kadar düzenliyse bulgu da o kadar sağlam olur.

Bir isteği tekrarlamak için her zaman grafik arayüz gerekmez. curl, HTTP isteğini komut satırından kuran bir araçtır; vekil olmadan da HTTP'yi elle görmene yarar. Başlık eklemek için -H, çerez göndermek için -b, yöntemi değiştirmek için -X kullanırsın. Yanıt başlıklarını görmek için -i, giden isteği de görmek için -v eklersin.

curl betiğe kolayca girer; Burp'ün Repeater sekmesinde denediğin isteği bir betikte otomatikleştirmek istediğinde de curl'e dökersin. Çoğu vekilde, yakaladığın isteği doğrudan curl komutu olarak da kopyalarsın. Aşağıda aynı gönderi kaydı iki kez isteniyor: önce oturum çereziyle, sonra çerezsiz.

$ curl -i -b "oturum=Ab3f" https://portal.altaykargo.example/api/gonderiler/55087
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{"gonderi": 55087, "sahip": "musteri-a", "durum": "dağıtımda"}

$ curl -i https://portal.altaykargo.example/api/gonderiler/55087
HTTP/1.1 401 Unauthorized
Content-Type: application/json

{"hata": "oturum gerekli"}

İlk komutta -i bayrağı yanıt başlıklarını da ekrana yazar; durum kodunu görmek için bunu hep eklersin. -b bayrağı çerezi gönderir; oturum değerini vekilden ya da tarayıcının geliştirici araçlarından kopyalarsın. Yanıt 200 ve kaydın sahibi musteri-a, yani sensin.

İkinci komutta çerez yok ve sunucu 401 döndürüyor. Bu sonuç kimlik doğrulamanın çalıştığını gösterir, ama yetkilendirme hakkında bir şey söylemez.

Asıl soru, aynı çerezle başkasına ait bir numarayı istediğinde ne olduğudur. Savunma tarafı da bu denemeleri görebilir. Aynı oturumdan art arda farklı numaralara gelen ve 200 alan istekler, sunucu günlüğünde bir IDOR taramasının tipik izidir. Numaraları tahmin edilemez kimliklerle değiştirmek taramayı zorlaştırır, ama asıl düzeltme her istekte sahipliği denetlemektir.

Vekil bir değişikliği tek tuşla yapar; bu yüzden yetkisi olmayan biri elinde aynı araçla çok hızlı zarar verir. Aracın gücü, testin sınırını daha da önemli kılar. Web testine özgü kapsam üç şeyi netleştirir. Birincisi hedef alan adları ve alt alan adlarıdır.

Joker karakterle yazılan bir kayıt bile hangi alt alanların gerçekten dahil olduğunu netleştirmez, liste açık yazılır. İkincisi üçüncü taraf bütünleşmelerdir: ödeme sağlayıcı, harita servisi, analiz betiği genelde kapsam dışıdır, çünkü onlar başka bir şirkete aittir. Üçüncüsü yasak tekniklerdir. Tek bir isteği elle değiştirmek çoğu kapsamda izinlidir; otomatik taramayı saatlerce koşturup hizmete yük bindirmek genelde yasaktır.

Yetkisiz sisteme dokunmanın yasal bir karşılığı da vardır. Türk Ceza Kanunu'nun 243. maddesi, bir bilişim sistemine hukuka aykırı girmeyi ya da orada kalmayı suç sayar.

244. madde ise sistemin işleyişini engellemeyi, verileri bozmayı ya da değiştirmeyi cezalandırır. Yetkili bir sızma testi bu maddelerin dışında kalır, çünkü sistem sahibinin yazılı izni ve tanımlı bir kapsamı vardır. İzin belgesi ve kapsam listesi, testi meşru kılan asıl dayanaktır.

Kapsam dışına çıkan bir istek, teknik olarak kolay olsa da hukuki olarak izinsiz erişim sayılabilir. Bu yüzden aracın kapsam süzgecini de ayarlarsın.

Araçlar kapsamı ayarda da destekler. Burp'te Target sekmesindeki bir düğüme ya da geçmişteki bir isteğe sağ tıklayıp Add to scope dersin. Burp bu sırada kapsam dışı öğeleri geçmişe göndermeyi bırakmak isteyip istemediğini sorar; evet dersen kapsam dışı trafik geçmişi doldurmaz.

HTTP geçmişini ve site haritasını da Show only in-scope items süzgeciyle daraltırsın. Kapsam belgesindeki alan adı listesini araca aynen geçirirsin; belgede olmayan bir adı kendi tahminine göre eklemezsin. Kapsamı aracın içine yazmak, yorgun olduğun saatte bile seni listedeki hedeflerde tutar.

ZAP'ta her uygulama için bir Context tanımlar ve onu kapsama eklersin. ZAP'ın modları bu noktada kritik olur. Safe modda tehlikeli sayılan hiçbir işlem yapılamaz. Protected modda tehlikeli işlemleri yalnız kapsamdaki adreslerde yapabilirsin; kapsam dışında örümcek (spider), aktif tarama, durdurma ve istek tekrarı engellenir.

Standard mod hiçbir şeyi kısıtlamaz. ATTACK modu ise kapsamda keşfedilen her yeni düğümü hemen aktif taramaya alır. Yeni başlarken Protected modu seçmek, yanlışlıkla kapsam dışı bir hedefe dokunmanı engeller. Hangi modda çalıştığını test notlarına da yazarsın, çünkü aktif taramanın hangi adreslere gidebildiğini o belirler.

Şimdiye kadar Burp'ün kendi tarayıcısını kullandın ve şifreli trafik sorun çıkarmadı. Kendi tarayıcını vekile bağladığında durum değişir. HTTPS bağlantısı uçtan uca şifreli olduğu için vekil içeriği okuyamaz sanılır.

Vekil bunu bir ara sertifikayla çözer. Kurulunca kendine özgü bir sertifika yetkilisi (CA) üretir. Bu sertifikayı tarayıcına güvenilir olarak tanıttığında, vekil her sunucu için anlık bir sertifika üretip trafiği kendi üzerinden çözebilir.

Kendi tarayıcın için sertifikayı Burp'ten dışa aktarıp tarayıcının güvenilir kök yetkilileri listesine eklersin; Burp bu sertifikayı http://burpsuite adresinden de indirtir. ZAP'ın kök sertifikası da aynı biçimde tarayıcıya kurulur. Sertifikayı kurmadan HTTPS trafiğini “şifreli, bakamam” diye geçmek en sık yapılan başlangıç hatasıdır.

Test bittiğinde iki şeyi temizlersin. Birincisi vekil geçmişidir. Geçmişte biriken kayıtlar hassas veri taşır: parola, oturum çerezi, kişisel bilgi, bazen başka müşterilerin kayıtları. Bu geçmiş silinir ya da şifreli saklanır.

Raporda kanıt olarak gereken istekler ayıklanır, içlerindeki çerez ve kişisel veri maskelenir. Kapsam belgesi neyin test edileceğini yazar, ama topladığın kanıtı nasıl koruyacağını çoğu zaman yazmaz; bu senin sorumluluğundadır.

İkincisi kök sertifikadır. Test tarayıcısına kurduğun sertifikayı kaldırırsın ya da o tarayıcı profilini tümüyle silersin. Testte açtığın oturumlardan çıkış yapar, test hesaplarını sistem sahibine geri bildirirsin.

Sonraki modüllerde bu vekili sürekli kullanacaksın. Erişim denetimi modülünde az önce denediğin numara değiştirme deneyini rollere ve yöntemlere genişleteceksin. Enjeksiyon modülünde ise yakaladığın isteğin bir alanına zararsız bir sınama girdisi ekleyip sunucunun yanıtını Repeater'da izleyeceksin.

Bugün öğrendiğin akış, yani durdur, değiştir, gönder ve tekrar et, o denemelerin hepsinin temelini kurar. Kapsam ve kanıt kuralları da orada geçerli kalır: yalnız yetkili ve kapsam içi hedefe dokunur, topladığın veriyi test sonunda korursun.