- Katılım
- 2 Ocak 2026
- Mesajlar
- 20
- Tepkime puanı
- 46
- Puan
- 13
Derinlemesine Race Condition ve HTTP Smuggling Zafiyeti ve HTTP Protokol Versiyon Etkileri
İki zafiyette isteklerin ön-arka uçta farklı yorumlanmasından kaynaklanır ve yetkisiz erişim, veri sızıntısı yaratır. İkisi de isteklerin sırası veya aynı anda işlenmesiyle ilgili hatalardan çıkar. Race Conditionda işlemler çakışır ve veri bozulur, smugglingde ise istekler birleşir veya karışır. Her ikisi de sunucunun paralel işlem kapasitesinin yetersiz kalmasından kaynaklanır. İkisinde de atomic işlemler, kilit mekanizmaları ve rate limit şart. Smuggling için HTTP parsing standartlaştırması, race için senkronizasyon gerekli.
Layer → Race Condition uygulama katmanında (veritabanı, session, dosya erişimi) oluşur. Aynı kaynağa birden fazla istek giderken oluşan sıra karmaşası sebep olur. Genel bir eşzamanlılık problemidir ve yazılım hataları gibi web dışında da olur. HTTP Request Smuggling ağ ve protokol katmanında, genellikle reverse Proxy (WAF, Load Balancer) ile backend arasında HTTP parsing farkından dolayı meydana gelir. Web’e özgüdür.
Tetikleme → Race Condition eş zamanlı isteklerle tetiklenir, zaman göstergeleri önemlidir. HTTP Request Smuggiling özel header manipülasyonuyla (CL.TE — TE.CL) çakışmasıyla istekler birleştirilerek tetiklenir.
Etkiler ve İstismar → Race Condition veri manipülasyonuna (bakiye sıfırlama), limit bypass gibi sebep olur. Uygulama mantığını bozar. HTTP Request Smuggling’in istek zehirleme, cache poisining, WAF bypass gibi etkileri vardır. Daha çok zincirleme saldırılara (XSS-SQLi) yol açar.
Bulma Zorluğu → Race Condition yüksek trafik ve özel zamanlama ister, false positive çoktur. HTTP Request Smuggling de ise Proxy-Backend uyumsuzluğu aranır, daha statiktir ama versiyona bağımlıdır.
→Rate Limit kısıtlaması sebebiyle 403 aldığını düşünüyorsan; eş zamanlı istekler atarak rate limiti aş. Mesela bir giriş ekranında brute-force ile şifre dene. Aynı anda auth token ve erişim isteği gönder, token geçerliyken 403’ü atlatabilirsin. Bunları yaparken false positive, sunucu çökmesi veya ban yeme ihtimali var. Bu sebeple düşük hacimle istek at. Eğer 403 statik (dosya izni sebebiyleyse) race condition işe yaramaz.
HTTP/3 ve QUIC
→ Google tarafından geliştirilen QUIC transport katmanı protokolünü kullanır.
→ Tüm veri trafiği UDP datagramları ile 443(https) portu üzerinden aktarılır.
→ UDP bağlantısız bir protokol olduğundan paketler birbirinden bağımsız gider.
→ QUIC’de uzun ve kısa olmak üzere 2 çeşit paket mevcuttur. Uzun olan ilk istektir.
→Her pakette benzersiz bir numara bulunur, bu numara 3 alandan (Initial, Handshake, Application Data) oluşur. Bu şekilde paketler karışmaz ve güvenlik sağlanır.
→ Paketlerin içerisinde küçük veri birimleri bulunur. ACK frame onay mesajını, STREAM frame veri akışını, CRYPTO frame şifreleme verilerin, CONNECTION_CLOSE frame bağlantısını güvenli kapatacak veriyi taşır.
→ Her frame akış kontrol (veri hızı ayarı) ve hata düzeltme için tasarlanmıştır.
→ Tek veya çift yönlü olarak bir bağlantıda birden fazla akış(stream) olabilir.
→ Her akış benzersiz bir ID alır ve akış kontrolü kredi tabanlıdır. (Flow Control Credits: Alıcı ne kadar veri kabul edebileceğini bildirir.)
→ RFC 9002 standartına göre ağ tıkanıklığını yönetir. Paket kaybında sadece etkilenen akış yavaşlar, diğerleri devan eder. HOL Blocking (Hide-of-Line-Blocking: TCP’deki paket kaybının tüm akışı engellemesi olmaz)
→ Connection ID’ler ile NAT Rebinding Migration yapılarak ağ değişimlerinde akışın normal bir şekilde devam etmesi sağlanır. NAT ağ adres çevirici, Rebinding ağ adres değişimini yönetir, migration ağın değişmesi halinde devamlılığı sağlar. Yeni ağ yolunun doğrulanması ile MTU (Maximum Transmission Unit ) ile paket boyutları optimize edilir.
→ Paket kaybı konusunda FEC(Forward Error Connection ile ileri hata düzeltme, kayıp paketleri önceden tahmin edip onarma yapıp yeniden gönderebilir.)
→ Bağlantı açma, veri gönderme, bağlantıyı kapatmayı statüs machine yapar. (Graceful Shutdown: Veri kaybı olmadan bağlantıyı sonlandır.)
Kısaca en önemli özellikleri: Her akışın ID’si vardır. Bağlantı değişikliği yönetme. Kayıp paket kurtarma ve iletme.
James Kettle (Race Condition)
Race Condition ile ilgili yapılacak çıkarım ve güzel tarafı; bir web zafiyeti en çok çoklu adımların olduğu yerlerde ortaya çıkar, race conditionda ise herşey çok adımlıdır ve bu yüzden zafiyet bulunma olasılığı çok fazladır.
Her HTTP isteği bir uygulamayı birden fazla geçici, gizli durumdan geçirebilir, bunlara alt durum denir. Doğru zamanlama yapılırsa bu alt durumları istenmeyen geçişler için kullanabiliriz. İş mantığını bozabilir ve yüksek etkili istismarlar elde edebiliriz. Alt durum uygulamanın tek bir isteği işlerken içinden geçtiği ve istek tamamlanmadan önce çıktığı, kısa ömürlü bir durumdur.?Bu durumu geliştirici mi ayarlıyor yoksa sistemsel bir durum mu?
Alt durum 1ms (0,0001sn) gibi kısa bir zaman aralığında geçerli olur. İşte bu zaman aralığına yarış aralığı denir. Bu alt durumu keşfetmek için alt durum üzerinde geçişi tetikleyecek bir, başlangıç HTTP isteği ve yarış sırasında aynı kaynakla etkileşim kuran ikinci bir istek gerekir. Örnek: ilk istek oturum açma, ikinci istek yönetici paneline erişme isteği olabilir. ??Burada birinci istek doğrulandığı için ve ikinci istekte aynı anda gittiği için, önceki isteğin onayıyla mı geçiyor??
Ağdaki TCP paketlerinin düzensiz gecikmesi sebebiyle son bayt tekniği dahi işe yaramayabilir. Burada da tek paket saldırısı devreye girer ve ağdaki gecikmeden bağımsız olarak sunucuya aynı anda 20–30 istek gönderebiliriz.
Son bayt tekniğiyle 20 istek atılınca ilk istek ile son istek arasında 3–4 ms fark oluyor. Tek paket saldırısında ise 1ms-0,3ms gecikme oluyor. İşte tek paket tekniğindeki zaman yarış zamanı için gerekli zaman. Bu sebeple de tek paket saldırısı 30 saniyede başarılı olurken, son bayt saldırısı 2 saatte başarılı olur.
Klasik sınır aşım saldırıları; sınır belirleyip onu aşmaya çalışarak kolayca tespit edilebilir. Daha gelişmiş saldırılar için istismar edilebilir alt durumları keşfetmek daha zordur.
Tespit ve Sömürü İçin Metodoloji
Tahmin → Hedefimiz sistemin uç noktalarıdır, her uç noktayı test etmemiz gereksiz iş yüküdür. Bu yüzden atlatmak istediğimiz “kullanıcılar, oturumlar, siparişler” gibi nesneleri belirlemeliyiz. Bunların işletmeye özgü kavramlar olması önemlidir.
Analiz → Her nesne için, nesneye yazan veya nesneden veri okuyan ve ardından bu verileri önemli bir amaç için kullanan tüm uç noktaları belirlemeliyiz. (Kullanıcı oluşturma, profil düzenleme, parola sıfırlama) Örnek senaryo: Bir oturum açma işlevi, oturumlar oluşturulurken kullanıcılar tablosundan kritik veriler okuyabilir.
→Race Conditionda paylaşılan bir kaynaktan iki eş zamanlı işlem olan bir “çarpışma/çakışma” gerekir. Bu sebeple çakışmalara neden olma olasılığı düşük uç noktaları elemek için her nesne ve ilişkili uç noktalara aşağıdaki soruları sormak mantıklıdır.
1- Durum Saklama Şekli: Kalıcı olarak sunucu tarafında depolanan veri akış işlemleri race condition için idealdir. Bazı uç noktalar durumları istemci tarafında saklayabilir. Mesela parola sıfırlama işlemini JWT’ye e-posta göndererek yapıyor olabilir. Bu da race condition ihtimalini düşürür ve geçeriz.
2- Düzeltme mi/Ekleme mi yapıyoruz: Mevcut verileri düzenleyen işlemler büyük bir çakışma potansiyeline sahiptir. Mesela bir hesabın birincil e-posta adresini değiştirmek. Çünkü bu sunucu taraflı bir veridir ve çakışma oranını arttırır. Mevcut verilere ekleme yapan eylemler ise sınır aşımı saldırıları dışında genellikle güvendedir ve geçeriz. Bir hesaba ek bir e-posta adresi eklemek.
Yazının devamında: Saldırı ve sömürü aşamasına, Sub-State/Alt Durum konusunun sebebi geliştirici mi yoksa sistem mi konusuna, İlk isteğin oturum açma ikinci isteğin admin paneline erişimi konusundaki mantığa, Nagle Algoritması ve Race Condition ile bağlantısına, İsteklere gecikmelerin nasıl eklenebildiğine ve Zamanlama kavramı ile modern web’ de süreler gibi detaylara değinilecektir…
İki zafiyette isteklerin ön-arka uçta farklı yorumlanmasından kaynaklanır ve yetkisiz erişim, veri sızıntısı yaratır. İkisi de isteklerin sırası veya aynı anda işlenmesiyle ilgili hatalardan çıkar. Race Conditionda işlemler çakışır ve veri bozulur, smugglingde ise istekler birleşir veya karışır. Her ikisi de sunucunun paralel işlem kapasitesinin yetersiz kalmasından kaynaklanır. İkisinde de atomic işlemler, kilit mekanizmaları ve rate limit şart. Smuggling için HTTP parsing standartlaştırması, race için senkronizasyon gerekli.
Layer → Race Condition uygulama katmanında (veritabanı, session, dosya erişimi) oluşur. Aynı kaynağa birden fazla istek giderken oluşan sıra karmaşası sebep olur. Genel bir eşzamanlılık problemidir ve yazılım hataları gibi web dışında da olur. HTTP Request Smuggling ağ ve protokol katmanında, genellikle reverse Proxy (WAF, Load Balancer) ile backend arasında HTTP parsing farkından dolayı meydana gelir. Web’e özgüdür.
Tetikleme → Race Condition eş zamanlı isteklerle tetiklenir, zaman göstergeleri önemlidir. HTTP Request Smuggiling özel header manipülasyonuyla (CL.TE — TE.CL) çakışmasıyla istekler birleştirilerek tetiklenir.
Etkiler ve İstismar → Race Condition veri manipülasyonuna (bakiye sıfırlama), limit bypass gibi sebep olur. Uygulama mantığını bozar. HTTP Request Smuggling’in istek zehirleme, cache poisining, WAF bypass gibi etkileri vardır. Daha çok zincirleme saldırılara (XSS-SQLi) yol açar.
Bulma Zorluğu → Race Condition yüksek trafik ve özel zamanlama ister, false positive çoktur. HTTP Request Smuggling de ise Proxy-Backend uyumsuzluğu aranır, daha statiktir ama versiyona bağımlıdır.
→Rate Limit kısıtlaması sebebiyle 403 aldığını düşünüyorsan; eş zamanlı istekler atarak rate limiti aş. Mesela bir giriş ekranında brute-force ile şifre dene. Aynı anda auth token ve erişim isteği gönder, token geçerliyken 403’ü atlatabilirsin. Bunları yaparken false positive, sunucu çökmesi veya ban yeme ihtimali var. Bu sebeple düşük hacimle istek at. Eğer 403 statik (dosya izni sebebiyleyse) race condition işe yaramaz.
HTTP/3 ve QUIC
→ Google tarafından geliştirilen QUIC transport katmanı protokolünü kullanır.
→ Tüm veri trafiği UDP datagramları ile 443(https) portu üzerinden aktarılır.
→ UDP bağlantısız bir protokol olduğundan paketler birbirinden bağımsız gider.
→ QUIC’de uzun ve kısa olmak üzere 2 çeşit paket mevcuttur. Uzun olan ilk istektir.
→Her pakette benzersiz bir numara bulunur, bu numara 3 alandan (Initial, Handshake, Application Data) oluşur. Bu şekilde paketler karışmaz ve güvenlik sağlanır.
→ Paketlerin içerisinde küçük veri birimleri bulunur. ACK frame onay mesajını, STREAM frame veri akışını, CRYPTO frame şifreleme verilerin, CONNECTION_CLOSE frame bağlantısını güvenli kapatacak veriyi taşır.
→ Her frame akış kontrol (veri hızı ayarı) ve hata düzeltme için tasarlanmıştır.
→ Tek veya çift yönlü olarak bir bağlantıda birden fazla akış(stream) olabilir.
→ Her akış benzersiz bir ID alır ve akış kontrolü kredi tabanlıdır. (Flow Control Credits: Alıcı ne kadar veri kabul edebileceğini bildirir.)
→ RFC 9002 standartına göre ağ tıkanıklığını yönetir. Paket kaybında sadece etkilenen akış yavaşlar, diğerleri devan eder. HOL Blocking (Hide-of-Line-Blocking: TCP’deki paket kaybının tüm akışı engellemesi olmaz)
→ Connection ID’ler ile NAT Rebinding Migration yapılarak ağ değişimlerinde akışın normal bir şekilde devam etmesi sağlanır. NAT ağ adres çevirici, Rebinding ağ adres değişimini yönetir, migration ağın değişmesi halinde devamlılığı sağlar. Yeni ağ yolunun doğrulanması ile MTU (Maximum Transmission Unit ) ile paket boyutları optimize edilir.
→ Paket kaybı konusunda FEC(Forward Error Connection ile ileri hata düzeltme, kayıp paketleri önceden tahmin edip onarma yapıp yeniden gönderebilir.)
→ Bağlantı açma, veri gönderme, bağlantıyı kapatmayı statüs machine yapar. (Graceful Shutdown: Veri kaybı olmadan bağlantıyı sonlandır.)
Kısaca en önemli özellikleri: Her akışın ID’si vardır. Bağlantı değişikliği yönetme. Kayıp paket kurtarma ve iletme.
James Kettle (Race Condition)
Race Condition ile ilgili yapılacak çıkarım ve güzel tarafı; bir web zafiyeti en çok çoklu adımların olduğu yerlerde ortaya çıkar, race conditionda ise herşey çok adımlıdır ve bu yüzden zafiyet bulunma olasılığı çok fazladır.
Her HTTP isteği bir uygulamayı birden fazla geçici, gizli durumdan geçirebilir, bunlara alt durum denir. Doğru zamanlama yapılırsa bu alt durumları istenmeyen geçişler için kullanabiliriz. İş mantığını bozabilir ve yüksek etkili istismarlar elde edebiliriz. Alt durum uygulamanın tek bir isteği işlerken içinden geçtiği ve istek tamamlanmadan önce çıktığı, kısa ömürlü bir durumdur.?Bu durumu geliştirici mi ayarlıyor yoksa sistemsel bir durum mu?
Alt durum 1ms (0,0001sn) gibi kısa bir zaman aralığında geçerli olur. İşte bu zaman aralığına yarış aralığı denir. Bu alt durumu keşfetmek için alt durum üzerinde geçişi tetikleyecek bir, başlangıç HTTP isteği ve yarış sırasında aynı kaynakla etkileşim kuran ikinci bir istek gerekir. Örnek: ilk istek oturum açma, ikinci istek yönetici paneline erişme isteği olabilir. ??Burada birinci istek doğrulandığı için ve ikinci istekte aynı anda gittiği için, önceki isteğin onayıyla mı geçiyor??
Ağdaki TCP paketlerinin düzensiz gecikmesi sebebiyle son bayt tekniği dahi işe yaramayabilir. Burada da tek paket saldırısı devreye girer ve ağdaki gecikmeden bağımsız olarak sunucuya aynı anda 20–30 istek gönderebiliriz.
Son bayt tekniğiyle 20 istek atılınca ilk istek ile son istek arasında 3–4 ms fark oluyor. Tek paket saldırısında ise 1ms-0,3ms gecikme oluyor. İşte tek paket tekniğindeki zaman yarış zamanı için gerekli zaman. Bu sebeple de tek paket saldırısı 30 saniyede başarılı olurken, son bayt saldırısı 2 saatte başarılı olur.
Klasik sınır aşım saldırıları; sınır belirleyip onu aşmaya çalışarak kolayca tespit edilebilir. Daha gelişmiş saldırılar için istismar edilebilir alt durumları keşfetmek daha zordur.
Tespit ve Sömürü İçin Metodoloji
Tahmin → Hedefimiz sistemin uç noktalarıdır, her uç noktayı test etmemiz gereksiz iş yüküdür. Bu yüzden atlatmak istediğimiz “kullanıcılar, oturumlar, siparişler” gibi nesneleri belirlemeliyiz. Bunların işletmeye özgü kavramlar olması önemlidir.
Analiz → Her nesne için, nesneye yazan veya nesneden veri okuyan ve ardından bu verileri önemli bir amaç için kullanan tüm uç noktaları belirlemeliyiz. (Kullanıcı oluşturma, profil düzenleme, parola sıfırlama) Örnek senaryo: Bir oturum açma işlevi, oturumlar oluşturulurken kullanıcılar tablosundan kritik veriler okuyabilir.
→Race Conditionda paylaşılan bir kaynaktan iki eş zamanlı işlem olan bir “çarpışma/çakışma” gerekir. Bu sebeple çakışmalara neden olma olasılığı düşük uç noktaları elemek için her nesne ve ilişkili uç noktalara aşağıdaki soruları sormak mantıklıdır.
1- Durum Saklama Şekli: Kalıcı olarak sunucu tarafında depolanan veri akış işlemleri race condition için idealdir. Bazı uç noktalar durumları istemci tarafında saklayabilir. Mesela parola sıfırlama işlemini JWT’ye e-posta göndererek yapıyor olabilir. Bu da race condition ihtimalini düşürür ve geçeriz.
2- Düzeltme mi/Ekleme mi yapıyoruz: Mevcut verileri düzenleyen işlemler büyük bir çakışma potansiyeline sahiptir. Mesela bir hesabın birincil e-posta adresini değiştirmek. Çünkü bu sunucu taraflı bir veridir ve çakışma oranını arttırır. Mevcut verilere ekleme yapan eylemler ise sınır aşımı saldırıları dışında genellikle güvendedir ve geçeriz. Bir hesaba ek bir e-posta adresi eklemek.
Yazının devamında: Saldırı ve sömürü aşamasına, Sub-State/Alt Durum konusunun sebebi geliştirici mi yoksa sistem mi konusuna, İlk isteğin oturum açma ikinci isteğin admin paneline erişimi konusundaki mantığa, Nagle Algoritması ve Race Condition ile bağlantısına, İsteklere gecikmelerin nasıl eklenebildiğine ve Zamanlama kavramı ile modern web’ de süreler gibi detaylara değinilecektir…
