Geri çağırma URL'si nasıl SSRF saldırısına dönüşür?

Ödeme altyapısı, müşterisinin yazdığı adrese kendi ağının içinden bağlanır. Sunucu taraflı istek sahteciliği (SSRF) denen sınıfın tamamı bu cümlede duruyor, üstelik burada kaza yok: geri çağırma alanı belgelerde yazılı ve onu çeken işçinin başka işi yok.

Özelliği saldırıya çeviren şey, isteğin nereden çıktığı. Teslimat çevrenin içinden yapılır; dışarıdaki hiçbir tarayıcıda bulunmayan yönlendirme tablosunu ve dışa çıkış kimliğini kullanır. Birisi adres kaydeder, platform onun yerine oraya bağlanır — takvimle, tekrar denemeyle.

Tutan kontrol çözümlenmiş adresin üzerindedir. Soket açılmadan önce uygulanır ve yönlendirmeyle ikinci bir adres çıkarsa istek orada biter. Aşağısı, o kontrolün nerede durabileceği ve tuttuğunda karşı uçtaki satıcıya neye mal olduğu.

Webhook SSRF nedir?

İsteği sunucunuz yapar, hedefini saldırgan seçer — hata sınıfı bu. Üstelik seçimini, tam o iş için açılmış tek alandan yapıyor.

Tanıdık SSRF bulguları kimsenin kurmaya niyetlenmediği türden. PDF üreteci görsel adresini izler, avatar aktarıcısı kullanıcı adına adres çeker. Kimse yabancılara HTTP istemcisi vermek istememiştir ve bulgu sonradan gözden kaçmış bir şey olarak okunur. Webhook göndereni ise bilerek kurulur.

OWASP 2025'te kategoriyi taşıdı. SSRF'in 2021 listesinde A10 olarak kendi başlığı vardı; 2025 Top 10'da başlık olarak yok, CWE-918 ise A01 Broken Access Control altındaki dikkate değer zayıflıklar arasında duruyor.

Yeni yerleşim zararı eski addan daha iyi anlatıyor. İstek sahte değil: onu sizin altyapınız gönderdi ve ulaştığı yere, gönderen kim olduğu için ulaştı.

Ağdaki konum neden cevaptan değerli?

Cevap çoğu zaman saldırgana hiç ulaşmaz, saldırı yine de işler.

Teslimat işçisi durum kodunu okur ve gövdeyi atar. Panele hiçbir şey yansımaz, dolayısıyla adresi kaydeden taraf deneme başına tek bit öğrenir: bağlantı kabul edildi ya da edilmedi. Kör varyant budur; SSRF'i veri sızıntısı sanan ekipler onu bu yüzden hafife alır. Tekrarlanan tek bit, ağ haritası çıkarır.

Asıl varlık konum. Çevrenin içinde işçi, dışarıdan kimseye cevap vermek üzere kurulmamış makinelere ulaşabilir; bunların çoğu iç ağda olmanın kimlik doğrulama yerine geçtiği bir dönemden kalmadır. Çevrenin dışında ise platformun çıkış adresi, yalnızca sizden trafik almayı kabul etmiş bir iş ortağının izin listesinde oturuyor olabilir.

Ödeme altyapısını PDF üretecinin önüne geçiren şey tekrar merdiveni. Geri çekilme takvimiyle yeniden deneyen gönderen, tek kayıttan, başkasının ayakta tuttuğu altyapıda tekrar tekrar çalışan bir iş üretir.

Kontrol nereye konur?

Ad çözümlendikten sonra, bağlantı açılmadan önce. Çoğu HTTP istemci kütüphanesinde durması zor olan yer tam olarak orası.

Ham metin üzerindeki filtre her zaman önce yazılır, çünkü istek işleyicisinden çıkmadan yazılabilen tek filtre odur. Zekice bir kaçış yüzünden değil, yapısal olarak tutmaz: ad bir işaretçidir ve neyi gösterdiğine, adresi kaydeden kişinin yönetebildiği DNS kaydı karar verir. Metni okumak paketin nereye gideceği hakkında hiçbir şey söylemez. OWASP'ın önleme rehberi bunu yazıyor: uygulama, adın arkasındaki adresleri (A ve AAAA kayıtlarının ikisini de) alır ve adres kurallarını dönen sonuca uygular.

