Arkayüz Ön Uç (BFF) Hakkında Geliştiricilerin Sıklıkla Düşündüğü 5 Hata

Geliştiriciler, Arkayüz Ön Uç (Backend for Frontend - BFF) desenini kullanırken sıkça yanıltıcı varsayımlara kapılıyor. Bu yanlış anlaşılmalar, uygulamaların güvenlik açıklarıyla sonuçlanabiliyor. OAuth 2.0 akışlarından çerez yönetimine kadar birçok konuda yapılan hatalar, aslında token güvenliğinin yanıltıcı şekilde iyileştirildiğine dair yanılsamalara yol açıyor.

PKCE, BFF'nin Yerini Tutan Bir Çözüm Değildir

Geliştiricilerin en sık karşılaştığı yanılgı, PKCE'nin (Proof Key for Code Exchange) BFF'nin yerini alabileceği yönündedir. OAuth çalışma grubunun, Tek Sayfalı Uygulamalar (SPA) için Implicit Grant yöntemini kullanımdan kaldırıp, PKCE'yi önerdiği doğrudur. Bu öneri, OAuth 2.1 ile tüm istemciler için PKCE kullanımını genişletmiştir. Ancak birçok geliştirici, PKCE'nin token depolama güvenliğini de çözdüğünü varsaymaktadır. Bu doğru değildir.

PKCE, yalnızca yetkilendirme kodunun taşınması sırasında araya girme saldırılarına karşı koruma sağlar. Yetkilendirme kodunu ele geçiren bir saldırganın, bu kodu token almak için kullanmasını engeller. Bu önemli bir güvenlik katmanıdır ancak OAuth akışının yalnızca bir bölümünü ele alır. Uygulama tokenları aldıktan sonra, PKCE'nin görevi biter. Artık tokenların tarayıcıda nasıl saklandığı ya da bir XSS saldırısı sırasında neler olabileceği konusunda hiçbir etkisi yoktur.

Tokenların localStorage, sessionStorage veya hatta JavaScript belleğinde saklanması, kötü amaçlı komut dosyalarına karşı savunmasız kalmalarına neden olur. BFF ise farklı bir yaklaşım sunar: tokenları tarayıcıdan tamamen uzak tutar. BFF, yetkilendirme kodunu tokenlarla değiştirir ve tokenları sunucu tarafında saklar. Tarayıcıya ise yalnızca HttpOnly bir oturum çerezi gönderilir. Bu şekilde, tarayıcıdaki bir XSS saldırısı bile tokenlara erişemez.

PKCE ve BFF, birbirini tamamlayan iki farklı güvenlik katmanıdır. Uygulamanızın tehdit modelinde XSS saldırıları yer alıyorsa (ki çoğu uygulama için durum böyledir), yalnızca PKCE kullanmak yeterli olmayacaktır.

BFF, Basit Bir Ters Proxy Değildir

Bazı geliştiriciler, BFF olarak adlandırdıkları mimarilerin aslında yalnızca bir ters proxy olduğunu fark etmemişlerdir. Bu tür sistemler, istekleri (ve tokenları) doğrudan arka uca iletir. Bu da bir BFF değildir.

BFF'nin temel özelliği, gizli bir OAuth istemcisi olarak hareket etmesidir. Bir istemci gizli anahtarı barındırır ve OAuth akışını tamamen yönetir. En önemlisi, tokenlar hiçbir zaman tarayıcıdan dışarı çıkmaz.

Eğer arka uç, yetkilendirme başlığında bearer tokenını tarayıcıya ileten bir ters proxy ise, bu BFF değildir. Tokenlar hâlâ tarayıcı erişimine açıktır. Bu durumda, yalnızca bir ağ atlama eklenmiş olur, ancak güvenlik avantajı sağlanmaz.

IETF, OAuth 2.0 tarayıcı tabanlı uygulamalar için en iyi uygulamalar belgesinde, Token Aracılı Arka Uç (Token-Mediating Backend) ile gerçek BFF arasındaki farkı net bir şekilde ortaya koymaktadır. Token aracılı arka uç, tokenları alır ve bunları ön uca iletirken, gerçek BFF'de tokenlar hiçbir zaman ön uca iletilmez. Bu iki desen farklı güvenlik özelliklerine sahiptir.

Eğer arka uç, tokenları herhangi bir şekilde tarayıcıya iletiyorsa, BFF uygulamamışsınız demektir. Token aracılı bir sistem uygulamışsınız, ki bu da hiçbir şey yapmamaktan iyidir, ancak BFF'nin sunduğu güvenlik avantajlarını sağlamaz.

Çerezler Tokenlardan Daha Güvensiz Değildir

Bu yanlış inanışın kökeninde, geçmişte çerezlerin kötüye kullanılması ve CSRF saldırıları yer almaktadır. SameSite özelliğinin standart hale gelmesinden önce, çerezler kolayca saldırıya uğrayabiliyordu. Ayrıca, REST API tasarımında durum bilgisine yer verilmemesi gerektiği yönündeki yanlış bir anlayış da bu algıyı destekledi.

Ancak günümüzde durum farklıdır. HttpOnly bir oturum çerezi, JavaScript tarafından okunamaz. Bu da XSS saldırılarının doğrudan token çalmasını engeller. Öte yandan, localStorage içinde saklanan bir JWT, sayfada çalışan herhangi bir komut dosyası tarafından okunabilir.

Saldırı yüzeyleri simetrik değildir. HttpOnly bir çerez kullanılarak yapılan CSRF saldırısı, saldırganın kullanıcıyı başka bir kaynaktan belirli bir yetkilendirilmiş isteği yapmaya ikna etmesini gerektirir. Öte yandan, localStorage içinde saklanan bir tokena yapılan XSS saldırısı, saldırgana doğrudan API çağrıları yapma yetkisi verir. Bu çağrılar, kullanıcı etkileşimi gerektirmeden, herhangi bir yerden gerçekleştirilebilir.

SameSite=Strict ya da SameSite=Lax kullanımıyla, HttpOnly çerezlere karşı yapılan CSRF saldırıları zaten oldukça zordur. Ek olarak, CSRF tokenları kullanıldığında bu saldırılar neredeyse imkansız hale gelir.

HttpOnly çerezler, CSRF saldırılarına karşı tamamen bağışıktır demek doğru olmasa da, saldırı yüzeyi XSS tabanlı token hırsızlığına kıyasla çok daha küçüktür. Bir saldırı vektörünü (XSS tabanlı token hırsızlığı) başka bir, daha sınırlı bir saldırı vektörüyle (CSRF) değiştiriyorsunuz. Bu değişim çoğu durumda yapılmaya değerdir.

BFF Tüm Tarayıcı Tabanlı Kimlik Doğrulama Güvenlik Sorunlarını Çözmez

BFF, güvenlik sınırını değiştirir, ortadan kaldırmaz. BFF'yi uyguladığınızda, XSS saldırılarının token çalması sorununu (XSS tokenları tarayıcı deposundan çalabilir) sunucu tarafında oturum yönetimi sorunuyla değiştirirsiniz. Bu çoğu durumda iyi bir değişimdir, ancak BFF'nin otomatik olarak çözmediği sorumluluklar da beraberinde gelir.

BFF'nin tek başına çözmediği unsurlar şunlardır:

• CSRF koruması. BFF, çerezler kullandığı için durum değiştiren isteklerin CSRF korumasına ihtiyacı vardır. SameSite çerezleri önemli ölçüde yardımcı olur, ancak bu ayarların doğru şekilde yapılandırılması sizin sorumluluğunuzdadır.

• Oturum iptali. Kullanıcı çıkış yaptığında, yalnızca tarayıcı tarafında çerezi temizlemek yeterli değildir. Sunucu tarafında da oturumu iptal etmek gerekir. Aksi takdirde, çalınan oturum çerezleri doğal olarak sona erene kadar geçerliliğini korur.

• Güvenli çerez yapılandırması. Secure, HttpOnly ve doğru SameSite ayarları mutlaka kullanılmalıdır. Bu ayarlardan herhangi biri eksikse, desenin güvenlik avantajları zayıflar.

BFF'nin sunduğu bu güvenlik avantajları, doğru şekilde uygulandığında, geliştiricilerin karşılaştığı birçok yaygın güvenlik açığını ortadan kaldırır. Ancak unutmayın: BFF, güvenliğinizi otomatik olarak sağlamaz. Doğru yapılandırma ve sürekli bakım gerektirir. Gelecekte, tarayıcı tabanlı uygulamaların güvenliğini sağlamak için BFF'nin nasıl daha da optimize edilebileceği konusunda araştırmalar devam edecektir. Geliştiricilerin, bu deseni doğru bir şekilde anlamaları ve uygulamaları, uygulamalarının güvenliğine önemli katkılar sağlayacaktır.