Bu bölümde, sunucu taraflı istek sahteciliğinin ne olduğunu açıklayacak, yaygın örneklerini tanımlayacak ve çeşitli SSRF zafiyetlerini nasıl bulabileceğinizi ve faydalanabileceğinizi açıklayacağız.
SSRF Nedir?
Sunucu taraflı istek sahteciliği (Server side request forgery) veya SSRF olarak da bilinir, bir saldırganın sunucu tarafındaki uygulamayı istenmeyen bir konuma istek yapmaya zorlayan bir web güvenlik zafiyetidir.
Tipik bir SSRF saldırısında, saldırgan sunucunun kuruluşun altyapısında yalnızca iç hizmetlere bağlantı yapmasına neden olabilir. Diğer durumlarda, sunucuyu keyfi dış sistemlere bağlaması ve yetkilendirme kimlik bilgileri gibi hassas verilerin sızmasına neden olabilir.
Laboratuvarlar
Eğer SSRF zafiyetlerinin temel kavramlarına aşina iseniz ve gerçekçi, kasıtlı olarak savunmasız hedefleri üzerinde bunları istismar etmek isterseniz, bu konudaki tüm laboratuvarlara konu altındaki postlardan ulaşabilirsiniz.
SSRF saldırılarının etkisi nedir?
Başarılı bir SSRF saldırısı genellikle yetkisiz işlemlere veya kuruluş içindeki verilere izinsiz erişime yol açabilir. Bu, savunmasız uygulama içinde veya uygulamanın iletişim kurabildiği diğer arka plandaki sistemlerde gerçekleşebilir. Bazı durumlarda, SSRF zafiyeti saldırganın keyfi komut yürütmesine izin verebilir.
Dış üçüncü taraf sistemlerine bağlantılar sağlayan bir SSRF istismarı, savunmasız uygulamayı barındıran kuruluştan kaynaklanıyormuş gibi görünen kötü niyetli ileri saldırılara yol açabilir.
Yaygın SSRF saldırıları
SSRF saldırıları genellikle güven ilişkilerini istismar ederek savunmasız uygulamadan saldırıyı tırmandırarak izinsiz işlemler gerçekleştirir. Bu güven ilişkileri, sunucuyla ilgili olabileceği gibi aynı kuruluş içindeki diğer arka plandaki sistemlerle de ilgili olabilir.
Sunucuya yönelik SSRF saldırıları
Sunucuya yönelik bir SSRF saldırısında, saldırgan uygulamayı loopback ağ arabirimini kullanarak uygulamayı barındıran sunucuya geri bir HTTP isteği yapması için yönlendirir. Bu genellikle 127.0.0.1 gibi bir IP adresi (loopback adaptörüne işaret eden bir rezerve IP adresi) veya localhost gibi bir ana bilgisayar adıyla bir URL sağlamayı içerir.
Örneğin, bir alışveriş uygulamasını düşünelim. Kullanıcının belirli bir mağazadaki bir ürünün stok durumunu görmesine izin verir. Stok bilgisini sağlamak için, uygulama, ilgili arka plandaki REST API uç noktasına ilişkin URL'yi ön uç HTTP isteği aracılığıyla geçirerek çeşitli arka plandaki API'ları sorgular. Bu nedenle, bir kullanıcı bir ürünün stok durumunu görüntülerken, tarayıcısı şu şekilde bir istek yapar:''
Bu, sunucunun belirtilen URL'ye istek yapmasına, stok durumunu almasına ve bunu kullanıcıya geri döndürmesine neden olur.
Bu durumda, bir saldırgan isteği sunucunun kendine ait yerel bir URL'yi belirtmek üzere değiştirebilir. Örneğin:
Burada, sunucu / admin URL'nin içeriğini alacak ve kullanıcıya geri dönecektir.
Tabii ki, saldırgan doğrudan /admin URL'sini ziyaret edebilir. Ancak yönetici işlevselliği genellikle yalnızca uygun kimlik doğrulaması yapılmış kullanıcılara erişilebilir. Bu nedenle, URL'yi doğrudan ziyaret eden bir saldırgan ilgi çekici bir şey görmeyecektir. Ancak, /admin URL'sine yapılan istek doğrudan yerel makineden geldiğinde, normal erişim kontrolleri atlanır. İsteğin güvenilir bir konumdan geldiği izlenimi yaratıldığı için uygulama yönetici işlevselliğine tam erişim sağlar.
Uygulamalar neden bu şekilde davranır ve yerel makineden gelen isteklere dolaylı olarak güvenir? Bunun çeşitli nedenleri olabilir:
-Erişim kontrolü , uygulama sunucusunun önünde bulunan farklı bir bileşende uygulanmış olabilir. Sunucuya geri bir bağlantı yapıldığında, kontrol atlanır.
-Olası bir sıkıntılı durumda, uygulama oturum açma olmaksızın yerel makineden gelen herhangi bir kullanıcıya yönetici erişimine izin verebilir. Bu, bir yöneticinin kimlik bilgilerini kaybettikleri durumda sistemini kurtarması için bir yol sağlar. Burada varsayım, sadece tamamen güvenilir bir kullanıcının doğrudan sunucudan geleceğidir.
-Yönetici arayüzü, ana uygulamadan farklı bir bağlantı noktasında dinleyebilir ve bu nedenle doğrudan kullanıcılar tarafından erişilemez olabilir.
Bu tür güven ilişkileri, yerel makineden kaynaklanan isteklerin normal isteklerden farklı şekilde işlendiği durumlar, SSRF'yi kritik bir zafiyete dönüştüren şeylerdir.
Diğer arka uç sistemlere karşı SSRF saldırıları
Sunucu taraflı istek sahteciliği sıkça ortaya çıkan bir başka güven ilişkisi türü, uygulama sunucusunun doğrudan kullanıcılar tarafından erişilemeyen diğer arka uç sistemlerle etkileşimde bulunabilmesidir. Bu sistemler genellikle yönlendirilemeyen özel IP adreslerine sahiptir. Arka uç sistemler genellikle ağ topolojisi tarafından korunduğu için genellikle daha zayıf bir güvenlik durumuna sahiptir. Birçok durumda, iç arka uç sistemler, bu sistemlerle etkileşimde bulunabilen herhangi biri tarafından kimlik doğrulama olmaksızın erişilebilen hassas işlevselliği içerir.
Önceki örnekte, arka uç URL'si https://192.168.0.68/admin üzerinde bir yönetici arayüzü olduğunu varsayalım. Burada, bir saldırgan SSRF zafiyetini sömürerek yönetici arayüzüne erişebilir. Bunun için aşağıdaki isteği göndermesi yeterlidir:
SSRF Nedir?
Tipik bir SSRF saldırısında, saldırgan sunucunun kuruluşun altyapısında yalnızca iç hizmetlere bağlantı yapmasına neden olabilir. Diğer durumlarda, sunucuyu keyfi dış sistemlere bağlaması ve yetkilendirme kimlik bilgileri gibi hassas verilerin sızmasına neden olabilir.
Laboratuvarlar
Eğer SSRF zafiyetlerinin temel kavramlarına aşina iseniz ve gerçekçi, kasıtlı olarak savunmasız hedefleri üzerinde bunları istismar etmek isterseniz, bu konudaki tüm laboratuvarlara konu altındaki postlardan ulaşabilirsiniz.
SSRF saldırılarının etkisi nedir?
Başarılı bir SSRF saldırısı genellikle yetkisiz işlemlere veya kuruluş içindeki verilere izinsiz erişime yol açabilir. Bu, savunmasız uygulama içinde veya uygulamanın iletişim kurabildiği diğer arka plandaki sistemlerde gerçekleşebilir. Bazı durumlarda, SSRF zafiyeti saldırganın keyfi komut yürütmesine izin verebilir.
Dış üçüncü taraf sistemlerine bağlantılar sağlayan bir SSRF istismarı, savunmasız uygulamayı barındıran kuruluştan kaynaklanıyormuş gibi görünen kötü niyetli ileri saldırılara yol açabilir.
Yaygın SSRF saldırıları
SSRF saldırıları genellikle güven ilişkilerini istismar ederek savunmasız uygulamadan saldırıyı tırmandırarak izinsiz işlemler gerçekleştirir. Bu güven ilişkileri, sunucuyla ilgili olabileceği gibi aynı kuruluş içindeki diğer arka plandaki sistemlerle de ilgili olabilir.
Sunucuya yönelik SSRF saldırıları
Sunucuya yönelik bir SSRF saldırısında, saldırgan uygulamayı loopback ağ arabirimini kullanarak uygulamayı barındıran sunucuya geri bir HTTP isteği yapması için yönlendirir. Bu genellikle 127.0.0.1 gibi bir IP adresi (loopback adaptörüne işaret eden bir rezerve IP adresi) veya localhost gibi bir ana bilgisayar adıyla bir URL sağlamayı içerir.
Örneğin, bir alışveriş uygulamasını düşünelim. Kullanıcının belirli bir mağazadaki bir ürünün stok durumunu görmesine izin verir. Stok bilgisini sağlamak için, uygulama, ilgili arka plandaki REST API uç noktasına ilişkin URL'yi ön uç HTTP isteği aracılığıyla geçirerek çeşitli arka plandaki API'ları sorgular. Bu nedenle, bir kullanıcı bir ürünün stok durumunu görüntülerken, tarayıcısı şu şekilde bir istek yapar:''
Kod:
POST /product/stock HTTP/1.0Content-Type: application/x-www-form-urlencodedContent-Length: 118stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1Bu, sunucunun belirtilen URL'ye istek yapmasına, stok durumunu almasına ve bunu kullanıcıya geri döndürmesine neden olur.
Bu durumda, bir saldırgan isteği sunucunun kendine ait yerel bir URL'yi belirtmek üzere değiştirebilir. Örneğin:
Kod:
POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118 stockApi=http://localhost/adminBurada, sunucu / admin URL'nin içeriğini alacak ve kullanıcıya geri dönecektir.
Tabii ki, saldırgan doğrudan /admin URL'sini ziyaret edebilir. Ancak yönetici işlevselliği genellikle yalnızca uygun kimlik doğrulaması yapılmış kullanıcılara erişilebilir. Bu nedenle, URL'yi doğrudan ziyaret eden bir saldırgan ilgi çekici bir şey görmeyecektir. Ancak, /admin URL'sine yapılan istek doğrudan yerel makineden geldiğinde, normal erişim kontrolleri atlanır. İsteğin güvenilir bir konumdan geldiği izlenimi yaratıldığı için uygulama yönetici işlevselliğine tam erişim sağlar.
Uygulamalar neden bu şekilde davranır ve yerel makineden gelen isteklere dolaylı olarak güvenir? Bunun çeşitli nedenleri olabilir:
-Erişim kontrolü , uygulama sunucusunun önünde bulunan farklı bir bileşende uygulanmış olabilir. Sunucuya geri bir bağlantı yapıldığında, kontrol atlanır.
-Olası bir sıkıntılı durumda, uygulama oturum açma olmaksızın yerel makineden gelen herhangi bir kullanıcıya yönetici erişimine izin verebilir. Bu, bir yöneticinin kimlik bilgilerini kaybettikleri durumda sistemini kurtarması için bir yol sağlar. Burada varsayım, sadece tamamen güvenilir bir kullanıcının doğrudan sunucudan geleceğidir.
-Yönetici arayüzü, ana uygulamadan farklı bir bağlantı noktasında dinleyebilir ve bu nedenle doğrudan kullanıcılar tarafından erişilemez olabilir.
Bu tür güven ilişkileri, yerel makineden kaynaklanan isteklerin normal isteklerden farklı şekilde işlendiği durumlar, SSRF'yi kritik bir zafiyete dönüştüren şeylerdir.
Diğer arka uç sistemlere karşı SSRF saldırıları
Sunucu taraflı istek sahteciliği sıkça ortaya çıkan bir başka güven ilişkisi türü, uygulama sunucusunun doğrudan kullanıcılar tarafından erişilemeyen diğer arka uç sistemlerle etkileşimde bulunabilmesidir. Bu sistemler genellikle yönlendirilemeyen özel IP adreslerine sahiptir. Arka uç sistemler genellikle ağ topolojisi tarafından korunduğu için genellikle daha zayıf bir güvenlik durumuna sahiptir. Birçok durumda, iç arka uç sistemler, bu sistemlerle etkileşimde bulunabilen herhangi biri tarafından kimlik doğrulama olmaksızın erişilebilen hassas işlevselliği içerir.
Önceki örnekte, arka uç URL'si https://192.168.0.68/admin üzerinde bir yönetici arayüzü olduğunu varsayalım. Burada, bir saldırgan SSRF zafiyetini sömürerek yönetici arayüzüne erişebilir. Bunun için aşağıdaki isteği göndermesi yeterlidir:
Kod:
POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118 stockApi=http://192.168.0.68/adminYaygın SSRF savunmalarını aşma
Kötü niyetli istismarı önlemek için SSRF davranışını içeren uygulamaların sıkça görülmesi ve genellikle bu savunmaların byplasslanması yaygındır.
Kara liste tabanlı giriş filtreleriyle SSRF
Bazı uygulamalar, 127.0.0.1 ve localhost gibi ana bilgisayar adlarını veya /admin gibi hassas URL'leri içeren girişleri engeller. Bu durumda, çeşitli teknikler kullanarak genellikle filtreyi atlayabilirsiniz:
- 2130706433, 017700000001 veya 127.1 gibi 127.0.0.1'in alternatif IP temsili kullanmak.
- 127.0.0.1'e çözümlenen kendi alan adınızı kaydetmek. Bu amaçla spoofed.burpcollaborator.net'i kullanabilirsiniz.
- Engellenen dizeleri URL kodlama veya büyük-küçük harf değişimiyle gizlemek.
- Hedef URL'ye yönlendiren sonradan kontrolünüzde olan bir URL sağlamak. Farklı yönlendirme kodlarını ve hedef URL için farklı protokolleri deneyin. Örneğin, yönlendirme sırasında http: URL'den https: URL'ye geçişin bazı anti-SSRF filtrelerini atlattığı gösterilmiştir.
Beyaz liste tabanlı giriş filtreleriyle SSRF
Bazı uygulamalar, yalnızca belirli değerlerle eşleşen, başlayan veya içeren girişlere izin verir. Bu durumda, bazen URL ayrıştırma işlemindeki tutarsızlıkları sömürerek filtreyi atlatabilirsiniz.
URL spesifikasyonu, URL'lerin ad hoc ayrıştırılması ve doğrulanması sırasında gözden kaçırılma eğiliminde olan bir dizi özelliği içerir:
- @ karakterini kullanarak ana bilgisayar adından önce URL'ye kimlik bilgileri ekleyebilirsiniz. Örneğin: https://expected-host:fakepassword@evil-host
- # karakterini kullanarak bir URL parçacığı belirtebilirsiniz. Örneğin: https://evil-host#expected-host
-DNS adlandırma hiyerarşisinden yararlanarak, kontrolünüzde olan tam nitelikli bir DNS adına gerekli girişi yerleştirebilirsiniz. Örneğin: https://expected-host.evil-host
- URL'deki karakterleri URL kodlama yaparak URL ayrıştırma kodunu karıştırabilirsiniz. Bu, filtrelemeyi uygulayan kodun, arka plandaki HTTP isteğini gerçekleştiren kodun URL kodlu karakterleri farklı şekilde işlediği durumlarda özellikle kullanışlıdır. Ayrıca karakterleri çift kodlama yapmayı da deneyebilirsiniz; bazı sunucular, aldıkları girişi rekürsif olarak URL kod çözümleme işlemine tabi tutarlar, bu da daha fazla tutarsızlığa neden olabilir.
-Bu tekniklerin kombinasyonlarını birlikte kullanabilirsiniz.
Açık yönlendirmeler aracılığıyla SSRF filtrelerini bypasslama
Açık yönlendirme zafiyetini sömürerek her türlü filtre tabanlı savunmayı bazen bypasslamak mümkündür.
Önceki SSRF örneğinde, kullanıcı tarafından gönderilen URL'nin SSRF davranışının kötüye kullanılmasını önlemek için sıkı bir şekilde doğrulandığını varsayalım. Ancak, URL'lerine izin verilen uygulama, açık yönlendirme zafiyeti içerir. Arka uç HTTP isteği yapmak için kullanılan API yönlendirmeleri destekliyorsa, filtreyi karşılayan bir URL oluşturabilir ve istenen arka uç hedefine yönlendirilen bir istekte bulunabilirsiniz.
Örneğin, uygulama şu URL içeren bir açık yönlendirme zafiyetine sahip olduğunu varsayalım:
/product/nextProduct?currentProductId=6&path=evil-user.net - Ressources et information concernant evil user Resources and Information.
bu bir yönlendirmeye yol açıyor:
evil-user.net - Ressources et information concernant evil user Resources and Information.
evil-user.net réunit des informations et annonces. Nous espérons que vous y trouverez les informations que vous recherchez !
evil-user.net
Açık yönlendirme zafiyetinden yararlanarak URL filtresini atlayabilir ve SSRF zafiyetini aşağıdaki gibi sömürülebilirsiniz:
Kod:
POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118 stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/adminBu SSRF saldırısı, uygulamanın öncelikle sağlanan stockAPI URL'sinin izin verilen bir alan adında olduğunu doğruladığı için işe yarar. Uygulama daha sonra sağlanan URL'yi istemekte ve bu açık yönlendirmeyi tetiklemektedir. Yönlendirmeyi takip eder ve saldırganın seçtiği dahili URL'ye bir istekte bulunur.
Kör SSRF zafiyetleri
Kör SSRF zafiyetleri, bir uygulamanın sağlanan bir URL'ye arka uç HTTP isteği yapmasına neden olabilir, ancak arka uç isteğin yanıtı uygulamanın ön uç yanıtında dönmeyebilir.
Kör SSRF genellikle sömürülmesi zor olsa da bazen sunucuda veya diğer arka uç bileşenlerinde tam uzaktan kod yürütme gibi sonuçlar doğurabilir.
SSRF zafiyetleri için gizli saldırı yüzeyi bulma
Birçok sunucu taraflı istek sahtekarlığı zafiyeti nispeten kolayca fark edilebilir, çünkü uygulamanın normal trafiği, tam URL'leri içeren istek parametrelerini içerir. Diğer SSRF örnekleri ise daha zor bulunabilir.
Taleplerde Kısmi URL'ler
Bazı durumlarda, bir uygulama yalnızca bir ana bilgisayar adını veya URL yolunun bir kısmını istek parametrelerine yerleştirir. Gönderilen değer daha sonra sunucu tarafında talep edilen tam bir URL'ye dahil edilir. Değer, bir ana bilgisayar adı veya URL yolunun hemen tanınabilir olduğu durumlarda, olası saldırı yüzeyi açık olabilir. Ancak, tam SSRF olarak sömürülebilirlik sınırlı olabilir çünkü talep edilen tam URL'yi kontrol etmiyorsunuz.
Veri formatları içindeki URL'ler
Bazı uygulamalar, formatın veri ayrıştırıcısı tarafından talep edilebilecek URL'leri içermesine izin veren formatlarda veri iletmektedir. Bu durumun açık bir örneği, istemciden sunucuya yapılandırılmış verileri iletmek için geniş çapta kullanılan XML veri formatıdır. Bir uygulama XML formatında veri kabul eder ve ayrıştırırken XXE enjeksiyonuna açık hale gelebilir ve bunun sonucunda XXE üzerinden SSRF zafiyetine maruz kalabilir. XXE enjeksiyon zafiyetlerine daha detaylı bir şekilde bakacağımızda bunu daha ayrıntılı bir şekilde ele alacağız.
Referer headerı aracılığıyla SSRF
Bazı uygulamalar, ziyaretçileri takip eden sunucu tarafı analitik yazılımı kullanmaktadır. Bu yazılım genellikle isteklerdeki Referer headerını kaydeder, çünkü bu, gelen bağlantıları takip etmek için özellikle ilgi çekicidir. Sıklıkla analitik yazılım, Referer headerında görünen herhangi bir üçüncü taraf URL'sini ziyaret eder. Bu genellikle gelen bağlantılarda kullanılan çapa metnini içeren başvuran sitelerin içeriğini analiz etmek için yapılır. Sonuç olarak, Referer headerı, SSRF zafiyetleri için verimli bir saldırı yüzeyi oluşturur. Referer headerı içeren zafiyet örnekleri için Kör SSRF zafiyetlerine bakın.
Lab 1: Yerel sunucuya karşı Temel SSRF
Bu laboratuvarda, iç sistemden veri çeken bir stok kontrol özelliği bulunmaktadır.
Labı çözmek için, stok kontrol URL'sini http://localhost/admin adresindeki yönetici arayüzüne erişecek şekilde değiştirin ve kullanıcı carlos'u silin.
Lab Linki: Lab: Basic SSRF against the local server | Web Security Academy
Bu laboratuvarda, iç sistemden veri çeken bir stok kontrol özelliği bulunmaktadır.
Labı çözmek için, stok kontrol URL'sini http://localhost/admin adresindeki yönetici arayüzüne erişecek şekilde değiştirin ve kullanıcı carlos'u silin.
Lab Linki: Lab: Basic SSRF against the local server | Web Security Academy
Lab 2: Bir başka arka uç sisteme karşı Temel SSRF
Bu laboratuvarda, iç sistemden veri çeken bir stok kontrol özelliği bulunmaktadır.
Labı çözmek için, stok kontrol işlevselliğini kullanarak içerideki 192.168.0.X aralığını port 8080'deki bir yönetici arayüzü için tarayın, ardından bu arayüzü kullanarak kullanıcı carlos'u silin.
Lab Linki: Lab: Basic SSRF against another back-end system | Web Security Academy
Bu laboratuvarda, iç sistemden veri çeken bir stok kontrol özelliği bulunmaktadır.
Labı çözmek için, stok kontrol işlevselliğini kullanarak içerideki 192.168.0.X aralığını port 8080'deki bir yönetici arayüzü için tarayın, ardından bu arayüzü kullanarak kullanıcı carlos'u silin.
Lab Linki: Lab: Basic SSRF against another back-end system | Web Security Academy
Lab 3: Kara liste tabanlı giriş filtresiyle SSRF
Bu laboratuvarda, iç sistemden veri çeken bir stok kontrol özelliği bulunmaktadır.
Labı çözmek için, stok kontrol URL'sini http://localhost/admin adresindeki yönetici arayüzüne erişecek şekilde değiştirin ve kullanıcı carlos'u silin.
Geliştirici, bypasslamanız gereken iki zayıf anti-SSRF savunması dağıtmıştır.
Lab Linki: Lab: SSRF with blacklist-based input filter | Web Security Academy
Bu laboratuvarda, iç sistemden veri çeken bir stok kontrol özelliği bulunmaktadır.
Labı çözmek için, stok kontrol URL'sini http://localhost/admin adresindeki yönetici arayüzüne erişecek şekilde değiştirin ve kullanıcı carlos'u silin.
Geliştirici, bypasslamanız gereken iki zayıf anti-SSRF savunması dağıtmıştır.
Lab Linki: Lab: SSRF with blacklist-based input filter | Web Security Academy
Lab 4: Beyaz liste tabanlı giriş filtresiyle SSRF
Bu laboratuvarda, iç sistemden veri çeken bir stok kontrol özelliği bulunmaktadır.
Labı çözmek için, stok kontrol URL'sini http://localhost/admin adresindeki yönetici arayüzüne erişecek şekilde değiştirin ve kullanıcı carlos'u silin.
Geliştirici, bypasslamanız gereken bir anti-SSRF savunması dağıtmıştır.
Lab Linki: Lab: SSRF with whitelist-based input filter | Web Security Academy
Bu laboratuvarda, iç sistemden veri çeken bir stok kontrol özelliği bulunmaktadır.
Labı çözmek için, stok kontrol URL'sini http://localhost/admin adresindeki yönetici arayüzüne erişecek şekilde değiştirin ve kullanıcı carlos'u silin.
Geliştirici, bypasslamanız gereken bir anti-SSRF savunması dağıtmıştır.
Lab Linki: Lab: SSRF with whitelist-based input filter | Web Security Academy
Lab: 5 Açık yönlendirme zafiyeti sayesinde filtre bypasslama | SSRF
Bu laboratuvarda, iç sistemden veri çeken bir stok kontrol özelliği bulunmaktadır.
Labı çözmek için, stok kontrol URL'sini http://192.168.0.12:8080/admin adresindeki yönetici arayüzüne erişecek şekilde değiştirin ve kullanıcı carlos'u silin.
Stok kontrol işlevi yalnızca yerel uygulamaya erişime izin vermek için kısıtlanmıştır, bu nedenle öncelikle uygulamayı etkileyen bir açık yönlendirme bulmanız gerekecektir.
Lab Linki: Lab: SSRF with filter bypass via open redirection vulnerability | Web Security Academy
Bu laboratuvarda, iç sistemden veri çeken bir stok kontrol özelliği bulunmaktadır.
Labı çözmek için, stok kontrol URL'sini http://192.168.0.12:8080/admin adresindeki yönetici arayüzüne erişecek şekilde değiştirin ve kullanıcı carlos'u silin.
Stok kontrol işlevi yalnızca yerel uygulamaya erişime izin vermek için kısıtlanmıştır, bu nedenle öncelikle uygulamayı etkileyen bir açık yönlendirme bulmanız gerekecektir.
Lab Linki: Lab: SSRF with filter bypass via open redirection vulnerability | Web Security Academy
Moderatör tarafında düzenlendi:
