Back-forward cache, çıkış sonrası kimlik doğrulamalı sayfaları geri getirebiliyor, dev.to yazısı uyarıyor

Tuzak

Oturumu kapatmak, sunucuya oturumun bittiğini söyler. Tarayıcıya bunu mutlaka söylemez. dev.io'daki bir yazı, tarayıcının tamamen render edilmiş bir sayfayı bellekte tuttuğu, böylece Geri ve İleri düğmelerinin anında çalışmasını sağlayan mekanizması olan back-forward cache, yani bfcache'e dikkat çekiyor. Yazının referans verdiği MDN'e göre, bfcache'ten geri getirilen bir sayfa sunucuyla yeniden doğrulanmayabilir. Sonuç, session cookie'nin yok edildiği ama son kimlik doğrulamalı görünümün hâlâ orada, bir Geri tuşu uzağında beklediği bir penceredir.

Yazarın öne çıkardığı senaryo, paylaşılan makine: biri bir fatura veya hesap paneli açar, oturumu kapatır ve cihazı başka birine devreder. O kişi Geri'ye basar. Tarayıcı sayfayı bfcache'ten sunarsa, uygulamanın oturumu yeniden kontrol etme şansı bile olmadan eski DOM ortaya çıkar. Yalnızca ilk yükleme sırasında çalışan kod tetiklenmez ve hızlı bir client-side redirect bile geçiş sırasında o anlık görüntüyü açığa çıkarabilir.

Header seviyesinde önlem

Tarayıcıya verilebilecek en doğrudan talimat Cache-Control: no-store'dur. Yazının referans gösterdiği MDN'e göre, no-store taşıyan yanıtlar bunu destekleyen tarayıcılarda bfcache'e alınmaz. Yazar, bu header'ın rastgele her yere uygulanmaması konusunda uyarıyor: header normal HTTP cache'lemeyi ve performansı da etkiler, dolayısıyla her yanıt için değil, gerçekten hassas sayfalar için kullanılmalıdır. Yazı ayrıca yaygın bir karışıklığa dikkat çekiyor: no-cache farklı bir direktiftir; depolamaya hâlâ izin verir ve yalnızca yeniden kullanımdan önce yeniden doğrulama gerektirir. HTTP cache ve bfcache ilişkili ama ayrı sistemlerdir; birini ele almak diğerini kapsamaz.

Geri getirmeyi JavaScript ile yakalamak

bfcache'e uygun kalması gereken sayfalar için pageshow event'i bir kanca sunar. Sayfa cache'ten geri getirildiğinde true olan bir persisted bayrağı taşır. Bu sinyalde bir çıkış akışı, yerel durumu çıkış yapılmış olarak işaretleyebilir, hassas içeriği DOM'dan temizleyebilir ve korumalı verileri render etmeden önce yeni bir yetkilendirme kararı isteyebilir. Yazar, böyle bir handler'ın sunucu tarafındaki iptalin yerini aldığı değil, onu tamamladığı konusunda açık. Canlı bağlantılar da dikkat ister: WebSocket oturumları ve event stream'leri, açıldıkları oturumdan daha uzun süre dayanabildikleri için geri getirme sonrasında durdurulmalı veya yeniden kurulmalıdır.

Sunucu ve depolama hijyeni

Yazıya göre eksiksiz bir çıkış; oturumu iptal eder, cookie'leri doğru attribute'lerle temizler ve refresh token'ları ya da cihaz yetkilerini geçersiz kılar. Birden fazla tab söz konusuysa, ekipler çıkışın global olup olmadığına karar vermeli ve globalse bunu diğer tab'lara idempotent handler'larla yaymalıdır. Çıkış anında çevrimdışı olmuş bir tab, tekrar aktifleştiğinde herhangi bir şey render etmeden önce oturumunu yeniden doğrulamalıdır.

Yazı ayrıca client-side depolamanın denetlenmesini öneriyor. IndexedDB, localStorage, bellek içi store'lar ve service worker cache'leri, bfcache'ten bağımsız olarak hassas veri tutabilir. Bir yüzeyi temizleyip diğerlerini dolu bırakmak, aynı bilgi sızıntısını başka bir kapıdan yeniden üretir. Yazar, yetkilendirme kararlarının asla sunucunun doğrulayamayacağı client depolamada tutulmaması gerektiğini ve her depolama yüzeyinin kendi veri saklama politikasına ihtiyacı olduğunu ekliyor.

Saldırganın yapacağı gibi test etmek

Son olarak yazı, tehdide uyan somut bir test öngörüyor: A hesabıyla giriş yapın, hassas bir sayfa açın, çıkış yapın, Geri'ye basın ve tam olarak neyin göründüğünü kaydedin. Çıkıştan sonra ağı çevrimdışı yaparak ve kısa bir gecikmenin ardından tekrar deneyin. Geri getirilen sayfanın bfcache'ten gelip gelmediğini, sunucunun eski oturumu reddetmediğini ve cache'lenmiş API yanıtlarının hem render edilen görünümde hem de temel isteklerde okunabilir kalıp kalmadığını kontrol edin.

Neden önemli

Bu sessiz bir arıza modu: hiçbir şey çökmüyor, hiçbir hata fırlatılmıyor ve davranış, kullanıcıların genellikle sevdiği bir tarayıcı özelliğinden kaynaklanıyor. Bu, onu sıradan QA'da gözden kaçırmayı kolay ve özellikle paylaşılan ya da ödünç alınan cihazlarda sömürmeye cazip kılıyor. dev.to yazısının çerçevesi benimsenmeye değer: oturumu kapatmayı sunucu, client ve tarayıcının cache katmanları genelinde eşgüdümlü bir değişiklik olarak ele alın; her birinin kendi sınırları vardır. Pratik hedef, tarayıcı eski bir anlık görüntü gösterse bile onda görülmeye değer hiçbir şey olmamasıdır.