Sunucu URL Güvenliği: Dış Bağlantı Özelliğini SSRF Riskinden Korumak

Önce gerçekten hangi adreslere ihtiyaç olduğunu belirleyin

Özellik yalnızca belirli bir tedarikçinin katalog dosyasını okuyacaksa bütün internete açık bir adres alanı gerekmeyebilir. Kullanıcıdan tam bağlantı almak yerine tanımlı sağlayıcı ve ürün kimliği seçtirmek daha dar bir tasarım olabilir. İş ihtiyacını sınırlamak, sonradan çok karmaşık filtrelerle bütün olasılıkları engellemeye çalışmaktan farklıdır.

OWASP SSRF rehberi, bilinen güvenilir hedeflerle çalışılan durumları herhangi bir dış hedefin gerektiği durumlardan ayırır. Uygulama kontrollerinin yanında ağ katmanında erişimi sınırlamayı da önerir. [1] Bu nedenle yalnızca adresin geçerli görünmesini kontrol etmek, sunucunun gitmesine izin verilen yerleri tanımlamanın yerine geçmez.

Yönlendirme yeni bir hedef kararıdır

İlk adres uygun görünürken yanıt başka bir adrese yönlendirebilir. İstemcinin bu yönlendirmeleri otomatik izleyip izlemediği bilinmelidir. Gerekmiyorsa kapatmak, gerekiyorsa her yeni hedefi aynı kurallarla değerlendirmek gerekir. Alan adının çözümlendiği adresler ve bağlantının gerçekten ulaştığı hedef de güvenlik incelemesinin parçasıdır. [1]

Varsayımsal bir katalog aracı, satıcının verdiği görsel bağlantısını indirsin. Ürünün fotoğrafı yerine iç sistemlere erişmeye çalışan bir hedef kabul edilmemelidir. Burada amaç saldırı adımlarını öğretmek değil, uygulamanın dış dosya alma yetkisinin sınırlarını ürün gereksinimine çevirmektir. Savunma testleri yalnızca yetkili deneme ortamında yürütülmelidir.

İç ağa erişimi özellikten bağımsız sınırlayın

Görsel indiren işçinin müşteri veritabanına veya yönetim servislerine erişmesi gerçekten gerekli mi? Ağ sınırları, bir uygulama kontrolü aksadığında etkiyi azaltmak için değerlendirilebilir. Dış içerik işleme bileşeninin geniş yönetici kimlikleri taşıması da gerekmeyebilir. Görev başına dar erişim seçin.

HTTP istemcisinin çerez, kimlik bilgisi veya iç başlıkları yeni hedefe taşımadığını doğrulayın. Dış yanıtı kullanıcıya aynen döndürmek yerine yalnızca gereken sonucu üretin. Hata mesajı iç ağ bilgilerini veya gizli değerleri açıklamamalıdır. Bu kontroller, güvenli çıktı üretimi ve dosya işleme kontrolleriyle birlikte ele alınmalıdır.

Örnek savunma kabul tablosu

Tablo tam sızma testi değildir; projenin risklerine göre genişletilecek başlangıçtır. İzin listesi kullanılan yerlerde benzer isimlerin veya beklenmeyen alt alanların otomatik kabul edilmediği kontrol edilsin. Güvenlik ekibinin bulgusu, yalnızca “adres geçersiz” mesajıyla kapatılmasın; hangi katmanda engellendiği görülebilsin.

Sınırları teslim dosyasına yazın

İzin verilen protokoller, hedefler, bağlantı süresi ve dosya boyutu belgelenmelidir. Yeniden denemelerin de aynı kuralları kullandığını test edin. Bir hata sonrasında daha geniş erişime sahip yedek yolun çalışması, asıl korumayı etkisizleştirebilir. Operatörün manuel yeniden denemesi de kontrol dışında kalmamalıdır.

Canlı izleme için reddedilen istek türleri ve kaynak kullanımı takip edilebilir; tam hassas adresler veya belirteçler gereksiz loglanmasın. Yeni sağlayıcı eklendiğinde kim onay verecek ve hangi testler yeniden çalışacak, belirli olsun. Böylece bağlantıdan dosya alma özelliği, unutulmuş ve sınırsız bir sunucu yetkisi olarak büyümez.

Sık sorulan sorular

HTTPS kullanmak SSRF riskini giderir mi?

Hayır. Şifreli bağlantı, hedefin iş açısından izinli olduğunu göstermez. Hedef doğrulama, ağ sınırı ve istemci davranışı ayrıca değerlendirilmelidir.

Adresi bir düzenli ifadeyle kontrol etmek yeterli mi?

Karmaşık URL davranışları için buna güvenmeyin. Uygun ayrıştırıcılar, açık hedef politikası ve katmanlı kontroller birlikte kullanılmalıdır. [1]