Yapay zekadan makale özeti
- Kısa
- Ayrıntılı
- Bu video, bir eğitmen tarafından sunulan teknik bir eğitim içeriğidir. Eğitmen, HTTP protokolünde yaşanan request smuggling (HTTP istek karıştırma) güvenlik açığını detaylı şekilde anlatmaktadır.
- Video, HTTP protokolünün yapısını, request smuggling zafiyetinin nasıl çalıştığını ve HTTP 1.1 ile HTTP 2.0 arasındaki farkları açıklamaktadır. Eğitmen, load balancer ve app server arasındaki protokol dönüşümünü, transfer encoding ve content length header'larının önemini ve bu zafiyet sayesinde nasıl güvenlik açığı yaratılabileceğini anlatmaktadır.
- Videoda ayrıca Netflix örneği üzerinden request injection ve redirection zafiyetleri, HTTP 2'den HTTP 1'e downgrade yapıldığında oluşan zafiyetler ve TCP session'ları üzerinde durulmaktadır. Eğitmen, konuyu teorik olarak anlattıktan sonra, bir sonraki yayında uygulamalı olarak ele alacaklarını belirtmektedir.
- HTTP Request Smaging Zafiyeti
- İki sene kadar önce James Cattle tarafından yapılan "HTTP Request Smaging" adlı araştırma, web zafiyeti kategorisine giren ancak web uygulaması ile doğrudan ilgili olmayan bir konudur.
- Bu zafiyet, HTTP protokolünün RFC'si (kitaptaki tanımı) ve implementasyonlarının farklı yorumlamasından kaynaklanmaktadır.
- Aynı HTTP requesti farklı implementasyonlar tarafından farklı şekilde yorumlanmaktadır.
- 01:17HTTP Request Süreci
- Bir HTTP request bilgisayardan çıkıp, ön tarafta load balancer, arka tarafta ise app server (örneğin Nginx veya Tomcat) tarafından karşılanır.
- Load balancer, gelen requesti arka taraftaki app server'a yönlendirir ve cevap tekrar aynı yoldan geri döner.
- HTTP protokolünün yapısı, HTTP 1.0 ve 1.1 versiyonlarında bu şekilde çalışır.
- 02:02Load Balancer ve App Server Arasındaki Farklar
- Load balancer, kurumların enterprise kurumlarında kullandığı F5, Amazon'un Elastic Load Balancer servisi, Cloud Front ve Cloudflare gibi CDN hizmetleridir.
- Load balancer, HTTP requestini yorumlayıp ne yapacağını karar verir ve bu requesti arka taraftaki app server'a iletir.
- İki kod (load balancer ve app server) aynı şeyi farklı şekilde implement etmiş olup, HTTP'nin RFC'sini farklı yorumlamışlardır.
- 02:58Request Smaging Zafiyetinin Temelindeki Sorun
- Farklı yorumlamadan kaynaklanan temel zafiyet, özel bir request hazırlayıp load balancer'ın bunu X olarak, arka taraftaki engine'in ise Y olarak yorumlamasıdır.
- Bu araştırma 2018 veya 2019 yılında James Cattle tarafından yapılmıştır.
- HTTP request'i gönderildiğinde, browser'dan gelen request ve alınan cevap arasında bir ilişki vardır.
- 04:48TCP Oturumu ve HTTP Protokolü
- Browser ve web sunucusu arasında TCP oturumu kurulur ve üç yönlü bağlantı (three way handshake) tamamlanır.
- HTTP protokolü bir text transfer protokolüdür ve TCP oturumunun içerisinde HTTP requesti gönderilir.
- TCP paketleri karşı tarafa gönderilir ve tüm paketler gelene kadar beklenir, ardından tüm datalar peş peşe yazılır ve iki newline görüldüğünde request tamamlanmış olur.
- 07:25HTTP Request ve Cevap Süreci
- HTTP kütüphanesi, gelen verileri işleyip cevap döndürür ve bu cevap alana kadar ikinci request gönderilemez.
- TCP 2.0'da bu durum farklıdır ve HTTPS olursa da trafik deccate edildikten sonra aynı süreç yaşanır.
- HTTP requestlerinde content length ve transfer encoding adlı iki header bulunur ve gelen header'daki değere göre HTTP servisi davranış gerçekleştirir.
- 09:44Zafiyetin Önemi
- Content length ve transfer encoding header'ları bir arada varsa, bununla ilgili net bir kural olmadığı için HTTP servisini implemente eden kişiler kendi kurallarını üretir.
- Bu kurallar arasında farklılık olursa, sistemde zafiyet oluşur.
- Bu araştırma, web security dünyasında tıp dünyasındaki CRISPR gibi en büyük "ground breaking" (temel kırma) araştırma olarak değerlendirilmektedir.
- 10:45Request Smagling Güvenlik Açığı
- Transfer encoding ve content lang header'ları arasındaki çakışma, ön taraftaki alanın content lang'e göre pars edilmesi ve bu parslama sonrası yeni bir HTTP request olarak algılanmasıyla güvenlik açığı oluşturuyor.
- Bu güvenlik açığı, request injection yaparak başka bir request enjekte etme imkanı sağlıyor ve bu sayede başka kullanıcılara dönen response'lara müdahale edilebiliyor.
- Güvenlik açığının fixi, ön taraftaki ve arka taraftaki sistemin aynı kitaptan aynı anlamı çıkarması gerekiyor.
- 14:25HTTP ve HTTP2 Protokolleri Arasındaki Farklar
- HTTP ve HTTP2 protokolleri alt katmanda TCP protokolünü kullanır, ancak HTTP2'de request'lerin içerisine bir adet ID yerleştirilerek asenkronizasyon sağlanıyor.
- HTTP2'de request'in nerede bittiğini kontrol etmek için content lang'e bakmaya gerek yok, protokol bazında frame'lerin içerisinde bitfice kaç byte okunacağı yazıyor.
- HTTP2'de request smagling gibi bir güvenlik açığı yok, çünkü HTTP2 protokolünde frame'lerin bitfice kontrolü daha sıkı yapılmış.
- 22:56HTTP Protokol Dönüşümü Sorunu
- Konuşmacı, bir araştırma hakkında bilgi veriyor ve bu konuda farklı bir yaklaşım sunuyor.
- Sistemde requesti gönderen kişi, load balancer ve uygulama bulunuyor.
- Load balancer HTTP 2.0 destekliyorsa, arka taraftaki sistem de HTTP 2.0 desteklemeli mi yoksa HTTP 1.0 veya 1.1 mi?
- 24:16HTTP Protokol Dönüşümü Zorlukları
- Load balancer, HTTP 2.0 request'i alıp sıfırdan HTTP 1.0 veya 1.1'e dönüştürebilir.
- Bu durumda, developer HTTP 2.0 ile alınan request'i HTTP 1.0 veya 1.1'e dönüştürmek zorunda kalır.
- Bu durum, HTTP request smogling ve desenkronization zafiyeti gibi sorunlara yol açabilir.
- 25:55Netflix'in HTTP 2.0 Uygulaması
- Netflix'in HTTP 2.0 uygulamasını zorlaması, binlerce uygulamanın önündeki engine x'leri ve native process'leri HTTP 2.0'a geçirmek zorluğundan kaynaklanıyor.
- İnternet tarafında hız önemli olduğu için Netflix HTTP 2.0 destek etmek isteyebilir.
- HTTP 1.0 ile HTTP 2.0 arasındaki temel fark, stream ID'si olarak belirtiliyor.
- 27:28HTTP 2.0 Downgrade Zafiyeti
- HTTP 2.0 request'i Netflix'e gönderildiğinde, HTTP 2.0'dan HTTP 1.0 veya 1.1'e dönüştürme işlemi gerçekleşiyor.
- HTTP 2.0 spesifikasyonu content length alanına ihtiyaç duymaz çünkü frame size olarak hesaplanır.
- Netflix, Jet'nin HTTP 2.0 implamentasyonunu kullanıyor ve HTTP 2.0 alıp arka tarafta HTTP'ye downgrade eden mekanizma bu.
- 30:48Web Zafiyeti ve Encoding
- Web zafiyeti, web uygulama zafiyeti değil, bu nedenle kaçınmak zor bir konudur.
- Netflix örneğinde, URL'ye yeni satır ekleyerek (örneğin "netflix.com://") farklı istekler oluşturulabilir.
- Bu tür istekler, arka tarafta post isteği oluşturarak ve cevap olarak 302 Found Relocated (redirection) cevabı alarak token'ları çalabilir.
- 32:12Mimari Zafiyeti ve HTTP Protokolünden Kaynaklanan Sorunlar
- Bu mimari zafiyeti, yazılımların uyumlu çalışabilmesi konusunda bir sorundur.
- Web'in derinliklerinde ve protokolünden kaynaklı olan bu tür sorunlar, daha önce dert edilmemiş konulardır.
- Araştırmacı, bu zafiyeti bir araştırmanın devamı olarak ele almıştır.
- 33:41HTTP 2.0'den HTTP 1.0'a Downgrade Zafiyeti
- HTTP 2.0'den HTTP 1.0'a downgrade edildiğinde, bir istekte birden fazla istek oluşturulabilir.
- Load balancer ve web sunucusu arasındaki TCP bağlantısı üzerinden, bir istekte birden fazla istek gönderilebilir.
- HTTP 2.0'den HTTP 1.0'a conversion yapıldığında, bir istek iki parçaya ayrılır ve bu parçaların cevapları farklı kullanıcılar arasında yönlendirilebilir.
- 38:43Zafiyetin Kullanımı ve Güvenlik Riskleri
- Bu zafiyeti kullanarak, login flow'undaki token'lar çalınabilir.
- Araştırmacı, Atlas'ta bu zafiyeti bulmuş ve tüm case'leri test etmiştir.
- TCP bağlantısının nasıl yönetildiği, bu tür zafiyetlerin kullanılabilirliğini belirler; her istek için yeni bağlantı kuruluyorsa zafiyetler kullanılamaz.
- 41:48URL Parçalama ve Sonuç
- URL parçalama (url parsing) da bu tür zafiyetlerde önemli bir rol oynar.
- İkinci enjekte edilen istekte, sunucunun ürettiği cevabın location kısmına kendi domainini enjekte ederek, başka bir kullanıcıdan token'ları çalabilir.
- Konuşmacı, HTTP request smogling ile başlamayı ve daha sonra Album Max'ın son araştırmasını incelemeyi önermektedir.