- 29 Eki 2018
- 2,702
- 568
Bu konuda, Türkçe karşılığı HTTP istek kaçakçılığı olan "HTTP request smuggling" saldırılarını açıklayacak ve yaygın istek kaçakçılığı güvenlik açıklarının nasıl ortaya çıkabileceğini anlatacağız.
Konudaki renklerin anlamı: Başlık, alt başlık, yönlendirilen konu, kavram, not, lab
HTTP istek kaçakçılığı nedir?
HTTP istek kaçakçılığı, bir web sitesinin bir veya daha fazla kullanıcıdan alınan HTTP istek dizilerini işleme biçimine müdahale etmeye yönelik bir tekniktir. İstek kaçakçılığı güvenlik açıkları genellikle kritik niteliktedir ve bir saldırganın güvenlik kontrollerini geçmesine, hassas verilere yetkisiz erişim elde etmesine ve diğer uygulama kullanıcılarını doğrudan tehlikeye atmasına olanak tanır.
İstek kaçakçılığı öncelikle HTTP/1 istekleri ile ilişkilidir. Bununla birlikte, HTTP/2'yi destekleyen web siteleri, back-end mimarilerine bağlı olarak savunmasız olabilir.
HTTP istek kaçakçılığı saldırısında ne olur?
Günümüz web uygulamalarında kullanıcılar ile nihai uygulama mantığı arasında sıklıkla HTTP sunucu zincirleri kullanılmaktadır. Kullanıcılar isteklerini bir front-end sunucusuna (bazen yük dengeleyici veya ters proxy olarak da adlandırılır) gönderir ve bu sunucu istekleri bir veya daha fazla back-end sunucusuna iletir. Bu tür bir mimari, modern bulut tabanlı uygulamalarda giderek yaygınlaşmakta ve bazı durumlarda kaçınılmaz hale gelmektedir.
Front-end sunucusu HTTP isteklerini bir back-end sunucusuna iletirken, genellikle aynı back-end ağ bağlantısı üzerinden birkaç istek gönderir, çünkü bu çok daha verimli ve performanslıdır. Protokol çok basittir; HTTP istekleri birbiri ardına gönderilir ve alıcı sunucunun bir isteğin nerede bittiğini ve bir sonrakinin nerede başladığını belirlemesi gerekir:
Bu durumda, front-end ve back-end sistemlerinin istekler arasındaki sınırlar konusunda hemfikir olması çok önemlidir. Aksi takdirde, bir saldırgan front-end ve back-end sistemleri tarafından farklı yorumlanan belirsiz bir istek gönderebilir:
Burada saldırgan, front-end isteğinin bir kısmının back-end sunucusu tarafından bir sonraki isteğin başlangıcı olarak yorumlanmasına neden olur. Etkili bir şekilde bir sonraki isteğin önüne eklenir ve böylece uygulamanın bu isteği işleme biçimine müdahale edebilir. Bu bir istek kaçakçılığı saldırısıdır ve yıkıcı sonuçlar doğurabilir.
HTTP istek kaçakçılığı güvenlik açıkları nasıl ortaya çıkar?
HTTP istek kaçakçılığı güvenlik açıklarının çoğu, HTTP/1 spesifikasyonunun bir isteğin nerede biteceğini belirtmek için iki farklı yol sunması nedeniyle ortaya çıkar: Content-Length başlığı ve Transfer-Encoding başlığı.
Content-Length başlığı basittir: mesaj gövdesinin uzunluğunu bayt cinsinden belirtir. Örneğin:
Transfer-Encoding başlığı, mesaj gövdesinin yığın kodlama kullandığını belirtmek için kullanılabilir. Bu, ileti gövdesinin bir veya daha fazla veri yığını içerdiği anlamına gelir. Her yığın, bayt cinsinden yığın boyutu (onaltılık olarak ifade edilir), ardından bir satırbaşı ve ardından yığın içeriğinden oluşur. İleti, sıfır boyutlu bir yığınla sonlandırılır. Örneğin:
HTTP/1 spesifikasyonu HTTP mesajlarının uzunluğunu belirtmek için iki farklı yöntem sunduğundan, tek bir mesajın her iki yöntemi de aynı anda kullanması ve böylece birbirleriyle çakışmaları mümkündür. Belirtim, Content-Length ve Transfer-Encoding başlıklarının her ikisi de mevcutsa Content-Length başlığının göz ardı edilmesi gerektiğini belirterek bu sorunu önlemeye çalışır. Bu, yalnızca tek bir sunucu söz konusu olduğunda belirsizliği önlemek için yeterli olabilir, ancak iki veya daha fazla sunucu birbirine zincirlendiğinde yeterli olmayabilir. Bu durumda, iki nedenden dolayı sorunlar ortaya çıkabilir:
Front-end ve back-end sunucuları (muhtemelen gizlenmiş) Transfer-Encoding başlığı ile ilgili olarak farklı davranırlarsa, birbirini izleyen istekler arasındaki sınırlar konusunda anlaşamayabilirler ve bu da istek kaçakçılığı güvenlik açıklarına yol açabilir.
Not: HTTP/2'yi uçtan uca kullanan web siteleri, istek kaçakçılığı saldırılarına karşı doğal olarak bağışıktır. HTTP/2 spesifikasyonu, bir isteğin uzunluğunu belirtmek için tek ve sağlam bir mekanizma sunduğundan, bir saldırganın gerekli belirsizliği ortaya koymasının hiçbir yolu yoktur.
Bununla birlikte, birçok web sitesi HTTP/2-speaking bir front-end sunucusuna sahiptir, ancak bunu yalnızca HTTP/1'i destekleyen back-end altyapısının önüne yerleştirir. Bu, front-end'in aldığı istekleri etkili bir şekilde HTTP/1'e çevirmesi gerektiği anlamına gelir. Daha fazla bilgi için Gelişmiş istek kaçakçılığı başlığına bakın.
HTTP istek kaçakçılığı saldırısı nasıl gerçekleştirilir?
Klasik istek kaçakçılığı saldırıları, hem Content-Length başlığını hem de Transfer-Encoding başlığını tek bir HTTP/1 isteğine yerleştirmeyi ve bunları front-end ve back-end sunucularının isteği farklı şekilde işlemesi için manipüle etmeyi içerir. Bunun tam olarak nasıl yapılacağı iki sunucunun davranışına bağlıdır:
CL.TE güvenlik açıkları
Burada front-end sunucu Content-Length başlığını, back-end sunucusuysa Transfer-Encoding başlığını kullanır. Basit bir HTTP istek kaçakçılığı saldırısını aşağıdaki gibi gerçekleştirebiliriz:
Front-end sunucu Content-Length başlığını işler ve istek gövdesinin SMUGGLED'in sonuna kadar 13 bayt uzunluğunda olduğunu belirler. Bu istek back-end sunucusuna iletilir.
Back-end sunucu Transfer-Encoding başlığını işler ve böylece mesaj gövdesini yığın kodlama kullanıyormuş gibi değerlendirir. Sıfır uzunlukta olduğu belirtilen ilk yığını işler ve böylece isteği sonlandırıyormuş gibi davranır. Sonraki baytlar, SMUGGLED, işlenmeden bırakılır ve back-end sunucusu bunları sıradaki bir sonraki isteğin başlangıcı olarak kabul eder.
Bu bölümde 1. lab vardır, yorumlardan erişebilirsiniz.
TE.CL güvenlik açıkları
Burada front-end sunucu Transfer-Encoding başlığını, back-end sunucu ise Content-Length başlığını kullanır. Basit bir HTTP istek kaçakçılığı saldırısını aşağıdaki gibi gerçekleştirebiliriz:
Front-end sunucu Transfer-Encoding başlığını işler ve böylece mesaj gövdesini yığın kodlama kullanıyormuş gibi değerlendirir. SMUGGLED'i izleyen satırın başlangıcına kadar 8 bayt uzunluğunda olduğu belirtilen ilk yığını işler. Sıfır uzunlukta olduğu belirtilen ikinci yığını işler ve böylece isteği sonlandırıyormuş gibi davranır. Bu istek back-end sunucusuna iletilir.
Back-end sunucusu Content-Length başlığını işler ve istek gövdesinin 8'den sonraki satırın başlangıcına kadar 3 bayt uzunluğunda olduğunu belirler. SMUGGLED ile başlayan sonraki baytlar işlenmeden bırakılır ve back-end sunucusu bunları sıradaki bir sonraki isteğin başlangıcı olarak kabul eder.
Bu bölümde 2. lab vardır, yorumlardan erişebilirsiniz.
TE.TE davranışı: TE başlığının gizlenmesi
Burada, front-end ve back-end sunucuların her ikisi de Transfer-Encoding başlığını desteklemektedir, ancak sunuculardan biri, başlığı bir şekilde gizleyerek işlememesi için uyarılabilir.
Transfer-Encoding başlığını gizlemenin potansiyel olarak sonsuz yolu vardır. Örneğin:
Bu tekniklerin her biri HTTP spesifikasyonundan ince bir sapmayı içerir. Bir protokol spesifikasyonunu uygulayan gerçek dünya kodu nadiren mutlak hassasiyetle buna bağlı kalır ve farklı uygulamaların spesifikasyondan farklı varyasyonları tolere etmesi yaygındır. Bir TE.TE güvenlik açığını ortaya çıkarmak için, Transfer-Encoding başlığının bir varyasyonunu bulmak gerekir, öyle ki front-end veya back-end sunuculardan yalnızca biri bunu işlerken diğer sunucu bunu yok sayar.
Karartılmış Transfer-Encoding başlığını işlememeye teşvik edilebilecek olanın front-end mi yoksa back-end sunucu mu olduğuna bağlı olarak, saldırının geri kalanı daha önce açıklanan CL.TE veya TE.CL güvenlik açıklarıyla aynı biçimi alacaktır.
Bu bölümde 3. lab vardır, yorumlardan erişebilirsiniz.
HTTP istek kaçakçılığı güvenlik açıkları nasıl bulunur?
HTTP istek kaçakçılığı güvenlik açıklarını kendiniz nasıl tespit edeceğinize dair bazı ipuçları için aşağıdaki konumuza göz atın. Ayrıca, bunun pratikte nasıl çalıştığını görebilmeniz için bazı etkileşimli LABS'ler sağladık.
https://www.turkhackteam.org/konular/http-istek-kacakciligi-guvenlik-aciklarini-bulma.2047510/
HTTP istek kaçakçılığı güvenlik açıklarından nasıl yararlanılır?
Artık temel kavramlara aşina olduğunuza göre, HTTP istek kaçakçılığının bir dizi yüksek şiddetli saldırı oluşturmak için nasıl kullanılabileceğine bir göz atalım. Her zamanki gibi, gerçekçi hedeflere saldırmak için çok sayıda tamamen etkileşimli LABS vardır.
https://www.turkhackteam.org/konula...igi-guvenlik-aciklarindan-yararlanma.2047511/
HTTP istek kaçakçılığı güvenlik açıkları nasıl önlenir?
HTTP istek kaçakçılı güvenlik açıkları, front-end sunucusu ve back-end sunucusunun istekler arasındaki sınırları belirlemek için farklı mekanizmalar kullandığı durumlarda ortaya çıkar. Bunun nedeni, HTTP/1 sunucularının her bir isteğin nerede bittiğini belirlemek için Content-Length başlığını mı yoksa yığın aktarım kodlamasını mı kullandığı arasındaki tutarsızlıklar olabilir. HTTP/2 ortamlarında, back-end için HTTP/2 isteklerini düşürmeye yönelik yaygın uygulama da sorunlarla doludur ve bir dizi ek saldırıyı mümkün kılar veya basitleştirir.
HTTP istek kaçakçılığı güvenlik açıklarını önlemek için aşağıdaki üst düzey önlemleri öneririz:
Eğitim materyallerinde gösterdiğimiz gibi, back-end bağlantılarının yeniden kullanımını devre dışı bırakmak belirli saldırı türlerini azaltmaya yardımcı olacaktır, ancak bu yine de sizi istek tünelleme saldırılarından korumaz.
Konudaki renklerin anlamı: Başlık, alt başlık, yönlendirilen konu, kavram, not, lab
HTTP istek kaçakçılığı nedir?
HTTP istek kaçakçılığı, bir web sitesinin bir veya daha fazla kullanıcıdan alınan HTTP istek dizilerini işleme biçimine müdahale etmeye yönelik bir tekniktir. İstek kaçakçılığı güvenlik açıkları genellikle kritik niteliktedir ve bir saldırganın güvenlik kontrollerini geçmesine, hassas verilere yetkisiz erişim elde etmesine ve diğer uygulama kullanıcılarını doğrudan tehlikeye atmasına olanak tanır.
İstek kaçakçılığı öncelikle HTTP/1 istekleri ile ilişkilidir. Bununla birlikte, HTTP/2'yi destekleyen web siteleri, back-end mimarilerine bağlı olarak savunmasız olabilir.
HTTP istek kaçakçılığı saldırısında ne olur?
Günümüz web uygulamalarında kullanıcılar ile nihai uygulama mantığı arasında sıklıkla HTTP sunucu zincirleri kullanılmaktadır. Kullanıcılar isteklerini bir front-end sunucusuna (bazen yük dengeleyici veya ters proxy olarak da adlandırılır) gönderir ve bu sunucu istekleri bir veya daha fazla back-end sunucusuna iletir. Bu tür bir mimari, modern bulut tabanlı uygulamalarda giderek yaygınlaşmakta ve bazı durumlarda kaçınılmaz hale gelmektedir.
Front-end sunucusu HTTP isteklerini bir back-end sunucusuna iletirken, genellikle aynı back-end ağ bağlantısı üzerinden birkaç istek gönderir, çünkü bu çok daha verimli ve performanslıdır. Protokol çok basittir; HTTP istekleri birbiri ardına gönderilir ve alıcı sunucunun bir isteğin nerede bittiğini ve bir sonrakinin nerede başladığını belirlemesi gerekir:
Bu durumda, front-end ve back-end sistemlerinin istekler arasındaki sınırlar konusunda hemfikir olması çok önemlidir. Aksi takdirde, bir saldırgan front-end ve back-end sistemleri tarafından farklı yorumlanan belirsiz bir istek gönderebilir:
Burada saldırgan, front-end isteğinin bir kısmının back-end sunucusu tarafından bir sonraki isteğin başlangıcı olarak yorumlanmasına neden olur. Etkili bir şekilde bir sonraki isteğin önüne eklenir ve böylece uygulamanın bu isteği işleme biçimine müdahale edebilir. Bu bir istek kaçakçılığı saldırısıdır ve yıkıcı sonuçlar doğurabilir.
HTTP istek kaçakçılığı güvenlik açıkları nasıl ortaya çıkar?
HTTP istek kaçakçılığı güvenlik açıklarının çoğu, HTTP/1 spesifikasyonunun bir isteğin nerede biteceğini belirtmek için iki farklı yol sunması nedeniyle ortaya çıkar: Content-Length başlığı ve Transfer-Encoding başlığı.
Content-Length başlığı basittir: mesaj gövdesinin uzunluğunu bayt cinsinden belirtir. Örneğin:
HTTP:
POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
q=smugglingTransfer-Encoding başlığı, mesaj gövdesinin yığın kodlama kullandığını belirtmek için kullanılabilir. Bu, ileti gövdesinin bir veya daha fazla veri yığını içerdiği anlamına gelir. Her yığın, bayt cinsinden yığın boyutu (onaltılık olarak ifade edilir), ardından bir satırbaşı ve ardından yığın içeriğinden oluşur. İleti, sıfır boyutlu bir yığınla sonlandırılır. Örneğin:
HTTP:
POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
b
q=smuggling
0HTTP/1 spesifikasyonu HTTP mesajlarının uzunluğunu belirtmek için iki farklı yöntem sunduğundan, tek bir mesajın her iki yöntemi de aynı anda kullanması ve böylece birbirleriyle çakışmaları mümkündür. Belirtim, Content-Length ve Transfer-Encoding başlıklarının her ikisi de mevcutsa Content-Length başlığının göz ardı edilmesi gerektiğini belirterek bu sorunu önlemeye çalışır. Bu, yalnızca tek bir sunucu söz konusu olduğunda belirsizliği önlemek için yeterli olabilir, ancak iki veya daha fazla sunucu birbirine zincirlendiğinde yeterli olmayabilir. Bu durumda, iki nedenden dolayı sorunlar ortaya çıkabilir:
- Bazı sunucular isteklerde Transfer-Encoding başlığını desteklemez.
- Transfer-Encoding başlığını destekleyen bazı sunucular, başlık bir şekilde gizlenirse bu başlığı işlememeye teşvik edilebilir.
Front-end ve back-end sunucuları (muhtemelen gizlenmiş) Transfer-Encoding başlığı ile ilgili olarak farklı davranırlarsa, birbirini izleyen istekler arasındaki sınırlar konusunda anlaşamayabilirler ve bu da istek kaçakçılığı güvenlik açıklarına yol açabilir.
Not: HTTP/2'yi uçtan uca kullanan web siteleri, istek kaçakçılığı saldırılarına karşı doğal olarak bağışıktır. HTTP/2 spesifikasyonu, bir isteğin uzunluğunu belirtmek için tek ve sağlam bir mekanizma sunduğundan, bir saldırganın gerekli belirsizliği ortaya koymasının hiçbir yolu yoktur.
Bununla birlikte, birçok web sitesi HTTP/2-speaking bir front-end sunucusuna sahiptir, ancak bunu yalnızca HTTP/1'i destekleyen back-end altyapısının önüne yerleştirir. Bu, front-end'in aldığı istekleri etkili bir şekilde HTTP/1'e çevirmesi gerektiği anlamına gelir. Daha fazla bilgi için Gelişmiş istek kaçakçılığı başlığına bakın.
HTTP istek kaçakçılığı saldırısı nasıl gerçekleştirilir?
Klasik istek kaçakçılığı saldırıları, hem Content-Length başlığını hem de Transfer-Encoding başlığını tek bir HTTP/1 isteğine yerleştirmeyi ve bunları front-end ve back-end sunucularının isteği farklı şekilde işlemesi için manipüle etmeyi içerir. Bunun tam olarak nasıl yapılacağı iki sunucunun davranışına bağlıdır:
- CL.TE: front-end sunucusu Content-Length başlığını, back-end sunucusu Transfer-Encoding başlığını kullanır.
- TE.CL: front-end sunucu Transfer-Encoding başlığını, back-end sunucu Content-Length başlığını kullanır.
- TE.TE: front-end ve back-end sunucularının her ikisi de Transfer-Encoding başlığını destekler, ancak sunuculardan biri başlığı bir şekilde gizleyerek işlememesi için uyarılabilir.
CL.TE güvenlik açıkları
Burada front-end sunucu Content-Length başlığını, back-end sunucusuysa Transfer-Encoding başlığını kullanır. Basit bir HTTP istek kaçakçılığı saldırısını aşağıdaki gibi gerçekleştirebiliriz:
HTTP:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked
0
SMUGGLEDFront-end sunucu Content-Length başlığını işler ve istek gövdesinin SMUGGLED'in sonuna kadar 13 bayt uzunluğunda olduğunu belirler. Bu istek back-end sunucusuna iletilir.
Back-end sunucu Transfer-Encoding başlığını işler ve böylece mesaj gövdesini yığın kodlama kullanıyormuş gibi değerlendirir. Sıfır uzunlukta olduğu belirtilen ilk yığını işler ve böylece isteği sonlandırıyormuş gibi davranır. Sonraki baytlar, SMUGGLED, işlenmeden bırakılır ve back-end sunucusu bunları sıradaki bir sonraki isteğin başlangıcı olarak kabul eder.
Bu bölümde 1. lab vardır, yorumlardan erişebilirsiniz.
TE.CL güvenlik açıkları
Burada front-end sunucu Transfer-Encoding başlığını, back-end sunucu ise Content-Length başlığını kullanır. Basit bir HTTP istek kaçakçılığı saldırısını aşağıdaki gibi gerçekleştirebiliriz:
HTTP:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 3
Transfer-Encoding: chunked
8
SMUGGLED
0Front-end sunucu Transfer-Encoding başlığını işler ve böylece mesaj gövdesini yığın kodlama kullanıyormuş gibi değerlendirir. SMUGGLED'i izleyen satırın başlangıcına kadar 8 bayt uzunluğunda olduğu belirtilen ilk yığını işler. Sıfır uzunlukta olduğu belirtilen ikinci yığını işler ve böylece isteği sonlandırıyormuş gibi davranır. Bu istek back-end sunucusuna iletilir.
Back-end sunucusu Content-Length başlığını işler ve istek gövdesinin 8'den sonraki satırın başlangıcına kadar 3 bayt uzunluğunda olduğunu belirler. SMUGGLED ile başlayan sonraki baytlar işlenmeden bırakılır ve back-end sunucusu bunları sıradaki bir sonraki isteğin başlangıcı olarak kabul eder.
Bu bölümde 2. lab vardır, yorumlardan erişebilirsiniz.
TE.TE davranışı: TE başlığının gizlenmesi
Burada, front-end ve back-end sunucuların her ikisi de Transfer-Encoding başlığını desteklemektedir, ancak sunuculardan biri, başlığı bir şekilde gizleyerek işlememesi için uyarılabilir.
Transfer-Encoding başlığını gizlemenin potansiyel olarak sonsuz yolu vardır. Örneğin:
HTTP:
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked
Transfer-Encoding
: chunkedBu tekniklerin her biri HTTP spesifikasyonundan ince bir sapmayı içerir. Bir protokol spesifikasyonunu uygulayan gerçek dünya kodu nadiren mutlak hassasiyetle buna bağlı kalır ve farklı uygulamaların spesifikasyondan farklı varyasyonları tolere etmesi yaygındır. Bir TE.TE güvenlik açığını ortaya çıkarmak için, Transfer-Encoding başlığının bir varyasyonunu bulmak gerekir, öyle ki front-end veya back-end sunuculardan yalnızca biri bunu işlerken diğer sunucu bunu yok sayar.
Karartılmış Transfer-Encoding başlığını işlememeye teşvik edilebilecek olanın front-end mi yoksa back-end sunucu mu olduğuna bağlı olarak, saldırının geri kalanı daha önce açıklanan CL.TE veya TE.CL güvenlik açıklarıyla aynı biçimi alacaktır.
Bu bölümde 3. lab vardır, yorumlardan erişebilirsiniz.
HTTP istek kaçakçılığı güvenlik açıkları nasıl bulunur?
HTTP istek kaçakçılığı güvenlik açıklarını kendiniz nasıl tespit edeceğinize dair bazı ipuçları için aşağıdaki konumuza göz atın. Ayrıca, bunun pratikte nasıl çalıştığını görebilmeniz için bazı etkileşimli LABS'ler sağladık.
https://www.turkhackteam.org/konular/http-istek-kacakciligi-guvenlik-aciklarini-bulma.2047510/
HTTP istek kaçakçılığı güvenlik açıklarından nasıl yararlanılır?
Artık temel kavramlara aşina olduğunuza göre, HTTP istek kaçakçılığının bir dizi yüksek şiddetli saldırı oluşturmak için nasıl kullanılabileceğine bir göz atalım. Her zamanki gibi, gerçekçi hedeflere saldırmak için çok sayıda tamamen etkileşimli LABS vardır.
https://www.turkhackteam.org/konula...igi-guvenlik-aciklarindan-yararlanma.2047511/
HTTP istek kaçakçılığı güvenlik açıkları nasıl önlenir?
HTTP istek kaçakçılı güvenlik açıkları, front-end sunucusu ve back-end sunucusunun istekler arasındaki sınırları belirlemek için farklı mekanizmalar kullandığı durumlarda ortaya çıkar. Bunun nedeni, HTTP/1 sunucularının her bir isteğin nerede bittiğini belirlemek için Content-Length başlığını mı yoksa yığın aktarım kodlamasını mı kullandığı arasındaki tutarsızlıklar olabilir. HTTP/2 ortamlarında, back-end için HTTP/2 isteklerini düşürmeye yönelik yaygın uygulama da sorunlarla doludur ve bir dizi ek saldırıyı mümkün kılar veya basitleştirir.
HTTP istek kaçakçılığı güvenlik açıklarını önlemek için aşağıdaki üst düzey önlemleri öneririz:
- HTTP/2'yi uçtan uca kullanın ve mümkünse HTTP düşürmeyi devre dışı bırakın. HTTP/2, isteklerin uzunluğunu belirlemek için sağlam bir mekanizma kullanır ve uçtan uca kullanıldığında, istek kaçakçılığına karşı doğal olarak korunur. HTTP düşürmeyi engelleyemiyorsanız, yeniden yazılan isteği HTTP/1.1 spesifikasyonuna göre doğruladığınızdan emin olun. Örneğin, başlıklarda yeni satır, başlık adlarında iki nokta üst üste ve istek yönteminde boşluk içeren istekleri reddedin.
- Front-end sunucunun belirsiz istekleri normalleştirmesini ve back-end sunucunun hala belirsiz olanları reddetmesini ve bu süreçte TCP bağlantısını kapatmasını sağlayın.
- Asla isteklerin bir gövdesi olmayacağını varsaymayın. Bu, hem CL.0 hem de istemci tarafı desync güvenlik açıklarının temel nedenidir.
- İstekleri işlerken sunucu düzeyinde istisnalar tetiklenirse bağlantının atılmasını varsayılan olarak ayarlayın.
- Trafiği bir ileri proxy üzerinden yönlendiriyorsanız, mümkünse yukarı akış HTTP/2'nin etkinleştirildiğinden emin olun.
Eğitim materyallerinde gösterdiğimiz gibi, back-end bağlantılarının yeniden kullanımını devre dışı bırakmak belirli saldırı türlerini azaltmaya yardımcı olacaktır, ancak bu yine de sizi istek tünelleme saldırılarından korumaz.
