OAuth SDK, eksik origin kontrolü ve tahmin edilebilir ID'ler nedeniyle sahte postMessage girişlerini kabul ediyordu

OAuth SDK'da eksik bir origin kontrolü

dev.to'da yayınlanan bir yazıya göre, bir web3 projesinin güvenlik incelemesi, projenin "Google ile giriş yap" akışının arkasındaki OAuth SDK'da bir açık ortaya çıkardı. Hata, SDK'nın postMessage olaylarını işleme biçimindeydi — bu, açılır pencereli kimlik doğrulama penceresinin ana uygulama sayfasıyla iletişim kurmak için kullandığı mekanizma — ve uygulamanın gelen giriş mesajlarını nereden geldiklerini hiç doğrulamadan işlemesi anlamına geliyordu.

Akışın kendisi yaygındır: kullanıcı bir giriş düğmesine tıklar, bir açılır pencere açılır, Google kullanıcıyı doğrular ve açılır pencere sonucu postMessage aracılığıyla üst pencereye iletir. Tarayıcı, pencereler arası mesajları origin'e bakılmaksızın ilettiğinden, tüm alışverişin güvenliği, alan dinleyicisinin event.data'ya güvenmeden önce event.origin'i doğrulamasına bağlıdır. Bu SDK'da bu doğrulama tamamen yoktu. Dinleyici, yükü alıp ileriye aktarıyor, ancak mesajın meşru açılır pencereden mi, kötü niyetli bir sayfadan mı yoksa başka bir yerden mi geldiğini kontrol etmiyordu.

Sıralı ID'ler hatayı sömürülmeye dönüştürdü

Eksik bir origin kontrolü bariz bir soruyu gündeme getirir: bir saldırgan bununla gerçekte ne kadar şey yapabilir? Cevap, SDK'nın gelen mesajları bekleyen OAuth istekleriyle nasıl eşleştirdiğine bağlıydı ve yazar, bu korelasyon mekanizmasını kaynağına kadar inceledi.

SDK her giriş isteğini bir payloadId ile etiketler ve aynı ID'ye referans veren bir açılır pencere mesajını bekler. Kod, bu ID'leri kriptografik rastgele bir kaynaktan üretmek yerine, her çağrıda bir artan modül düzeyinde bir sayaç kullanıyordu. 7 numaralı isteğin çıktığını gören herkes, bir sonraki isteğin 8 numara olacağını biliyordu.

Bu öngörülebilirlik saldırı zincirini tamamladı. Kurbanın OAuth açılır penceresi açılır açılmaz ve SDK mesaj dinleyicisini kaydeder kayıt etmez, kurbanın başka bir sekmede açık tuttuğu kötü niyetli bir sayfa, sadece sayarak tahmin ettiği bir payloadId ile window.opener.postMessage() çağırabilir. Dinleyicide origin kontrolü olmadığından SDK, sahte mesajı gerçek Google açılır penceresinden gelmiş gibi işler ve saldırganın başka bir şey tahmin etmesi gerekmez, diye açıklıyor yazar.

Bilinen bir kalıp, tutarsız uygulanmış

Yazıda öne çıkan bir detay var: aynı şirket, aynı SDK ailesindeki, origin'leri doğru şekilde doğrulayan — event.origin'i beklenen endpoint ile karşılaştıran ve uyuşmazlıkta erken dönen — başka bir paketi daha bakıyordu. Bilgi ve kalıp kurumun kendi kodunda mevcuttu — sadece OAuth uzantısına hiç ulaşmamıştı. Yazar bu ihmali, büyük kod tabanlarında bilinen etkenlere — ayrı ekipler, zaman çizelgeleri ve inceleme derinliği gibi — bağlıyor ve tutarsız güvenliğin saldırganlara fiilen en zayıf halkaya giden bir yol haritası sunduğunu savunuyor.

Sorun sorumlu bildirim yoluyla rapor edildi ve yazar, satıcının yamayı yayınlaması ve kendi danışma belgesini yayınlaması için zaman tanıyana kadar SDK'nın adını açıklamayı bekletiyor; dolayısıyla söz konusu paket ve tam sömürü detayları henüz kamuya açıklanmadı.

Düzeltime tek bir satır

Çare, şirketin zaten başka bir yerde yayınladığı kontrolü yansıtıyor: mesaj dinleyicisinin en başında event.origin'i SDK'nın beklenen endpoint'i ile karşılaştırın ve uyuşmuyorsa erken dönün. Yazarın belirttiği gibi, savunmasız ile düzeltilmiş sürüm arasında tek bir satır var.

Neden önemli

Bu ders tek bir SDK'nın çok ötesine genelleniyor. postMessage her yerde karşımıza çıkıyor — giriş açılır pencereleri, cüzdan bağlayıcıları, analitik araçları, sohbet widget'ları, gömülü iframe'ler — ve eksik origin doğrulaması egzotik bir hata değil, tekrarlayan bir hata sınıfı. Her mesaj dinleyicisi event.origin kontrolünü zorunlu saymalı ve asenkron işlemleri ilişkilendirmek kriptografik olarak rastgele ID'ler gerektirmelidir; çünkü öngörülebilir sıralı tanımlayıcılar yalnızca enumerasyona değil, pencereler arası saldırılara da olanak tanır. Hatanın nasıl bulunduğu da dikkat çekicidir: bir tarayıcıyla değil, kaynağı açarak, mesaj akışını izleyerek ve kodun neyi varsaydığı ile tarayıcının gerçekte neyi garanti ettiğini sorarak. postMessage kullanan her uygulama için yazının pratik tavsiyesi net — şimdi gidin dinleyicilerinizi kontrol edin.