
Geliştiriciler CORS'u neden hâlâ anlamıyor: Zoom'un localhost açığından dersler
Danışman Chris Foster'ın 2019 tarihli yazısı, Zoom'un localhost açığı örneği üzerinden CORS'u anlamamanın nasıl gerçek güvenlik sorunları doğurduğunu ve doğru bir uygulamanın nasıl olması gerektiğini anlatıyor.
Full-stack danışmanı Chris Foster'ın 2019'da yazdığı ve geliştiriciler arasında hâlâ dolaşan bir denemesi, pek çok web geliştiricisinin Cross-Origin Resource Sharing (CORS) mekanizmasını anlamadığını ve bu yanlış anlamanın gerçek güvenlik sonuçları doğurduğunu savunuyor. Yazının örnek olayı, güvenlik araştırmacısı Jonathan Leitschuh'un Temmuz 2019'da açıkladığı Zoom masaüstü istemcisindeki localhost açığı.
Zoom'un localhost tuzağı
Zoom istemcisi, makinede http://localhost:19421 adresini dinleyen bir web sunucusu kuruyordu. Bir kullanıcı Zoom bağlantısı açtığında zoom.us sitesi bu yerel sunucuya istek gönderip yerel uygulamanın açılmasını istiyordu. Normal bir AJAX isteği yerine sayfa, yerel web sunucusundan bir görsel yüklüyordu ve görselin boyutları sunucunun durum ya da hata kodunu kodluyordu. Leitschuh yazısında bunun CORS'u atlatmak için yapıldığını öne sürdü; çünkü ona göre tarayıcılar localhost üzerinde çalışan sunucular için CORS politikasını tamamen yok sayıyordu.
Foster bu iddianın yanlış olduğunu belirtiyor: Chrome, yerel web sunucuları için de CORS başlıklarına uyar ve localhost'a yapılan kaynaklar arası istekler tüm tarayıcılarda desteklenir — geliştiriciler bunu, Create React App arayüzü bir portta, API'si başka bir portta çalışırken sürekli yapar. Ona göre görsel hilesi, Zoom'un CORS'u ya anlamadığını ya da bilinçli olarak etrafından dolaştığını gösteriyor; bedeli ağır oldu: yerel istemcide işlem başlatıp yanıtı okuyabilen tek taraf zoom.us değil, internetteki her siteydi.
Güvenli bir uygulama nasıl olurdu
Yerel web sunucusu bir REST API sunmalı ve Access-Control-Allow-Origin başlığını https://zoom.us değeriyle göndermeliydi; böylece yalnızca zoom.us alan adında çalışan JavaScript onunla konuşabilirdi. Ayrıca zoom.us, sayfaların arka planda sessizce toplantı açmasını engellemek için iframe içinde görüntülemeyi bloke eden bir Content Security Policy başlığı göndermeliydi. Geriye yine de şu kalıyor: herhangi bir sayfa tarayıcıyı beklemediğiniz bir toplantının zoom.us bağlantısına yönlendirebilir. Foster bunu yazılım açığı değil, bir kullanıcı deneyimi kararı olarak sınıflandırıyor ve karara katılmıyor: yazılım öngörülebilir olmalıdır ve bir bağlantıya tıklamak kameranızı ve mikrofonunuzu yabancılara açmamalıdır. Daha iyi bir örnek olarak Google Meet'in uygulama içi açılır penceresini gösteriyor.
Kafa karışıklığı neden sürüyor
Sorun Zoom'la sınırlı değil: başka sağlayıcılar da tam olarak aynı açıkla yakalandı ve Stack Overflow CORS sorularıyla dolu; bunların yanında sık sık güvensiz varsayılanlar öneriliyor — örneğin enable-cors.org'da yayımlanan Express örneği, olduğu gibi kopyalanırsa uygulamayı savunmasız bırakır. Teknik mazeretler de tutmuyor: Firefox güvenli kaynaktan güvensiz kaynağa bazı istekleri engelleyebilir, ama localhost'u destekler; yerel uygulamalar kendi kendine imzalı sertifika üretebilir ya da bir tarayıcı eklentisiyle gelebilir. Foster'a göre aynı kaynak politikasını atlatmak kodu çalıştırabilir, ama sonrasında sorun üretir; CORS'un fazla karmaşık bir API mi olduğu yoksa geliştirici eğitiminin mi yetersiz kaldığı ise hâlâ belirsiz.
SiTech — AI destekli web geliştirme
Hızlı ve modern web siteleri kuruyor, AI'yı gerçek iş akışlarına taşıyoruz. Projeniz veya sorunuz mu var? Yardımcı olmaktan mutluluk duyarız.