JWT'yi yük ve imza arasında bölme

Question

Bağlam: Tek sayfalı bir uygulamada JWT belirteçleri için depolama çözümlerine bakıyorum.

1. JWT'yi yerel depolamada saklamak güvenli değildir ve XSS saldırılarına açıktır.
2. JWT'yi güvenli / yalnızca HTTP tanımlama bilgisinde saklamak daha güvenlidir, ancak CSRF saldırılarına eğilimlidir.

Aşağıdaki senaryoyu inceliyorum:

Kimlik doğrulamasının ardından, bir yenileme belirteci yalnızca http olan güvenli bir tanımlama bilgisinde saklanır. Yalnızca bir erişim belirteci almak için kullanılabilir.

Yetkilendirmenin ardından, arka uç bir JWT erişim belirteci ile yanıt verir. JWT'nin başlık ve yük kısmı yanıt gövdesinin içindedir. Belirteç imzası gönderilmez ve yalnızca http güvenli bir çerezde ayarlanır (mümkünse aynı site katıdır, ancak durumun böyle olmadığını varsayalım). Başlık + yük, bellekte saklanır.

JWT aşağıdaki iddiaları içerir

• iat, nbf, exp (tahmin edilebilir IMO)
• kullanıcı kimliği ve izinleriyle ilgili iddialar (kullanıcı kimliği biliniyorsa tahmin edilebilir)
• kriptografik olarak güvenli bir rastgele sayı içeren jti (benim durumumda python sırlarıyla oluşturulmuş )

İsteklerde bulunurken, üstbilgi + yük, bir Yetkilendirme başlığında SPA tarafından XHR / fetch aracılığıyla gönderilir. İmza çerezlerle birlikte gönderilir. Arka uç her ikisini de birleştirir ve imzayı doğrular.

1. Bu mekanizma CSRF saldırılarına karşı güvenli midir? Jti iddiaları, Yetkilendirme belirteci + imza tanımlama bilgisini geçerli bir CSRF azaltma tekniği yapar mı?
2. Bu mekanizma, XSS saldırılarına karşı JWT'yi yerel depolamada depolamaktan gerçekten daha güvenli mi? (XSS kullanan bir saldırı, TRACE istismarında olduğu gibi imzayı da kolayca çalabilir ).

Not: Benzer, ancak aşırı geniş olan bu soruyu okudum, bu yüzden daha kesin bir cevap almak için bunu gönderiyorum.

Answer 1

Bu mekanizma CSRF saldırılarına karşı güvenli midir?

Bir JWT'yi bölme ve imzayı tanımlama bilgisinde ve belirtecin geri kalanını Tarayıcı Depolamasında depolamanın bu yöntemi, JWT'nin tamamının Yerel veya Oturum Depolamasında depolanmasına kıyasla CSRF saldırılarına karşı herhangi bir ek koruma sağlamaz. Evet, CSRF saldırılarını azaltacaktır, ancak sunucuya JWT'leri bölme ve birleştirme gibi gereksiz ek yükü eklemenize gerek yoktur. JWT'leri Yerel Depolamada saklamak ve yalnızca Yetkilendirme başlıklarında kabul etmek, uygulamanızı CSRF saldırılarından korumak için yeterlidir.

Bu mekanizma, XSS saldırılarına karşı JWT'yi yerel depolamada depolamaktan gerçekten daha güvenli mi? (XSS kullanan bir saldırı, TRACE istismarında olduğu gibi imzayı da kolayca çalabilir)

Odağınız yalnızca bir saldırganın JWT'leri çalabilmesindeyse, haklı olarak belirttiğiniz gibi TRACE sunucuda etkinleştirilmediği sürece bu yaklaşım güvenlidir.

Ancak bu, uygulamanızı XSS ​​saldırılarından daha güvenli hale getirmez. Örneğin, uygulamanızda keyfi Javascript çalıştırabilirsem, JWT üstbilgisini + yükünü Yerel Depolamadan alabilir ve Credentials True olarak ayarlanmış hassas bir uç noktaya bir XHR gönderebilirim. Bu uç nokta, örneğin hesap e-posta adresini değiştirerek tasarlanabilir. Bu hemen bir hesap devralmaya götürür. Çerezleri veya JWT'leri çalmaya gerek yok.

Özetle: Bu yaklaşım, imzayı belirtecin geri kalanından ayırarak oturum belirteçlerine karşı bir miktar koruma sağlar. Ancak, XSS söz konusu olduğunda, oturum jetonlarını çalmak, bakmanız gereken tek risk değildir.