Jegand
Kayıtlı Üye
- Katılım
- 22 Şubat 2021
- Mesajlar
- 41
- Tepkime puanı
- 77
- İlgi Alanlarınız
- Web Uygulama Güvenliği
- Cinsiyet
-
- Erkek
HTTP request smuggling (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 etme tekniğidir. Talep kaçakçılığı güvenlik açıkları doğası gereği genellikle kritiktir ve bir saldırganın güvenlik denetimlerini atlamasına, hassas verilere yetkisiz erişim sağlamasına ve diğer uygulama kullanıcılarını doğrudan tehlikeye atmasına olanak tanır.
HTTP isteği kaçakçılığı saldırısında ne olur?
Günümüzün web uygulamaları, kullanıcılar ve nihai uygulama mantığı arasında sıklıkla HTTP sunucu zincirlerini kullanır. Kullanıcılar, istekleri bir ön uç sunucuya (bazen yük dengeleyici veya ters proxy olarak adlandırılır) gönderir ve bu sunucu, istekleri bir veya daha fazla arka uç sunucuya iletir. Bu tür bir mimari, modern bulut tabanlı uygulamalarda giderek daha yaygın ve bazı durumlarda kaçınılmaz hale geliyor.
Ön uç sunucu, HTTP isteklerini bir arka uç sunucuya ilettiğinde, genellikle aynı arka uç 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ı sunucu, bir isteğin nerede bitip diğerinin nerede başladığını belirlemek için HTTP istek başlıklarını ayrıştırır:
Bu durumda, ön uç ve arka uç sistemlerinin istekler arasındaki sınırlar konusunda hemfikir olması çok önemlidir. Aksi takdirde, bir saldırgan, ön uç ve arka uç sistemler tarafından farklı şekilde yorumlanan belirsiz bir istek gönderebilir:
Burada saldırgan, ön uç isteklerinin bir kısmının arka uç sunucusu tarafından bir sonraki isteğin başlangıcı olarak yorumlanmasına neden olur. Etkin bir şekilde sonraki talebe eklenir ve bu nedenle uygulamanın talebi işleme biçimine müdahale edebilir. Bu bir kaçakçılık saldırısıdır ve yıkıcı sonuçları olabilir.
HTTP istek kaçakçılığı güvenlik açıkları nasıl ortaya çıkar?
Content-Length üstbilgisi basittir: ileti gövdesinin uzunluğunu bayt cinsinden belirtir. Örneğin:
POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
q=smuggling
Transfer-Encoding başlığı, mesaj gövdesinin parçalı 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 yığın, bayt cinsinden yığın boyutundan (onaltılık olarak ifade edilir), ardından bir satırsonu ve ardından yığın içeriğinden oluşur. Mesaj, sıfır boyutunda bir yığınla sonlandırılır. Örneğin:
POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
b
q=smuggling
0
HTTP belirtimi, HTTP mesajlarının uzunluğunu belirtmek için iki farklı yöntem sağladığından, tek bir mesajın aynı anda her iki yöntemi de kullanması mümkündür, böylece birbirleriyle çakışırlar. HTTP belirtimi, hem Content-Length hem de Transfer-Encoding üstbilgilerinin mevcut olması durumunda Content-Length üstbilgisinin yok sayılması gerektiğini belirterek bu sorunu önlemeye çalışır. Bu, yalnızca tek bir sunucu oyundayken belirsizliği önlemek için yeterli olabilir, ancak iki veya daha fazla sunucu birbirine zincirlendiğinde değil. 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 karartılmışsa bunu işlememeye teşvik edilebilir.
Ön uç ve arka uç sunucuları (muhtemelen gizlenmiş olan) Transfer-Encoding başlığıyla ilişkili olarak farklı davranırsa, birbirini izleyen istekler arasındaki sınırlar konusunda anlaşamayabilir ve bu da kaçakçılık güvenlik açıklarının talep edilmesine neden olabilir.
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şleyebilmesi için değiştirmeyi içerir. Bunun tam olarak nasıl yapılacağı, iki sunucunun davranışına bağlıdır:
• CL.TE: ön uç sunucusu Content-Length başlığını kullanır ve arka uç sunucusu, Transfer-Encoding başlığını kullanır.
• TE.CL: ön uç sunucusu Transfer-Encoding başlığını kullanır ve arka uç sunucusu Content-Length başlığını kullanır.
• TE.TE: Ön uç ve arka uç sunucuların her ikisi de Transfer-Encoding başlığını destekler, ancak sunuculardan biri başlığı bir şekilde gizleyerek onu işlememeye teşvik edilebilir.
CL.TE güvenlik açıkları
Burada, ön uç sunucusu Content-Length başlığını kullanır ve arka uç sunucusu, Transfer-Encoding başlığını kullanır. Basit bir HTTP isteği kaçakçılığı saldırısı şu şekilde gerçekleştirebiliriz:
POST / HTTP/1.1
Host: zafiyetli-website.com
Content-Length: 13
Transfer-Encoding: chunked
0
SMUGGLED
Ön uç 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 arka uç sunucuya iletilir.
Arka uç sunucusu, Transfer-Encoding başlığını işler ve bu nedenle ileti gövdesine yığınlanmış kodlama kullanıyormuş gibi davranır. Sıfır uzunlukta olduğu belirtilen ilk parçayı işler ve bu nedenle isteği sonlandırıyormuş gibi değerlendirilir. Aşağıdaki baytlar, SMUGGLED, işlenmeden bırakılır ve arka uç sunucusu, bunları sıradaki bir sonraki isteğin başlangıcı olarak ele alır.
TE.CL güvenlik açıkları
Burada, ön uç sunucusu Transfer-Encoding başlığını kullanır ve arka uç sunucusu Content-Length başlığını kullanır. Basit bir HTTP isteği kaçakçılığı saldırısı şu şekilde gerçekleştirebiliriz:
POST / HTTP/1.1
Host: zafiyetli-website.com
Content-Length: 3
Transfer-Encoding: chunked
8
SMUGGLED
0
Ön uç sunucu, Transfer-Encoding başlığını işler ve bu nedenle ileti gövdesine yığınlanmış kodlama kullanıyormuş gibi davranır. SMUGGLED'i takip eden satırın başlangıcına kadar 8 bayt uzunluğunda olduğu belirtilen ilk parçayı işler. Sıfır uzunlukta olduğu belirtilen ikinci parçayı işler ve bu nedenle isteği sonlandırıyormuş gibi değerlendirilir. Bu istek arka uç sunucuya iletilir.
Arka uç 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 aşağıdaki baytlar işlenmemiş olarak bırakılır ve arka uç sunucusu bunları sıradaki bir sonraki isteğin başlangıcı olarak ele alacaktır.
TE.TE davranışı: TE başlığını gizleme
Burada, ön uç ve arka uç sunucuların her ikisi de Transfer-Encoding başlığını destekler, ancak sunuculardan biri başlığı bir şekilde gizleyerek bunu işlememeye teşvik edilebilir.
Transfer-Encoding başlığını gizlemenin potansiyel olarak sonsuz yolları vardır. Örneğin:
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
: chunked
Bu tekniklerin her biri, HTTP spesifikasyonundan ince bir ayrımı içerir. Bir protokol spesifikasyonunu uygulayan gerçek dünya kodu, buna nadiren mutlak bir hassasiyetle 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 bazı varyasyonlarını bulmak gerekir, öyle ki ön uç veya arka uç sunuculardan yalnızca biri onu işlerken, diğer sunucu bunu görmezden gelir.
Karartılmış Transfer-Encoding başlığını işlememeye teşvik edilebilecek ön uç veya arka uç sunucu olmasına bağlı olarak, tarif edildigi gibi saldırının geri kalanı CL.TE veya TE.CL güvenlik açıkları ile aynı biçimde olacaktır.
HTTP istek kaçakçılığı güvenlik açıkları nasıl önlenir?
HTTP istek kaçakçılığı güvenlik açıkları, bir ön uç sunucunun birden çok isteği aynı ağ bağlantısı üzerinden bir arka uç sunucuya ilettiği ve arka uç bağlantıları için kullanılan protokolün, iki sunucunun aralarındaki sınırlar konusunda anlaşmazlık riski taşıdığı durumlarda ortaya çıkar. HTTP istek kaçakçılığı güvenlik açıklarını önlemenin bazı genel yolları aşağıdaki gibidir:
• Her arka uç isteğinin ayrı bir ağ bağlantısı üzerinden gönderilmesi için arka uç bağlantılarının yeniden kullanımını devre dışı bırakın.
• Bu protokol, istekler arasındaki sınırlarla ilgili belirsizliği önlediğinden, arka uç bağlantıları için HTTP / 2 kullanın.
• Ön uç ve arka uç sunucular için tam olarak aynı web sunucusu yazılımını kullanın, böylece istekler arasındaki sınırlar konusunda hemfikir olurlar.
Bazı durumlarda, ön uç sunucunun belirsiz istekleri normalleştirmesini sağlayarak 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 potansiyel olarak yukarıda tanımlanan genel azaltımlardan daha fazla hataya eğilimlidir.
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 etme tekniğidir. Talep kaçakçılığı güvenlik açıkları doğası gereği genellikle kritiktir ve bir saldırganın güvenlik denetimlerini atlamasına, hassas verilere yetkisiz erişim sağlamasına ve diğer uygulama kullanıcılarını doğrudan tehlikeye atmasına olanak tanır.
HTTP isteği kaçakçılığı saldırısında ne olur?
Günümüzün web uygulamaları, kullanıcılar ve nihai uygulama mantığı arasında sıklıkla HTTP sunucu zincirlerini kullanır. Kullanıcılar, istekleri bir ön uç sunucuya (bazen yük dengeleyici veya ters proxy olarak adlandırılır) gönderir ve bu sunucu, istekleri bir veya daha fazla arka uç sunucuya iletir. Bu tür bir mimari, modern bulut tabanlı uygulamalarda giderek daha yaygın ve bazı durumlarda kaçınılmaz hale geliyor.
Ön uç sunucu, HTTP isteklerini bir arka uç sunucuya ilettiğinde, genellikle aynı arka uç 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ı sunucu, bir isteğin nerede bitip diğerinin nerede başladığını belirlemek için HTTP istek başlıklarını ayrıştırır:
Bu durumda, ön uç ve arka uç sistemlerinin istekler arasındaki sınırlar konusunda hemfikir olması çok önemlidir. Aksi takdirde, bir saldırgan, ön uç ve arka uç sistemler tarafından farklı şekilde yorumlanan belirsiz bir istek gönderebilir:
Burada saldırgan, ön uç isteklerinin bir kısmının arka uç sunucusu tarafından bir sonraki isteğin başlangıcı olarak yorumlanmasına neden olur. Etkin bir şekilde sonraki talebe eklenir ve bu nedenle uygulamanın talebi işleme biçimine müdahale edebilir. Bu bir kaçakçılık saldırısıdır ve yıkıcı sonuçları olabilir.
HTTP istek kaçakçılığı güvenlik açıkları nasıl ortaya çıkar?
Content-Length üstbilgisi basittir: ileti gövdesinin uzunluğunu bayt cinsinden belirtir. Örneğin:
POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
q=smuggling
Transfer-Encoding başlığı, mesaj gövdesinin parçalı 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 yığın, bayt cinsinden yığın boyutundan (onaltılık olarak ifade edilir), ardından bir satırsonu ve ardından yığın içeriğinden oluşur. Mesaj, sıfır boyutunda bir yığınla sonlandırılır. Örneğin:
POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
b
q=smuggling
0
HTTP belirtimi, HTTP mesajlarının uzunluğunu belirtmek için iki farklı yöntem sağladığından, tek bir mesajın aynı anda her iki yöntemi de kullanması mümkündür, böylece birbirleriyle çakışırlar. HTTP belirtimi, hem Content-Length hem de Transfer-Encoding üstbilgilerinin mevcut olması durumunda Content-Length üstbilgisinin yok sayılması gerektiğini belirterek bu sorunu önlemeye çalışır. Bu, yalnızca tek bir sunucu oyundayken belirsizliği önlemek için yeterli olabilir, ancak iki veya daha fazla sunucu birbirine zincirlendiğinde değil. 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 karartılmışsa bunu işlememeye teşvik edilebilir.
Ön uç ve arka uç sunucuları (muhtemelen gizlenmiş olan) Transfer-Encoding başlığıyla ilişkili olarak farklı davranırsa, birbirini izleyen istekler arasındaki sınırlar konusunda anlaşamayabilir ve bu da kaçakçılık güvenlik açıklarının talep edilmesine neden olabilir.
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şleyebilmesi için değiştirmeyi içerir. Bunun tam olarak nasıl yapılacağı, iki sunucunun davranışına bağlıdır:
• CL.TE: ön uç sunucusu Content-Length başlığını kullanır ve arka uç sunucusu, Transfer-Encoding başlığını kullanır.
• TE.CL: ön uç sunucusu Transfer-Encoding başlığını kullanır ve arka uç sunucusu Content-Length başlığını kullanır.
• TE.TE: Ön uç ve arka uç sunucuların her ikisi de Transfer-Encoding başlığını destekler, ancak sunuculardan biri başlığı bir şekilde gizleyerek onu işlememeye teşvik edilebilir.
CL.TE güvenlik açıkları
Burada, ön uç sunucusu Content-Length başlığını kullanır ve arka uç sunucusu, Transfer-Encoding başlığını kullanır. Basit bir HTTP isteği kaçakçılığı saldırısı şu şekilde gerçekleştirebiliriz:
POST / HTTP/1.1
Host: zafiyetli-website.com
Content-Length: 13
Transfer-Encoding: chunked
0
SMUGGLED
Ön uç 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 arka uç sunucuya iletilir.
Arka uç sunucusu, Transfer-Encoding başlığını işler ve bu nedenle ileti gövdesine yığınlanmış kodlama kullanıyormuş gibi davranır. Sıfır uzunlukta olduğu belirtilen ilk parçayı işler ve bu nedenle isteği sonlandırıyormuş gibi değerlendirilir. Aşağıdaki baytlar, SMUGGLED, işlenmeden bırakılır ve arka uç sunucusu, bunları sıradaki bir sonraki isteğin başlangıcı olarak ele alır.
TE.CL güvenlik açıkları
Burada, ön uç sunucusu Transfer-Encoding başlığını kullanır ve arka uç sunucusu Content-Length başlığını kullanır. Basit bir HTTP isteği kaçakçılığı saldırısı şu şekilde gerçekleştirebiliriz:
POST / HTTP/1.1
Host: zafiyetli-website.com
Content-Length: 3
Transfer-Encoding: chunked
8
SMUGGLED
0
Ön uç sunucu, Transfer-Encoding başlığını işler ve bu nedenle ileti gövdesine yığınlanmış kodlama kullanıyormuş gibi davranır. SMUGGLED'i takip eden satırın başlangıcına kadar 8 bayt uzunluğunda olduğu belirtilen ilk parçayı işler. Sıfır uzunlukta olduğu belirtilen ikinci parçayı işler ve bu nedenle isteği sonlandırıyormuş gibi değerlendirilir. Bu istek arka uç sunucuya iletilir.
Arka uç 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 aşağıdaki baytlar işlenmemiş olarak bırakılır ve arka uç sunucusu bunları sıradaki bir sonraki isteğin başlangıcı olarak ele alacaktır.
TE.TE davranışı: TE başlığını gizleme
Burada, ön uç ve arka uç sunucuların her ikisi de Transfer-Encoding başlığını destekler, ancak sunuculardan biri başlığı bir şekilde gizleyerek bunu işlememeye teşvik edilebilir.
Transfer-Encoding başlığını gizlemenin potansiyel olarak sonsuz yolları vardır. Örneğin:
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
: chunked
Bu tekniklerin her biri, HTTP spesifikasyonundan ince bir ayrımı içerir. Bir protokol spesifikasyonunu uygulayan gerçek dünya kodu, buna nadiren mutlak bir hassasiyetle 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 bazı varyasyonlarını bulmak gerekir, öyle ki ön uç veya arka uç sunuculardan yalnızca biri onu işlerken, diğer sunucu bunu görmezden gelir.
Karartılmış Transfer-Encoding başlığını işlememeye teşvik edilebilecek ön uç veya arka uç sunucu olmasına bağlı olarak, tarif edildigi gibi saldırının geri kalanı CL.TE veya TE.CL güvenlik açıkları ile aynı biçimde olacaktır.
HTTP istek kaçakçılığı güvenlik açıkları nasıl önlenir?
HTTP istek kaçakçılığı güvenlik açıkları, bir ön uç sunucunun birden çok isteği aynı ağ bağlantısı üzerinden bir arka uç sunucuya ilettiği ve arka uç bağlantıları için kullanılan protokolün, iki sunucunun aralarındaki sınırlar konusunda anlaşmazlık riski taşıdığı durumlarda ortaya çıkar. HTTP istek kaçakçılığı güvenlik açıklarını önlemenin bazı genel yolları aşağıdaki gibidir:
• Her arka uç isteğinin ayrı bir ağ bağlantısı üzerinden gönderilmesi için arka uç bağlantılarının yeniden kullanımını devre dışı bırakın.
• Bu protokol, istekler arasındaki sınırlarla ilgili belirsizliği önlediğinden, arka uç bağlantıları için HTTP / 2 kullanın.
• Ön uç ve arka uç sunucular için tam olarak aynı web sunucusu yazılımını kullanın, böylece istekler arasındaki sınırlar konusunda hemfikir olurlar.
Bazı durumlarda, ön uç sunucunun belirsiz istekleri normalleştirmesini sağlayarak 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 potansiyel olarak yukarıda tanımlanan genel azaltımlardan daha fazla hataya eğilimlidir.
