Önde Gelen Framework'ler Origin Kontrollerini Varsayılan Olarak Atlayınca Cross-Site WebSocket Hijacking Varlığını Sürüdürüyor

dev.to'da yayınlanan bir yazı, Cross-Site WebSocket Hijacking'in (CSWSH) ilk kez tanımlandığından beri geçen on yılı aşkın süreye rağmen hâlâ pratik bir tehdit olduğunu savunuyor; çünkü baskın sunucu framework'leri WebSocket desteğini Origin doğrulaması etkin olmadan sunmaya devam ediyor. Yazıya göre en yaygın kullanılan beş framework'ten dördü varsayılan olarak herhangi bir origin'den gelen bağlantıları kabul ediyor; bu, saldırganın kontrol ettiği tek bir sayfanın kurbanın kimlik doğrulaması yapılmış oturumunu saldırganın hem okuyabileceği hem yazabileceği bir kanala dönüştürebileceği anlamına geliyor.

Saldırı nasıl çalışıyor

dev.to yazarı kök nedeni yanlış yapılandırma değil, protokol tasarımı olarak tanımlıyor. RFC 6455'te tanımlanan WebSocket handshake'i bir HTTP Upgrade isteğidir ve tarayıcılar bunu CORS preflight ya da Access-Control-Allow-Origin kontrolü olmadan cross-origin olarak gönderir; çünkü CORS, XMLHttpRequest ve fetch'i yönetir, WebSocket constructor'ını değil. Session cookie'leri istekle birlikte yolculuk eder.

Bu, CSWSH'yi klasik CSRF'den daha yıkıcı yapar. CSRF'de saldırgan bir istek gönderebilir ama yanıtı göremez; CSWSH'de ise ele geçirilen bağlantı kurulduğunda saldırganın sayfası sunucunun gönderdiği her şeyi okuyabilir ve kendi frame'lerini kurbanın kimliği altında enjekte edebilir — XSS veya phishing gerektirmeyen, canlı bir oturuma bağlı kalıcı, iki yönlü bir kanal. Christian Schneider saldırıyı 2013'te resmileştirdi; CWE-1385 olarak izleniyor ve yazar, mekanizma üzerine standart referans olarak James Kettle'in PortSwigger'ın Web Security Academy'deki materyalini gösteriyor.

Onu gerçek kılan üç olay

Yazı, boşluğun gerçek sonuçları doğurduğunun kanıtı olarak üç CVE'ye atıfta bulunuyor:

• LogRhythm Platform Manager 7.4.9. CVE-2020-25095, WebSocket bağlantılarını Origin kontrolü olmadan kabul ediyordu ve LocalSystem olarak çalışan Smart Response arayüzündeki komut enjeksiyonu (CVE-2020-25094) ile zincirlendiğinde, tarayıcısında saldırganın sayfasını yükleyen herhangi bir oturum açmış kurban karşı kimlik doğrulaması yapılmadan uzaktan kod çalıştırmaya imkân veriyordu.
• release-2022.11.2.16 öncesi Gitpod. CVE-2023-0957, cookie kimlik doğrulaması kullanan ve Origin kontrolü olmayan, WebSocket üzerinden sunulan bir JSONRPC API'sini etkiliyordu; Snyk ekibi bunu bir SameSite alt alan adı bypass'ıyla birleştirerek çalışma alanlarını, kod çalıştırma dahil, tamamen ele geçirdi. Düzeltme, ifşadan sonraki 24 saat içinde yayımlandı.
• Apache Zeppelin 0.11.1. CVSS puanı 7.5 olan CVE-2024-51775, kimlik doğrulaması yapılmış oturumlardaki paragraph içeriğini, kimlik doğrulaması ya da kullanıcı etkileşimi olmadan ağ erişimi olan herkese açıyordu.

Yazara göre ortak nokta şu: cookie kimlik doğrulaması mevcut HTTP rotalarında çalışıyor ve fark edilmeden varsayılan güvenlik sınırı hâline geliyor; daha sonra, çoğunlukla farklı bir ekip tarafından eklenen WebSocket endpoint'leri ise CSRF kontrollerini hiç miras almıyor.

