Şu ana kadar bahsettiğimiz istek kaçakçılığı saldırılarının çoğu, yalnızca front-end ve back-end arasındaki aynı bağlantının birden fazla isteği işlemesi nedeniyle mümkündür. Bazı sunucular herhangi bir istek için bağlantıyı yeniden kullansa da diğerlerinin daha katı kuralları vardır.
Örneğin, bazı sunucular yalnızca aynı IP adresinden veya aynı istemciden gelen isteklerin bağlantıyı yeniden kullanmasına izin verir. Diğerleri bağlantıyı hiçbir şekilde yeniden kullanmayacaktır; bu da, diğer kullanıcıların trafiğini etkilemenin açık bir yolunun olmaması nedeniyle klasik istek kaçakçılığı yoluyla elde edebileceklerinizi sınırlamaktadır.
Soketı diğer kullanıcıların isteklerine müdahale edecek şekilde manipüle edemeseniz de, back-end'den iki yanıt alacak tek bir istek gönderebilirsiniz. Bu potansiyel olarak bir isteği ve onunla eşleşen yanıtı ön uçtan tamamen gizlemenize olanak tanır.
Belirli istekleri göndermenizi engelleyebilecek front-end güvenlik önlemlerini atlatmak için bu tekniği kullanabilirsiniz. Aslında istek sahteciliğini önlemek için özel olarak tasarlanmış bazı mekanizmalar bile istek tünellemeyi durdurmada başarısız olabilmektedir.
İsteklerin bu şekilde back-end'e tünellenmesi, istek sahteciliğinin daha sınırlı bir biçimini sunar, ancak yine de ne yaptığını bilen saldırganların ellerinde çok tehlikeli saldırılara yol açabilir.
HTTP/2 ile Request Tüneli Oluşturma
İstek tünellemesi hem HTTP/1 hem de HTTP/2 ile mümkündür ancak HTTP/1 ortamlarında tespit edilmesi çok daha zordur. Kalıcı bağlantıların HTTP/1'de çalışma şekli nedeniyle, iki yanıt alsanız bile bu, isteğin başarılı bir şekilde kaçırıldığı anlamına gelmez.
Öte yandan HTTP/2'de her "akış" yalnızca tek bir istek ve yanıt içermelidir. Gövdede HTTP/1 yanıtı gibi görünen bir HTTP/2 yanıtı alırsanız, ikinci isteği başarıyla tünellediğinizden emin olabilirsiniz.
HTTP/2 Request Tüneli aracılığıyla dahili başlıkların sızdırılması
Tek seçeneğiniz istek tünelleme olduğunda, önceki laboratuvarlarımızdan birinde ele aldığımız tekniği kullanarak dahili başlıkları sızdıramazsınız ancak HTTP/2'de sürüm düşürme alternatif bir çözüm sağlar.
Potansiyel olarak front-end'i kandırarak, arka uçta bir gövde parametresi haline gelecek dahili başlıkların içine eklenmesini sağlayabilirsiniz. Diyelim ki şuna benzer bir istek gönderdik:
Bu durumda hem front-end hem de back-end yalnızca bir istek olduğu konusunda hemfikirdir. İlginç olan, başlıkların nerede bittiği konusunda anlaşmazlığa düşebilmeleridir.
Front-end, bir başlığın parçası olarak enjekte ettiğimiz her şeyi görür, bu nedenle yeni başlıkları sondaki comment= dizesinden sonra ekler. Öte yandan back-end ise \r\n\r\n dizisini görür ve bunun başlıkların sonu olduğunu düşünür. comment= dizesi, dahili başlıklarla birlikte gövdenin bir parçası olarak kabul edilir. Sonuç, değeri dahili başlıkları olan bir comment parametresidir.
Kör Request Tünelleme
Bazı front-end sunucular, back-end'den aldıkları tüm verileri okur. Bu, bir isteği başarılı bir şekilde tünellemeniz durumunda ana yanıtın gövdesi içine yerleştirilmiş tünellenmiş isteğe verilen yanıtla birlikte potansiyel olarak her iki yanıtı da istemciye iletecekleri anlamına gelir.
Diğer front-end sunucular yalnızca yanıtın Content-Length başlığında belirtilen bayt sayısını okur, dolayısıyla istemciye yalnızca ilk yanıt iletilir. Bu, tünellenmiş isteğinize verilen yanıtı göremeyeceğiniz için kör istek tünelleme güvenlik açığına neden olur.
HEAD kullanarak kör olmayan request tünelleme
Kör istek tünelini kullanmak zor olabilir ancak bazen HEAD isteklerini kullanarak bu güvenlik açıklarını kör olmayan hale getirebilirsiniz.
HEAD isteklerine verilen yanıtlar, kendilerine ait bir gövdeye sahip olmasalar bile genellikle içerik uzunluğunda bir başlık içerir. Bu normalde bir GET isteği tarafından aynı uç noktaya döndürülecek kaynağın uzunluğunu ifade eder. Bazı front-end sunucular bunu hesaba katmaz ve ne olursa olsun başlıkta belirtilen byte sayısını okumaya çalışır. Bir isteği, bunu yapan bir front-end sunucusundan başarıyla geçirirseniz bu davranış, sunucunun arka uçtan gelen yanıtı aşırı okumasına neden olabilir. Sonuç olarak, aldığınız yanıt, tünellenmiş isteğinize verilen yanıtın başlangıcından itibaren baytlar içerebilir.
Istek:
Yanıt:
Bir yanıtın içerik uzunluğu başlığını diğerinin gövdesiyle etkili bir şekilde karıştırdığınızdan dolayı bu tekniği başarıyla kullanmak biraz dengeleme eylemidir.
HEAD isteğinizi gönderdiğiniz uç nokta, okumaya çalıştığınız tünel yanıtından daha kısa bir kaynak döndürürse, yukarıdaki örnekte olduğu gibi ilginç bir şey göremeden bu kaynak kesilebilir. Öte yandan, döndürülen içerik uzunluğu tünellenmiş isteğinize verilen yanıttan daha uzunsa front-end sunucusunun back-end'den ek baytların gelmesini beklemesi nedeniyle büyük olasılıkla bir zaman aşımı ile karşılaşacaksınız.
Neyse ki, biraz deneme yanılma ile aşağıdaki çözümlerden birini kullanarak bu sorunların üstesinden gelebilirsiniz:
Örneğin, bazı sunucular yalnızca aynı IP adresinden veya aynı istemciden gelen isteklerin bağlantıyı yeniden kullanmasına izin verir. Diğerleri bağlantıyı hiçbir şekilde yeniden kullanmayacaktır; bu da, diğer kullanıcıların trafiğini etkilemenin açık bir yolunun olmaması nedeniyle klasik istek kaçakçılığı yoluyla elde edebileceklerinizi sınırlamaktadır.
Soketı diğer kullanıcıların isteklerine müdahale edecek şekilde manipüle edemeseniz de, back-end'den iki yanıt alacak tek bir istek gönderebilirsiniz. Bu potansiyel olarak bir isteği ve onunla eşleşen yanıtı ön uçtan tamamen gizlemenize olanak tanır.
Belirli istekleri göndermenizi engelleyebilecek front-end güvenlik önlemlerini atlatmak için bu tekniği kullanabilirsiniz. Aslında istek sahteciliğini önlemek için özel olarak tasarlanmış bazı mekanizmalar bile istek tünellemeyi durdurmada başarısız olabilmektedir.
İsteklerin bu şekilde back-end'e tünellenmesi, istek sahteciliğinin daha sınırlı bir biçimini sunar, ancak yine de ne yaptığını bilen saldırganların ellerinde çok tehlikeli saldırılara yol açabilir.
HTTP/2 ile Request Tüneli Oluşturma
İstek tünellemesi hem HTTP/1 hem de HTTP/2 ile mümkündür ancak HTTP/1 ortamlarında tespit edilmesi çok daha zordur. Kalıcı bağlantıların HTTP/1'de çalışma şekli nedeniyle, iki yanıt alsanız bile bu, isteğin başarılı bir şekilde kaçırıldığı anlamına gelmez.
Öte yandan HTTP/2'de her "akış" yalnızca tek bir istek ve yanıt içermelidir. Gövdede HTTP/1 yanıtı gibi görünen bir HTTP/2 yanıtı alırsanız, ikinci isteği başarıyla tünellediğinizden emin olabilirsiniz.
HTTP/2 Request Tüneli aracılığıyla dahili başlıkların sızdırılması
Tek seçeneğiniz istek tünelleme olduğunda, önceki laboratuvarlarımızdan birinde ele aldığımız tekniği kullanarak dahili başlıkları sızdıramazsınız ancak HTTP/2'de sürüm düşürme alternatif bir çözüm sağlar.
Potansiyel olarak front-end'i kandırarak, arka uçta bir gövde parametresi haline gelecek dahili başlıkların içine eklenmesini sağlayabilirsiniz. Diyelim ki şuna benzer bir istek gönderdik:
HTML:
:method POST
:path /comment
:authority vulnerable-website.com
content-type application/x-www-form-urlencoded
foo
bar\r\n
Content-Length: 200\r\n
\r\n
comment=
x=1Bu durumda hem front-end hem de back-end yalnızca bir istek olduğu konusunda hemfikirdir. İlginç olan, başlıkların nerede bittiği konusunda anlaşmazlığa düşebilmeleridir.
Front-end, bir başlığın parçası olarak enjekte ettiğimiz her şeyi görür, bu nedenle yeni başlıkları sondaki comment= dizesinden sonra ekler. Öte yandan back-end ise \r\n\r\n dizisini görür ve bunun başlıkların sonu olduğunu düşünür. comment= dizesi, dahili başlıklarla birlikte gövdenin bir parçası olarak kabul edilir. Sonuç, değeri dahili başlıkları olan bir comment parametresidir.
HTML:
POST /comment HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 200
comment=X-Internal-Header: secretContent-Length: 3
x=1Kör Request Tünelleme
Bazı front-end sunucular, back-end'den aldıkları tüm verileri okur. Bu, bir isteği başarılı bir şekilde tünellemeniz durumunda ana yanıtın gövdesi içine yerleştirilmiş tünellenmiş isteğe verilen yanıtla birlikte potansiyel olarak her iki yanıtı da istemciye iletecekleri anlamına gelir.
Diğer front-end sunucular yalnızca yanıtın Content-Length başlığında belirtilen bayt sayısını okur, dolayısıyla istemciye yalnızca ilk yanıt iletilir. Bu, tünellenmiş isteğinize verilen yanıtı göremeyeceğiniz için kör istek tünelleme güvenlik açığına neden olur.
HEAD kullanarak kör olmayan request tünelleme
Kör istek tünelini kullanmak zor olabilir ancak bazen HEAD isteklerini kullanarak bu güvenlik açıklarını kör olmayan hale getirebilirsiniz.
HEAD isteklerine verilen yanıtlar, kendilerine ait bir gövdeye sahip olmasalar bile genellikle içerik uzunluğunda bir başlık içerir. Bu normalde bir GET isteği tarafından aynı uç noktaya döndürülecek kaynağın uzunluğunu ifade eder. Bazı front-end sunucular bunu hesaba katmaz ve ne olursa olsun başlıkta belirtilen byte sayısını okumaya çalışır. Bir isteği, bunu yapan bir front-end sunucusundan başarıyla geçirirseniz bu davranış, sunucunun arka uçtan gelen yanıtı aşırı okumasına neden olabilir. Sonuç olarak, aldığınız yanıt, tünellenmiş isteğinize verilen yanıtın başlangıcından itibaren baytlar içerebilir.
Istek:
HTML:
:method HEAD
:path /example
:authority vulnerable-website.com
foo
bar\r\n
\r\n
GET /tunnelled HTTP/1.1\r\n
Host: vulnerable-website.com\r\n
X: xYanıt:
HTML:
:status 200
content-type text/html
content-length 131
*******************************
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 4286
<!DOCTYPE html>
<h1>Tunnelled</h1>
<p>This is a tunnelled respoBir yanıtın içerik uzunluğu başlığını diğerinin gövdesiyle etkili bir şekilde karıştırdığınızdan dolayı bu tekniği başarıyla kullanmak biraz dengeleme eylemidir.
HEAD isteğinizi gönderdiğiniz uç nokta, okumaya çalıştığınız tünel yanıtından daha kısa bir kaynak döndürürse, yukarıdaki örnekte olduğu gibi ilginç bir şey göremeden bu kaynak kesilebilir. Öte yandan, döndürülen içerik uzunluğu tünellenmiş isteğinize verilen yanıttan daha uzunsa front-end sunucusunun back-end'den ek baytların gelmesini beklemesi nedeniyle büyük olasılıkla bir zaman aşımı ile karşılaşacaksınız.
Neyse ki, biraz deneme yanılma ile aşağıdaki çözümlerden birini kullanarak bu sorunların üstesinden gelebilirsiniz:
- HEAD isteğinizi gerektiği gibi daha uzun veya daha kısa bir kaynak döndüren farklı bir uç noktaya yönlendirin.
- Kaynak çok kısaysa, isteğe bağlı dolgu karakterleri eklemek için ana HEAD isteğinde yansıtılan bir giriş kullanın. Girişinizin gerçekte yansıtıldığını görmeseniz bile, döndürülen içerik uzunluğu yine de buna göre artacaktır.
- Kaynak çok uzunsa, tünellenmiş yanıtın uzunluğunun beklenen içeriğin uzunluğuyla eşleşmesi veya bu uzunluğu aşması için rastgele karakterler eklemek üzere tünellenmiş istekte yansıtılmış bir giriş kullanın.
HTTP/2 request tünellemesi üzerinden web önbelleği manipülasyonu
İstek tünellemesi genellikle klasik istek kaçakçılığından daha sınırlı olsa da bazen yine de yüksek önem derecesine sahip saldırılar oluşturabilirsiniz. Örneğin, web önbellek manipülasyonunun ekstra güçlü bir biçimi için şu ana kadar incelediğimiz istek tünelleme tekniklerini birleştirebilirsiniz.
Kör olmayan istek tünellemeyle, bir yanıtın başlıklarını diğerinin gövdesiyle etkili bir şekilde karıştırıp eşleştirebilirsiniz. Gövdedeki yanıt kodlanmamış kullanıcı girişini yansıtıyorsa, tarayıcının normalde kodu yürütmeyeceği bağlamlarda yansıtılan XSS için bu davranıştan yararlanabilirsiniz.
Örneğin, aşağıdaki yanıt kodlanmamış, saldırgan tarafından kontrol edilebilen girdi içerir:
HTML:
HTTP/1.1 200 OK
Content-Type: application/json
{ "name" : "test<script>alert(1)</script>" }
[etc.]Tek başına bu nispeten zararsızdır. Content-Type, bu payload'ın tarayıcı tarafından basitçe JSON olarak yorumlanacağı anlamına gelir. Ancak isteği back-end'e yönlendirirseniz ne olacağını düşünün. Bu yanıt, farklı bir yanıtın gövdesinde görünecek ve içerik türü de dahil olmak üzere başlıklarını etkili bir şekilde devralacaktır.
Önbellekleme front-end'de gerçekleştiğinden, önbellekler de bu karışık yanıtları diğer kullanıcılara sunmak üzere kandırılabilir.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Çevirmen: @Dolyetyus
Kaynak: HTTP request tunnelling | Web Security Academy
