Neler Yeni

HTTP istek kaçakçılığı

Katılım
22 Nis 2020
Mesajlar
86
Tepkime puanı
23
Puanları
150
Merhabalar arkadaşlar.

Bugünkü yazımızda HTTP istek kaçakçılığının ne oldğunu ve ve ortak istek kaçakçılığı güvenlik açıklarının nasıl ortaya çıkabileceğini açıklayacağız. Yazıyı okuduktan sonra Fikir bildirmeyin unutmayın.
Başlıyoruz
HTTP istek kaçakçılığı nedir?

HTTP isteği kaçakçılığı,
bir web sitesinin bir veya daha fazla kullanıcıdan gelen HTTP isteklerinin dizilerini işleme biçimine müdahale etme tekniğidir. Talep kaçakçılığı güvenlik açıkları çoğu zaman kritik öneme sahiptir, bir saldırganın güvenlik kontrollerini atlamasına, hassas verilere yetkisiz erişim sağlamasına ve diğer uygulama kullanıcılarını doğrudan tehlikeye atmasına izin verir.
Bu gwvenlik açığı ilk olarak 2005 senesinde ortaya çıkmıştır.

vavvLA.png



Bir HTTP isteği kaçakçılığı saldırısında ne olur?

Bugünün web uygulamaları, kullanıcılar ve nihai uygulama mantığı arasında sık sık HTTP sunucu zincirleri kullanır. Kullanıcılar bir ön uç sunucuya istek gönderir (bazen yük dengeleyici veya ters proxy olarak adlandırılır) ve bu sunucu istekleri bir veya daha fazla arka uç sunucuya iletir. Bu tür mimari, günümüz bulut tabanlı uygulamalarda giderek yaygınlaşmaktadır ve bazı durumlarda kaçınılmazdır.

Ön uç sunucusu HTTP isteklerini bir arka uç (back-end) sunucusuna ilettiğinde, genellikle aynı arka uç ağ bağlantısı üzerinden birkaç istek gönderir, çünkü bu çok daha verimli ve daha performanslıdır. Protokol çok basittir: HTTP istekleri birbiri ardına gönderilir ve alıcı sunucu, bir isteğin nerede bitip bir sonrakinin başlayacağını belirlemek için HTTP istek başlıklarını ayrıştırır:

7BrrAP.png


Bu durumda, ön uç (front-end) ve arka uç (Back-end) sistemlerinin talepler arasındaki sınırlar üzerinde hemfikir olması çok önemlidir. Aksi takdirde, saldırgan ön uç (front-end) ve arka uç (back-end) sistemleri tarafından farklı şekilde yorumlanan belirsiz bir istek gönderebilir:

M133o2.png


Burada, saldırgan ön uç isteğinin bir kısmının bir sonraki isteğin başlangıcı olarak arka uç sunucu tarafından yorumlanmasına neden olur. Bir sonraki talebe etkin bir şekilde hazırlanmıştır ve bu nedenle talep edilen başvurunun işleme şeklini engelleyebilir. Bu bir istek kaçakçılığı saldırısıdır ve çok kötü sonuçlar doğurabilir.

HTTP isteği kaçakçılığı güvenlik açıkları nasıl ortaya çıkar?

Çoğu HTTP isteği kaçakçılığı güvenlik açığı ortaya çıkar, çünkü HTTP özelliği bir isteğin nerede biteceğini belirtmek için iki farklı yol sunar: Content-Length (İçerik uzunluğu) başlığı ve Transfer-Encoding (Aktarım Şifreleme) başlığı.

İçerik Uzunluğu başlığı basittir: mesaj gövdesinin bayt cinsinden uzunluğunu belirtir. Örneğin:

anbbGd.png