Kutudan çıktığı gibi açık

• ws kütüphanesiyle Express: verifyClient callback'i mevcut ama isteğe bağlı ve varsayılan her origin'i kabul ediyor. Upgrade ayrıca Express middleware yığınını atlıyor, dolayısıyla doğrulamanın upgrade handler içinde açıkça yazılması gerekiyor.
• Django Channels: proje cross-site riskini belgeliyor, ancak OriginValidator ve AllowedHostsOriginValidator middleware'leri isteğe bağlı ASGI wrapper'ları olarak geliyor ve varsayılan kurulumda etkin değiller.
• FastAPI ve Starlette: WebSocket rotaları için yerleşik Origin doğrulaması yok ve CORSMiddleware yalnızca HTTP rotalarını kapsıyor, geriye her route handler içinde manuel kontroller kalıyor.
• Socket.io: 2.4.0 öncesi sürümler tüm origin'leri kabul ediyordu (CVE-2020-28481). Sürüm 2.4.0 CORS'yi varsayılan olarak devre dışı bıraktı, ancak yazıya göre bu ayar polling transport'unun HTTP yanıtlarını yönetiyor; dolayısıyla WebSocket transport'u için açık cors yapılandırması hâlâ gerekiyor.
• Go için Gorilla WebSocket: kütüphane varsayılan olarak yalnızca Host başlığını karşılaştırıyor ve CheckOrigin'i her zaman true döndüren bir fonksiyonla geçersiz kılan, yaygın biçimde kopyala-yapıştır edilen çözüm düzenli olarak üretime çıkıyor.

Boşluğu tespit etme ve kapatma

Tespit, upgrade sınırında yer alır. Meşru upgrade'ler uygulama alanına uyan bir Origin ve geçerli bir session cookie taşıyorken, bir hijacking denemesi geçerli bir cookie'nin yanında saldırgan kontrollü bir Origin taşır — yazara göre normal kullanımda asla birlikte görülmeyen bir ikili. Origin bir allowlist dışında kalırken Cookie başlığı boş olmayan upgrade'leri filtrelemek fiilen hiç false positive üretmez ve o Cookie başlığındaki session ID hedeflenen hesabı tanımlar. curl veya sunucudan sunucuya istemcilerin gönderdiği gibi Origin başlığı olmayan istekler sessizce kabul edilmek yerine güvenilmez olarak ele alınmalıdır.

Savunma için yazı birlikte kullanılan üç katman öngörüyor: uyuşmayan ve eksik değerleri reddeden sunucu tarafı bir Origin allowlist'i; upgrade URL'sinde query parametresi olarak geçirilen ve handshake tamamlanmadan önce doğrulanan kısa ömürlü bir CSRF token'ı; ve SameSite cookie'ler — Strict tercih edilir, ancak WebSocket handshake'leri üst düzey gezinme istekleri olmadığından Lax mevcut tarayıcılarda etkilidir (yazarın bu bulguyu atfettiği yer Nisan 2025 tarihli Include Security araştırması), buna karşılık SameSite=None tamamen sömürülebilir kalmaya devam ediyor. Yazı ayrıca OWASP'ın WebSockets'i cookie kimlik doğrulamasından uzaklaştırıp header tabanlı token'lara geçme tavsiyesini aktarıyor.

Neden önemli

Bu, ana akım araçlardaki bir varsayılanlar sorunu, dolayısıyla maruziyet geniş kapsamlı: bir WebSocket endpoint'i eklemiş herhangi bir cookie kimlik doğrulamalı uygulama bu sorunu sessizce miras alıyor ve başarısızlık modu CSRF'den daha kötü; çünkü saldırgan kör bir istek yerine kimlik doğrulaması yapılmış bir oturuma okuma-yazma penceresi elde ediyor. Dengeleyici iyi haber şu: tespit sinyali net ve düzeltme iyi anlaşılmış durumda, bu da saldırı sınıfı belgelendikten on iki yıl sonra açık varsayılanların varlığını sürdürmesini büyük ölçüde bir mühendislik ilgisi meselesi hâline getiriyor.