Naif sürüm bu tuhaflık yüzünden hâlâ yayımlanıyor. İstemci kütüphanesi URL alıp cevap döndürmek ister; sizin ihtiyaç duyduğunuz kanca ise onun kendi işi saydığı iki adımın arasındadır. Oraya ulaşmak, adı kendiniz çözümlemek ya da sokete kanca takmak demektir ve ikisi de form alanına yazılan düzenli ifadeden fazla iştir.

Kaydın kendisinde ise daha erken bir kapı var. Paymos'ta uç nokta URL'si HTTPS olmak zorunda; değilse oluşturma da güncelleme de reddedilir. Bu, adres doğrulamasının yerine geçmez, ondan önce gelir: şifresiz taşınan imzalı yük, henüz kaydedilmeden elenir.

Hangi adres aralıkları reddedilmeli?

Çoğu mühendisin ezberden yazdığından fazlası.

Loopback ve özel ağ blokları herkesin yazdığı iki satır. Link-local de oraya ait, çünkü bulut örneklerinin metadata servisi o aralıkta cevap verir ve oraya ulaşan kimlik bilgisini alır.

Atlanan ikisi ise o ezberden daha genç.

Paylaşımlı adres alanı, 100.64.0.0/10, RFC 6598 ile Nisan 2012'de operatör NAT'ı için ayrıldı ve RFC bunu özel adres alanından ayrı tutuyor, çünkü servis sağlayıcı ağlarına ait.

10. ve 192.168. kalıplarını arayan filtrenin bu aralık hakkında hiçbir fikri yoktur, üstelik geçerken özel blokların bir kısmını da atlar.

IPv6 benzersiz yerel adresler, fc00::/7, RFC 4193'ten geliyor; RFC onları genel internette yönlendirilmeyen, site gibi sınırlı bir alanın içinde yönlendirilen adresler olarak tanımlıyor.

Bu tarife uyan hedefe webhook gönderilmemeli; yalnızca IPv4 için yazılmış aralık listesi ise onlardan hiç söz etmez.

Paymos webhook teslimatında engellenen aralıkların tamamı yazının sonundaki tabloda. Adres aralık testinden geçmeden önce normalleştiriliyor, dolayısıyla IPv6'ya eşlenmiş IPv4 adresiyle yapılan klasik atlatma da çalışmıyor. Adres doğrulaması varsayılan olarak açık gelen bir ayar, yapısal bir özellik değil. İddiayı bu kadar dar tutmak işe yarıyor, çünkü dar iddia denetlenebilir.

Geçen bir kontrolü yönlendirme neden bozar?

Çünkü doğruladığınız adres, çektiğiniz adres olmaktan çıkar.

İşçi adı çözümler, genel adres alır, onaylar, bağlantıyı açar. Sunucu 302 ve yeni konumla cevap verir. HTTP istemcisi yönlendirmeleri izliyorsa — .NET'in HttpClient'ı da Python'ın requests'i de aksi söylenmedikçe izler — ikinci istek hiç kontrol edilmemiştir; kontrol, birincinin hayatında yaşanmış bir olaydı.

Önleme rehberi bunu tek cümlede kapatıyor: kullanılan web istemcisinde yönlendirme desteğini kapatın.

Kaba ve doğru. Geri çağırma alan uç noktanın onu ikinci adrese devretmek için hiçbir nedeni yok, adresini taşımış satıcı da yenisini kaydedebilir.

Aynı sorunun sessiz sürümü, hiçbir yönlendirme olmasa bile kontrolle bağlantı arasında durur: DNS cevabının ömrü vardır ve verdiğiniz onay, gördüğünüz cevap hakkındaydı. Paymos teslimatında bu boşluk kapalı, çünkü ad bir kez çözümleniyor, geçen ilk adres seçiliyor ve soket doğrudan o adrese açılıyor; kontrolle bağlantı arasında ikinci bir DNS sorgusu yok.

Reddedilen hedef gönderene ne kadara mal olmalı?

Hiç. Doğrulamayı geçemeyen hedef, hiçbir bağlantı denenmeden reddedilir; engellenen kayıt gönderenin dışa çıkış kapasitesinden bir şey götürmez.

İkinci yarı kaynak sınırları. Güvenilirlik işi gibi göründüğü için atlanır. Paymos webhook teslimatında güvenilirlik için kurulmuş; bu sınıfı da sınırlıyor:

• Deneme başına 10 saniye. Süre sınırı olmadan, el sıkışmaya cevap verip sonra susan hedef, başka bir şey pes edene kadar işçiyi tutar; bunlardan yeterince olunca kuyruk boşalmaz.
• On bir deneme olayı kapatır: ilk deneme ve on tekrar, bir dakikadan sekiz saate açılan aralarla, yaklaşık on altı saate yayılır. Tavansız tekrar, seçilmiş hedefe kendini yeniden yükleyen trafik kaynağı verirdi.
• Satıcı ortamı başına on uç nokta. Kayıt sınırı, tek hesapla sınırsız dışa çıkış payı arasında duran şeydir.

Bu denemeler olayı sınırlar, uç noktayı değil. Döngüsü tükenen olay başarısız işaretlenir, kayıt canlı kalır; bir gün boyunca kapalı kalan alıcı, yeniden oynatılabilir olaylara döner. Tekrarın alıcı tarafındaki karşılığı aynı webhookun iki kez gelmesi.

Bu savunma satıcıya neye mal olur?

Gerçek uç noktalar buna takılır ve takıldığında kontrol gibi değil, kesinti gibi görünür.

Geri çağırma adresi localhost'u ya da ofis ağındaki makineyi gösteremez, dolayısıyla yerel geliştirme işleyicinin önüne genel bir ad koyan tünel ister. Her entegrasyon bununla ilk öğleden sonra tanışıyor.

Yönlendirme izlenmediği için, kaydettiğiniz adresin son adres olması gerekiyor. Apex alan adından www'ye kanonik yönlendirme yapan uç nokta, ya da geçen yıl taşınmış ve hâlâ sıçratan bir yol, teslimatta düşer — aynı adres tarayıcıya tertemiz sayfa döndürürken. Geri çağırmanın önündeki link sarmalayıcıları ve kısaltıcılar da aynı sorunun başka kılığı.

İnce olanı yanlış adrese bakan DNS kaydı. Uç noktanın A kaydı, yönlendiricinin iç tarafta gösterdiği adresi taşıyorsa hedef engelli aralığa düşer ve binadan hiçbir şey çıkmaz.

Bunların hiçbiri kendini duyurmaz. Satıcı geri çağırma görmez ve webhooklar gelmiyor diye destek kaydı açar; önce işleyici ayıklanır, cevap ise kaydedilmiş URL'dedir.

Ödeme altyapısına bu konuda ne sorulmalı?

Kontrolün nerede çalıştığını sorun, diğer bütün cevaplar bundan çıkıyor.

Çözümlenmiş adresi doğrulayan sağlayıcı bunu sormadan söyler ve aralıkları sayar. Loopback ile özel bloklar listenin herkesin bildiği yarısı; paylaşımlı adres alanına ve IPv6 benzersiz yerel adreslere kadar uzanan cevap, eski bir kontrol listesini geri dönüştürmek yerine güncel RFC okuyan birinden gelmiştir. Otomatik yönlendirmelerin izlenip izlenmediğini sorun. Reddedilen hedefin, platformdaki diğer satıcıların teslimat kapasitesine ne yaptığını sorun.

Sonra sağlayıcının güvenlik sayfasını okuyun ve sayfanın, mühendisliğin bittiği yerde bittiğini kontrol edin. Savunmayı, onu uygulayan bileşenden geniş anlatan sayfa başka bir risktir — ve dışarıdan denetleyebileceğiniz risk odur.

Bu işin öbür ucundaysanız, yani göndereni siz kuruyorsanız, zorluk şurada: kontrol çalışırken sesini çıkarmaz, devreye girdiğinde de hatadan ayırt edilmez. Reddi, çarptığı kuralı adıyla söyleyecek biçimde kurun ve bunu yalnızca kendi kaydınıza değil, API cevabında satıcıya da söyleyin.