Tek Sayfa Uygulaması'nda (SPA) OAuth yönetimi söz konusu olduğunda, erişim ve yenileme token'larının nerede saklanacağı uzun süredir tartışılan bir konudur. localStorage, sessionStorage ve bellek içi değişkenlerin tümü XSS karşısında yetersiz kalır. Backend for Frontend (BFF) deseni, token'ları tarayıcıya iletmek yerine sunucu tarafında tutan bir tasarımdır. Bu makale, mekanizmayı ve temel uygulama noktalarını düzenlemektedir.
Ön Koşullar
Bu makale aşağıdaki ortamı varsaymaktadır:
- OAuth 2.0 ve OpenID Connect kullanan tarayıcı tabanlı bir uygulamanın geliştirilmesi.
- SPA, çağırdığı API'ler ve bir yetkilendirme sunucusunun varlığı.
- SPA ve onu destekleyen sunucu tarafı bileşenlerin aynı üst alan adına yerleştirilebilmesi.
- HTTPS ön koşuldur (Güvenli Çerezlerin yayınlanması için gereklidir).
Tarayıcı Tabanlı Uygulamalarda XSS Riskleri
Tarayıcıda çalışan uygulama kodu, tarayıcının yürütme ortamında olan her şeye karşı savunmasızdır. XSS'in etkisi geniştir ve saldırı kodu uygulamayla aynı bağlamda çalıştığı için aşağıdaki işlemler mümkündür:
- localStorage veya sessionStorage'da saklanan değerlerin okunması.
- JavaScript'ten erişilebilen bellek içi değişkenlerin okunması.
- Uygulamanın gerçekleştirebileceği tüm API çağrılarının yürütülmesi.
- Yerleşik işlevlerin üzerine yazılarak davranışın değiştirilmesi (prototip kirliliği).
XSS için birden fazla giriş noktası vardır; bağımlı kütüphanelerdeki güvenlik açıkları, kendi kodunuzun girdi/çıktı işlemesindeki kusurlar veya üçüncü taraf betiklerinin ele geçirilmesi gibi. XSS'i tamamen önlemek zor olduğundan, gerçekçi bir politika "bir saldırı olursa etkiyi sınırlamak"tır.
Token'lar tarayıcıya yerleştirildiği sürece, XSS yoluyla token'ların çalınma olasılığı devam eder. Bir saldırgan çalınan yenileme token'ını kendi ortamında kullanırsa, kullanıcı web sitesini kapattıktan sonra bile uzun süre API'leri çağırabilir. Token rotasyonu ve boşta kalma zaman aşımları etkiyi azaltabilir ancak temel çözümler değildir.
Token'ları Tarayıcıya Koymayan Tasarım
BFF deseni, SPA'ya özel bir sunucu tarafı bileşen sunar ve OAuth istemci sorumluluklarını burada merkezileştirir. SPA, OAuth işlemlerini doğrudan yönetmez; kimlik doğrulama ve API çağrılarını BFF aracılığıyla gerçekleştirir.
Görev dağılımı şu şekildedir:
- Yetkilendirme sunucusuyla OAuth protokol iletişimi: BFF tarafından yönetilir.
- Erişim ve yenileme token'larını tutma: Yalnızca BFF.
- SPA ve BFF arasında kimlik doğrulama durumunu sürdürme: HttpOnly Çerez.
- API çağrıları: SPA, BFF'ye istek gönderir; BFF, Çerezi token'a dönüştürür ve API'ye iletir.
Bu yapılandırmada token'lar yalnızca BFF ve çağırdığı API'ler arasında dolaşır ve tarayıcının JavaScript'inden görünmez. XSS meydana gelse bile saldırgan token'ı çıkarıp başka bir yerden kullanamaz. Saldırganın yapabileceği tek şey, kullanıcının o anda açık olan oturumu kapsamında BFF'ye istek göndermektir. Bu etki göz ardı edilemez olsa da, etkinin süresi ve kapsamı token hırsızlığına kıyasla önemli ölçüde sınırlıdır.
BFF, OAuth terminolojisinde "gizli istemci" olarak adlandırılan şeyi temsil eder. Bir istemci sırrı tutar ve yetkilendirme kodlarının token'larla değişimini ve yenileme işlemini tamamen sunucu tarafında tamamlar.
Kimlik Doğrulama Akışı
Tipik bir kimlik doğrulama akışı şu şekildedir:
- SPA bir oturum açma başlattığında BFF'ye bir oturum açma isteği gönderir.
- BFF, PKCE ile bir yetkilendirme kodu akışı başlatır, yetkilendirme sunucusuna bir yönlendirme URL'si oluşturur ve SPA'ya döndürür.
- SPA tarayıcıyı bu URL'ye yönlendirir ve kullanıcı yetkilendirme sunucusunda kimlik doğrulaması yapar.
- Yetkilendirme sunucusu, BFF'nin yönlendirme URI'sine bir yetkilendirme kodu döndürür.
- BFF, yetkilendirme kodunu token'larla değiştirir ve bir erişim token'ı ile bir yenileme token'ı elde eder.
- BFF, token'ları kendi güvenli alanında (şifrelenmiş çerez, sunucu tarafı oturum deposu vb.) saklar ve SPA'ya yalnızca bir oturum tanımlayıcısını HttpOnly Çerez aracılığıyla döndürür.
- SPA bir API çağırdığında, isteği BFF aracılığıyla gönderir. Çerez aynı anda gönderilir ve BFF bunu bir erişim token'ına dönüştürüp yukarı akış API'sine iletir.
- Erişim token'ının süresi dolarsa, BFF yenileme token'ını kullanarak sessizce günceller.
SPA perspektifinden bakıldığında, oturum açma durumu Çerez tarafından sürdürülür ve API istekleri normal fetch çağrılarıyla tamamlanır. SPA'da doğrudan OAuth token'larını veya yetkilendirme kodlarını işleyen kod bulunmaz.
Gerekli Güvenlik Ayarları
BFF tarafından yayınlanan Çerez için aşağıdaki nitelikler ayarlanmalıdır:
- HttpOnly: JavaScript'ten erişimi yasaklar. XSS olsa bile Çerez içeriği okunamaz.
- Secure: Yalnızca HTTPS üzerinden gönderilir.
- SameSite=Strict: Çerezin diğer sitelerden gelen isteklerle gönderilmemesini sağlar. Bu, büyük CSRF saldırı yollarını engellemeye yardımcı olur, ancak CSRF koruması yalnızca bununla tamamlanmaz.
- __Host- öneki: Çerez adına __Host- öneki eklemek, tarayıcının Çerezi yayınlayan ana bilgisayarla sınırlamasını ve alt alan adlarıyla paylaşmamasını sağlar.
Token'lar şifrelenmiş bir Çerezde (istemci tarafı oturum) saklanıyorsa, Çerez içeriği şifrelenir. Token'lar sunucu tarafı oturum deposuna (sunucu tarafı oturum) yerleştiriliyorsa, Çerez yalnızca bir oturum tanımlayıcısı içerdiğinden şifreleme gerekli değildir.
CSRF Koruması Yalnızca SameSite'e Dayanmamalıdır
Çerez tabanlı kimlik doğrulama kullandığından, BFF'nin CSRF'ye karşı koruma uygulaması gerekir. SameSite=Strict geçerli bir adımdır ancak tek çözüm değildir. Özellikle SPA'nın www.example.com ve BFF'nin api.example.com üzerinde yer aldığı yapılandırmalarda dikkatli olunmalıdır. SameSite belirlemesi kaynaktan ziyade site tarafından yapıldığından, example.com altındaki diğer alt alan adlarından gelen istekler "aynı site" olarak kabul edilir ve SameSite=Strict ile bile Çerezler gönderilir.
Bu nedenle, CSRF savunmasını aşağıdakilerden biriyle güçlendirin:
- BFF ve SPA farklı kaynaklardaysa, savunma için CORS ve Origin başlık doğrulaması kullanın.
- Durumu değiştiren istekler için, sahteciliğe karşı koruma / çift gönderim çerez yöntemini kullanarak CSRF token'larını doğrulayın.
CORS'u Tam Kaynaklarla Sınırlayın
CORS'a yalnızca SPA'nın tam kaynağı için izin verilmelidir. Çerezleri içeren kimlik bilgisi isteklerinde tarayıcılar, Access-Control-Allow-Origin'de joker karakterlere (*) izin vermez. Bu nedenle BFF, yanıtta SPA'nın tam kaynağını yansıtmalıdır. İzin verilen kaynakları bu şekilde sıkı bir şekilde sınırlamak, CSRF savunmasının bir parçası olarak işlev görür.
BFF tarafından tutulan oturum verileri, özellikle şifrelenmiş Çerezlerde saklanan token bilgileri için anahtar yönetimi gereklidir. Anahtarları BFF ayarları olarak güvenli bir şekilde enjekte etme ve düzenli olarak döndürme işlemlerini dahil edin.
SPA ve BFF'nin aynı üst alan adına yerleştirilmesinin, Same-Site Çerezlerinin birinci taraf Çerezler olarak işlev görmesi koşulunu karşılamak için olduğunu unutmayın.
Evrim: API Odaklı BFF
Bir BFF geleneksel bir web uygulaması gibi oluşturulursa, BFF'nin sunucu tarafı işlemesi SPA'nın sayfa geçişlerine dahil olur. API odaklı bir BFF bu etkiyi en aza indirir.
Görevler ikiye ayrılır:
- OAuth Ajanı: OAuth protokol işlemlerinden sorumlu bir API. SPA'dan JSON aracılığıyla çağrılır.
- OAuth Vekili: Bir API ağ geçidi eklentisi olarak çalışır, token'ı Çerezden çıkarır ve yukarı akış API'sine iletir.
Bu yapılandırmada SPA, OAuth Ajanı'nı normal bir REST API'si olarak çağırır. SPA ön uç geliştirme deneyimi, BFF'nin tanıtılmasından öncekiyle neredeyse aynı tutulabilir.
Benimseme İçin Dikkat Edilmesi Gerekenler
BFF desenini benimserken aşağıdakileri göz önünde bulundurun:
- Ek mimari bileşenler, geliştirme ve işletme maliyetlerini artırır.
- SPA ve BFF aynı üst alan adına yerleştirilmelidir.
- Authorization başlığını basitçe bir ters proxy aracılığıyla ileten bir yapılandırma BFF değildir. BFF'nin özü, token'ı gizli bir istemci olarak tutmaktır.
- PKCE ve BFF alternatif değil, birlikte kullanılır.
- BFF, token'ın amaçlanmayan ana bilgisayarlara maruz kalmasını önlemek için iletmeden önce hedef ana bilgisayarı doğrulamalıdır.
- Oturum kapatma tasarımı karmaşık hale gelir; SPA oturumları, BFF çerezleri ve yetkilendirme sunucusu oturumlarının tümü birbirine bağlanmalıdır.
Özet
Tarayıcı tabanlı uygulamalarda token'ları güvenli bir şekilde işlemenin pratik bir yolu, onları tarayıcıya koymamaktır. BFF deseni, OAuth istemci sorumluluklarını sunucu tarafına taşır ve tarayıcıya yalnızca HttpOnly Çerezler iletir. Bu, XSS meydana gelse bile token hırsızlığını önler. Görevlerin bir OAuth Ajanı ve OAuth Vekili olarak bölünmesiyle, SPA geliştirme deneyimi korunurken güvenlik güçlendirilebilir.