Aktarım Şifreleme başlığı, mesaj gövdesinin yığınlanmış kodlama kullandığını belirtmek için kullanılabilir. Bu, mesaj gövdesinin bir veya daha fazla veri parçası içerdiği anlamına gelir. Her bir yığın, bayt cinsinden yığın boyutundan (onaltılık olarak ifade edilir), ardından yeni bir satır ve ardından yığın içeriği oluşur. Mesaj, sıfır boyutta bir yığınla sonlandırılır. Örneğin:

QPoo2A.png


HTTP belirtimi, HTTP iletilerinin uzunluğunu belirlemek için iki farklı yöntem sağladığından, tek bir iletinin aynı anda birbirleriyle çakışacak şekilde her iki yöntemi de kullanması mümkündür. HTTP belirtimi, Content-Length ve Transfer-Encoding üstbilgileri varsa, Content-Length üstbilgisinin yoksayılması gerektiğini belirterek bu sorunu önlemeye çalışır. Bu, yalnızca tek bir sunucu çalışırken, iki veya daha fazla sunucu birlikte zincirlendiğinde belirsizliği önlemek için yeterli olabilir. Bu durumda, iki nedenden dolayı sorunlar ortaya çıkabilir:

1. Bazı sunucular isteklerde transfer-encoding başlığını desteklememektedir.
2. Transfer-encoding başlığını destekleyen bazı sunucular, başlık bir şekilde gizlenirse işlenmemesi için tetiklenebilir.
Ön uç ve arka uç sunucular (muhtemelen gizlenmiş) Aktarma Kodlaması başlığına göre farklı davranırlarsa, art arda gelen istekler arasındaki sınırlar konusunda anlaşmazlık içinde olabilirler;

HTTP isteği kaçakçılığı saldırısı nasıl gerçekleştirilir?

Talep kaçakçılığı saldırıları, hem Content-Length üstbilgisini hem de Transfer-Encoding üstbilgisini tek bir HTTP isteğine yerleştirmeyi ve bunları ön uç ve arka uç sunucuların isteği farklı şekilde işlemesi için değiştirmeyi içerir. Bunun yapılma şekli, iki sunucunun davranışına bağlıdır:

1. CL.TE: ön uç sunucu Content-Length üstbilgisini kullanır ve arka uç sunucusu Transfer-Encoding üstbilgisini kullanır.

2. TE.CL: ön uç sunucu Transfer-Encoding üstbilgisini kullanır ve arka uç sunucu Content-Length üstbilgisini kullanır.

3. TE.TE: ön uç ve arka uç sunucular her ikisi de aktarım şifreleme üstbilgisini destekler, ancak sunuculardan biri, üstbilgiyi bir şekilde gizleyerek işlememesine neden olabilir.

CL.TE güvenlik açıkları

Burada, ön uç sunucu Content-Length üstbilgisini kullanır ve arka uç sunucusu Transfer-Encoding üstbilgisini kullanır. Basit bir HTTP isteği kaçakçılık saldırısı gerçekleştirebiliriz:

XbrzL3.png


Ön uç sunucu Content-Length üstbilgisini işler ve istek gövdesinin KAÇAKLIĞIN sonuna kadar 13 bayt uzunluğunda olduğunu belirler. Bu istek, arka uç sunucuya iletilir.

Arka uç sunucu aktarım kodlama üstbilgisini işler ve bu nedenle ileti gövdesini yığın kodlamayı kullanarak değerlendirir. Sıfır uzunluğa sahip olduğu belirtilen ilk öbek işlenir ve bu nedenle isteği sonlandırma olarak kabul edilir. Aşağıdaki baytlar, SMUGGLED, işlenmeden bırakılır ve arka uç sunucu bunları sıradaki bir sonraki isteğin başlangıcı olarak değerlendirir.

Bu zafiyyete Ait Lab : lt;ahref= " " gt;Tıklayın lt;/a gt;

TE.CL güvenlik açıkları

Burada, ön uç sunucu aktarım kodlama üstbilgisini kullanır ve arka uç sunucu Content-Length üstbilgisini kullanır. Basit bir HTTP isteği kaçakçılık saldırısı gerçekleştirebiliriz:

p5pQzr.png


Ön uç sunucusu Aktarım Kodlaması başlığını işler ve bu nedenle ileti gövdesine yığın kodlama kullanıyormuş gibi davranır. Kaçakçılığın ardından hattın başlangıcına kadar, 8 bayt uzunluğa sahip ilk yığınını işler. Sıfır uzunluk olduğu belirtilen ikinci parçayı işler ve bu nedenle isteği sonlandırma olarak kabul edilir. Bu istek arka uç sunucuya iletilir.

Bu zafiyyete Ait Lab : lt;ahref= " " gt;Tıklayın lt;/a gt;

TE.TE davranışı: TE başlığını engelleme

Burada, ön uç ve arka uç sunucular her ikisi de aktarım kodlama üstbilgisini destekler, ancak sunuculardan biri, üstbilgiyi bir şekilde gizleyerek işlememesine neden olabilir.

Transfer Şifreleme başlığını gizlemenin potansiyel olarak sonsuz yolları vardır. Örneğin:

Xbrz45.png


Bu tekniklerin her biri, HTTP spesifikasyonundan ince bir ayrılma içerir. Bir protokol spesifikasyonu uygulayan gerçek dünya kodu nadiren mutlak bir kesinliğe bağlı kalır ve farklı uygulamaların spesifikasyondan farklı varyasyonları tolere etmesi yaygındır.
Bir TE.TE güvenlik açığını açığa çıkarmak için, diğer sunucu görmezden gelirken, ön uç veya arka uç sunuculardan yalnızca birinin işlemesi için Transfer Şifrelemesi başlığının bir çeşitlemesinin bulunması gerekir. Gizli Aktarım Kodlama başlığını işlememesi için tetiklenebilecek ön uç veya arka uç sunucu olmasına bağlı olarak, saldırının geri kalanı CL.TE veya TE.CL güvenlik açıkları ile aynı şekilde olacaktır.

Bu zafiyyete Ait Lab : lt;ahref= " " gt;Burada lt;/a gt;

HTTP isteği kaçakçılığı güvenlik açıkları nasıl önlenir

HTTP istek kaçakçılığı güvenlik açıkları, bir ön uç sunucusunun aynı ağ bağlantısı üzerinden bir arka uç sunucuya birden çok istek ilettiği durumlarda ortaya çıkar ve arka uç bağlantıları için kullanılan protokol iki sunucunun sınırlar arasında uyuşmaması riskini taşır. Oluşan HTTP isteği kaçakçılığı güvenlik açıklarını önlemenin bazı genel yolları şunlardır:

1. Arka uç bağlantılarının yeniden kullanılmasını engellmek gerekli, böylece her arka uç isteği ayrı bir ağ bağlantısı üzerinden gönderilir.
2. Arka uç bağlantıları için HTTP / 2 kullanmak gereklidir, çünkü bu protokol istekler arasındaki sınırlar hakkında belirsizliği önler.
3. Ön uç ve arka uç sunucular için tam olarak aynı web sunucusu yazılımını kullanmalıyız, böylece istekler arasındaki sınırları kabul ederler.

Bazı durumlarda, ön uç sunucunun belirsiz istekleri normalleştirmesini veya arka uç sunucunun belirsiz istekleri reddetmesini ve ağ bağlantısını kapatmasını sağlayarak güvenlik açıklarından kaçınılabilir. Bununla birlikte, bu yaklaşımlar yukarıda belirtilen genel azaltmalara göre potansiyel olarak hataya daha açıktır.

evvet Arkadaşlar. Bu yazımızı şimdi burada bitirmek gerekdir. İnşAllah en yakın sürede bu tür Zafiyyetlerin tesbit edilmesi ve Exploit edilmasi hakkında bir yazı gelecekdir.

Konu Hakkında yorumlarda fikir bildirmeyi unutmayın.

Saygılarla.
 

Konuyu görüntüleyen kullanıcılar

Üst