· kaynak dev.to (home feed)
Araştırmacı, React veri çekme kütüphanesinde kullanıcılar arası SSR önbellek sızıntısını belgeledi
Bir araştırmacı, popüler bir React veri çekme kütüphanesinin SSR önbelleğini modül düzeyinde bir Map'te tuttuğunu, bu sayede eşzamanlı sunucu render'ları sırasında bir kullanıcının verisinin başka bir kullanıcıya sunulabildiğini gösterdi. İzolasyon düzeltmesi ise opsiyonel.

Sunucuda paylaşılan bir önbellek
Bir güvenlik araştırmacısı, popüler bir React veri çekme kütüphanesindeki önbellek izolasyonu hatasını belgeledi ve varsayılan yapılandırmanın, sunucu tarafında render (SSR) sırasında önbelleğe alınmış verinin eşzamanlı kullanıcılar arasında akmasına izin verdiğini gösterdi. dev.to'da yayımlanan bir yazıya göre araştırmacı, kütüphaneyi — genellikle Next.js projelerinde görülen türden — denetlerken önbellek başlatımını, bir kez oluşturulan ve kütüphanenin her parçasının referans verdiği modül düzeyinde bir new Map()'e kadar izledi.
Bu tasarım tarayıcıda mantıklıdır; burada tek bir uzun ömürlü önbellek, kullanıcı sayfalar arasında gezinirken korunmalıdır. Ancak bir Node.js süreci her modülü bir kez yükler ve gelen her istek arasında paylaşır. Araştırmacı, varsayılan yolda istek kapsamlı bir izolasyon bulunmadığını bildiriyor: AsyncLocalStorage sarmalayıcısı yok, istek başına önbellek fabrikası yok, izole bir önbellek veren SSR'ye özel bir dal yok.
Veri kullanıcılar arasında nasıl geçiyor
Bu hata için bir saldıgana ya da kötü niyetli bir girdiye gerek yok. Yazı, SSR sırasında /api/user-data gibi tek bir önbellek anahtarı altında kullanıcıya özel veri çeken bir bileşeni adım adım anlatıyor. Bu anahtar her kullanıcı için aynı olduğu için senaryo basit: A kullanıcısının render'ı önbelleği dolduruyor, birkaç milisaniye sonra B kullanıcısının render'ı aynı anahtar altında A'nın yükünü buluyor ve yeniden kullanıyor; B kullanıcısının HTML'i de artık A'nın adını, e-postasını ya da yükteki başka ne varsa içeriyor.
Davranışı doğrulamak için araştırmacı, üç farklı kullanıcının aynı önbellek anahtarına çarpan üç eşzamanlı isteği simüle eden bir kavram kanıtı hazırladı. Gönderide alıntılenen çıktıya göre B ve C kullanıcıları, paylaşılan önbellekten A kullanıcısının özel verilerini aldı. Ne bir exploit zinciri ne de bir zamanlama saldırısı — sadece aynı anda gelen sıradan trafik.
Gönderideki örnek bileşen useSWR tarzı bir hook çağırıyor, ancak araştırmacı sorumlu açıklama (responsible disclosure) pratiğine atıfla kütüphanenin adını ve tedarikçinin yanıtını açıklamıyor.
Güvenli seçenek opsiyonel
Yazıya göre kütüphane, taze bir önbellek kapsamı oluşturan ve istekleri ayrı tutacak bir provider bileşeniyle geliyor. Sorun şu ki bu opsiyonel: Varsayılan kurulumu izleyen geliştiriciler paylaşılan singleton'u alıyor ve dokümantasyon SSR riskini öne çıkarmıyor. Araştırmacıya göre geliştiricilerin kendilerinin keşfedip etkinleştirmesi gereken bir koruma, pratikte hiç koruma değildir; çünkü entegrasyonu yapanların çoğu tehlikenin varlığından hiç haberdar olmaz.
Önerilen düzeltmenin iki parçası var. Birincisi, AsyncLocalStorage gibi bir şey kullanarak istek kapsamlı önbellekleme sunucuda varsayılan hale getirilmeli. İkincisi, SSR riski çok daha açıkça dokümante edilmeli — araştırmacı bunun daha zor yarısı olduğunu söylüyor, çünkü bir dokümantasyon boşluğu yamanamaz ve kimseyi okumaya zorlayamaz.
Tanıdık bir örüntü
Bulgular, daha geniş bir sınıfın tek bir örneği olarak çerçeveleniyor: sunucu tarafı JavaScript'te modül düzeyindeki değiştirilebilir durum. Üst düzey bir nesnede saklanan yapılandırma, modül kapsamında tampon yapan bir logger, bir kez başlatılan bir oturum yöneticisi — ayrıntılar değişse de hepsi aynı yanlış varsayıma dayanıyor: modül kapsamında bir kez oluşturulan durumun istekler arasında paylaşılması güvenlidir.
Yazıya göre bu hata sınıfını yakalamayı zorlaştıran şey, yerel geliştirmenin bunu nadiren ortaya çıkarması. Yalnız test eden bir geliştirici aynı anda tek istek yapıyor, dolayısıyla önbellek hiçbir şeyle çakışmıyor. Sızıntı yalnızca üretimde, yük altında, iki kullanıcı tesadüfen aynı önbellek anahtarına aynı anda çarptığında görünüyor.
Neden önemli
Sunucu tarafında render, React uygulamalarının büyük bir kısmı için artık varsayılan bir mimari ve veri çekme kütüphaneleri doğrudan kullanıcıya özel isteklerin yolunda yer alıyor. Önbellekleri süreç genelinde singleton'larsa, varsayılan kurulumu çalıştıran her SSR uygulaması, hiçbir saldırganın tetiklemesine gerek olmayan ve rutin hiçbir taramanın işaretlemeyeceği makul bir kullanıcılar arası veri sızıntısını taşıyor. Bulgu ayrıca eşzamanlılık güvenliğinin özelliklerde değil varsayılanlarda yaşadığının bir hatırlatıcısı: izolasyon mekanizması bu kütüphanede zaten var, ama yalnızca onu zaten aradığını bilen geliştiricileri koruyor. İstek kapsamlı önbellekleme sunucuda kutudan çıkan davranış haline gelene kadar, paylaşılan önbellek anahtarlarıyla SSR çalıştıran ekipler veri katmanlarını denetlemeli — ya da en azından uygulamalarını gerçekten izolasyon provider'ına sarıp sarmadıklarını doğrulamalı.
- #react
- #ssr
- #security
- #caching
- #node-js