JWT'yi tarayıcıda nerede saklayabilirim? CSRF'ye karşı nasıl korunulur?


159

Çerez tabanlı kimlik doğrulamasını biliyorum. SSL ve HttpOnly bayrağı, çerez tabanlı kimlik doğrulamasını MITM ve XSS'den korumak için uygulanabilir. Bununla birlikte, CSRF'den korunmak için daha özel önlemlerin alınması gerekecektir. Bunlar biraz karmaşık. ( başvuru )

Son zamanlarda, JSON Web Token'ın (JWT) kimlik doğrulama için bir çözüm olarak oldukça sıcak olduğunu keşfettim. JWT kodlama, kod çözme ve doğrulama ile ilgili maddeleri biliyorum. Ancak, bazı web sitelerinin / öğreticilerin JWT kullanılıyorsa neden CSRF korumasına gerek olmadığını anlayamıyorum. Oldukça çok okudum ve aşağıdaki sorunları özetlemeye çalışıyorum. Sadece birinin JWT'nin büyük resmini vermesini ve JWT hakkında yanlış anladığım kavramları netleştirmesini istiyorum.

  1. JWT çerezde saklanırsa, sunucunun çerez / jetonu doğrulamak için oturumlara gerek duymaması dışında çerez tabanlı kimlik doğrulaması ile aynı olduğunu düşünüyorum. Özel bir önlem uygulanmazsa, CSRF hakkında hala risk vardır. JWT çerezde saklanmıyor mu?

  2. JWT localStorage / sessionStorage içinde saklanıyorsa, hiçbir çerez bu nedenle CRSF'ye karşı korumaya gerek yoktur. Soru JWT'nin sunucuya nasıl gönderileceği. Burada buldum jQuery kullanarak ajax istekleri HTTP üstbilgisi JWT göndermek için önerir. Yani, sadece ajax istekleri kimlik doğrulaması yapabilir?

  3. Ayrıca, JWT göndermek için "Yetkilendirme başlığı" ve "Taşıyıcı" kullanmak için bir blog daha gördüm . Blogun bahsettiği yöntemi anlamıyorum. Birisi lütfen "Yetkilendirme başlığı" ve "Taşıyıcı" hakkında daha fazla açıklayabilir mi? Bu, JWT'nin TÜM isteklerin HTTP üstbilgisi tarafından iletilmesini sağlıyor mu? Evet ise, CSRF'ye ne dersiniz?

Yanıtlar:


70

JWT belirteçleri, OAuth 2.0 ve OpenID Connect gibi yeni yetkilendirme ve kimlik doğrulama protokollerinde varsayılan belirteç biçimi olarak kullanıldığından popülerdir .

Simge bir çerezde saklandığında, tarayıcı her istekle birlikte aynı alana otomatik olarak gönderir ve bu yine de CSRF saldırılarına karşı savunmasızdır.

Taşıyıcı kimlik doğrulaması, HTTP'de tanımlanan kimlik doğrulama düzenlerinden biridir. Temel olarak YOU, bir isteğin Yetkilendirme HTTP başlığına (JWT) jetonunun yapıştırılması anlamına gelir . Tarayıcı NOTbunu sizin için otomatik olarak yapar, bu nedenle web sitenizi korumak için uygun değildir. Tarayıcı üstbilgiyi isteğinize otomatik olarak eklemediğinden, kimlik doğrulama bilgilerinizin orijinal etki alanına otomatik olarak gönderilmesine bağlı olan bir CSRF saldırısına karşı savunmasız değildir.

Taşıyıcı şeması genellikle AJAX çağrıları veya mobil istemciler tarafından tüketilen web API'lerini (REST hizmetleri) korumak için kullanılır.


1
@ Timespace7 Hayır, JWT belirteçleri genellikle yerel istemcilerden de kullanılır. OAuth 2.0, özellikle yerel (mobil) istemcileri hedefleyen akışlara sahiptir. Yapmadıkları şey gizli tarayıcı kimlik doğrulamasıdır (çerezler veya temel kimlik doğrulama gibi).
MvdD

5
API'nız JWT jetonunu yalnızca Yetkilendirme başlığından alırsa, CSRF'ye karşı savunmasız olmadığını söylüyorum. Simgeyi bir çerezden alan herhangi bir site veya API'nın CSRF azaltması gerekir.
MvdD

13
Bu, jwt'yi bir çerezde etkili bir şekilde saklayabileceğimiz ve Yetkilendirme başlığında istek gönderirsek güvenli olacağı anlamına mı geliyor?
cameronroe

10
@cameronjroe, çerezlerinizde saklayabilirsiniz, ancak çerezlerinizi kimlik doğrulama için kullanmıyorsanız (bu durumda başlıklarınızı kullanırsınız)
Jaakko

1
AJAX aramaları da tarayıcıdan geliyor. JWT jetonları, web uygulamalarını (işaretleme, resimler, css ve JavaScript sunma) doğrulamak için kullanılan çerezlere karşı web API'lerini (veri sunma) doğrulamak için kullanılır
MvdD

144

JWT'yi istemci bilgisayarda depolamamız gerekiyor. Bir LocalStorage / SessionStorage içinde saklarsak, bir XSS saldırısı tarafından kolayca yakalanabilir. Bir çerezleri çerezlerde saklarsak, bir bilgisayar korsanı bir CSRF saldırısında (okumadan) kullanabilir ve kullanıcıyı taklit edebilir ve API'mizle iletişime geçebilir ve eylemler yapmak veya kullanıcı adına bilgi almak için istek gönderebilir.

Ancak çerezlerde JWT'yi kolayca çalınmamasını sağlamak için birkaç yol vardır (ancak bunları çalmak için bazı gelişmiş teknikler vardır). Ancak LocalStorage / SessionStorage'a güvenmek istiyorsanız, basit bir XSS saldırısı ile erişilebilir.

Bu yüzden CSRF sorununu çözmek için uygulamamda Çifte Gönder Çerezleri kullanıyorum.

Çerezleri Çift Gönderme Yöntemi

  1. JWT'yi bir HttpOnly çerezinde saklayın ve HTTPS üzerinden aktarmak için güvenli modda kullanın.

  2. CSRF saldırılarının çoğunun, isteklerinde orijinal sunucunuzla farklı bir başlangıç ​​veya yönlendirme başlığı vardır. Başlıkta bunlardan herhangi birinin olup olmadığını kontrol edin, alan adınızdan geliyorlar mı yoksa yoklar mı? Değilse onları reddet. İstekte hem başlangıç ​​noktası hem de yönlendiren mevcut değilse endişelenmeyin. Bir sonraki adımda açıklayacağım X-XSRF-TOKEN başlık doğrulama sonuçlarının sonucuna güvenebilirsiniz.

  3. Tarayıcı, istek alanınız için çerezlerinizi otomatik olarak sağlarken, yararlı bir sınırlama vardır: Bir web sitesinde çalışan JavaScript kodu, diğer web sitelerinin çerezlerini okuyamaz. CSRF çözümümüzü oluşturmak için bundan yararlanabiliriz. CSRF saldırılarını önlemek için, şu şekilde adlandırılan ekstra bir Javascript tarafından okunabilir çerez oluşturmalıyız: XSRF-TOKEN. Bu çerez kullanıcı oturum açtığında oluşturulmalı ve rastgele, tahmin edilemeyen bir dize içermelidir. Bu numarayı JWT'ye özel bir iddia olarak da kaydediyoruz. JavaScript uygulaması her istekte bulunmak istediğinde, bu kodu okuması ve özel bir HTTP başlığında göndermesi gerekir. Bu işlemler (çerezi okuma, üstbilgiyi ayarlama) yalnızca JavaScript uygulamasının aynı alanında gerçekleştirilebildiğinden,

Açısal JS hayatınızı kolaylaştırır

Neyse ki, platformumuzda Angular JS kullanıyorum ve Angular CSRF token yaklaşımını paketler, bu da uygulamamızı kolaylaştırıyor. Açısal uygulamamızın sunucudan yaptığı her istek için, Açısal $httphizmet aşağıdaki işlemleri otomatik olarak yapar:

  • Geçerli alanda XSRF-TOKEN adında bir çerez arayın.
  • Bu çerez bulunursa, değeri okur ve X-XSRF-TOKEN başlığı olarak isteğe ekler.

Böylece müşteri tarafı uygulaması sizin için otomatik olarak halledilir! XSRF-TOKENSunucu tarafında geçerli etki alanında adlandırılmış bir çerez ayarlamamız gerekiyor ve API'miz istemciden herhangi bir çağrı aldığında, X-XSRF-TOKENüstbilgiyi kontrol etmeli XSRF-TOKENve JWT'deki ile karşılaştırmalıdır . Eğer eşleşirlerse, kullanıcı gerçektir. Aksi takdirde, sahte bir istektir ve yok sayabilirsiniz. Bu yöntem, "Çifte Gönder Çerez" yönteminden esinlenmiştir.

Dikkat

Gerçekte, hala XSS'ye karşı duyarlısınız, sadece saldırgan JWT jetonunu daha sonra kullanmak üzere çalamaz, ancak yine de XSS kullanarak kullanıcılarınızın adına istekte bulunabilir.

Daki JWT'yi saklamak ister localStorageya da değil HttpOnly çerez olarak XSRF-belirteci depolamak, hem XSS ile kolayca yakaladı edilebilir. HttpOnly çerezindeki JWT'niz bile XST yöntemi gibi gelişmiş bir XSS saldırısı ile yakalanabilir .

Bu nedenle, Çerezleri Çift Gönder yöntemine ek olarak, kaçan içerikler de dahil olmak üzere XSS'ye karşı her zaman en iyi uygulamaları izlemelisiniz. Bu, tarayıcının istemediğiniz bir şeyi yapmasına neden olacak tüm yürütülebilir kodları kaldırmak anlamına gelir. Bu genellikle // <![CDATA[JavaScript'in değerlendirilmesine neden olan etiketleri ve HTML niteliklerini kaldırmak anlamına gelir .

Daha fazlasını buradan okuyun:


1
@AranDehkharghani evet Sanırım özellikle JWT'yi değiştirirseniz ve API tarafından her kullanıldığında önceki JWT'yi sonlandırırsanız tekrar saldırılarını önler. bu, JWT'nizin bir defalık şifre (OTP) gibi olacağı anlamına gelir. JWT'yi platformunuzdaki güvenliği ne kadar önemsediğinize bağlı olarak farklı şekillerde kullanabilirsiniz.
Iman Sedighi

7
Bahsettiğiniz gibi, bir web sitesi XSS'ye karşı savunmasızsa, kullanıcının istismar edilmesi sadece zaman meselesidir. Görünüşe göre güvenlikteki çok küçük bir artış için önemli bir karmaşıklıkla ticaret yapıyoruz.
shusson

3
@shusson JWT'nizi korumak için XSS ve XSRF saldırılarına dikkat etmelisiniz. Güvenlikte çok küçük bir artış için önemli bir karmaşıklıkla ticaret yaptığınızı kabul etmiyorum. Güvenlik önemliyse, XSS güvenlik açıklarına sahip olmamak için tüm çabaları göstermeniz gerekir. Bu yöntem, simgenizi XSRF saldırılarına karşı korumak için tasarlanmıştır. ancak bu, XSS güvenlik açıklarını göz ardı edebileceğiniz anlamına gelmez.
Iman Sedighi

5
@ImanSedighi Jwt'yi bir çerezde saklayarak karmaşıklık ekliyorsunuz ve şimdi XSRF'ye karşı korunmanız gerekiyor. Öyleyse neden sadece kısa ömürlü jetonlarla yerel depolamayı kullanmıyor ve XSS'yi önlemeye konsantre olmuyorsunuz?
shusson

2
@Royi Namir: 10 $ 'lık bir SSL sertifikası kullanıyorsanız, Wireshark tarafından kimlik sahtekarlığı endişe etmemelidir! Web sitesinin güvenliği önemliyse, verileri şifrelemeli ve HTTPS protokolünü kullanmalısınız.
Iman Sedighi

2

JWT'lerin depolanması konusuna bir başka açı:

  1. JWT'ler asla yerel depolama alanınızda saklanmamalıdır
  2. Aslında, onlar bile cookie`leri edilmemelidir , sen çok sıkı CSRF koruması uygulamak mümkün olmadıkça

Motivasyon için bunu kontrol et

  • İd_token olarak JWT kullanıcı kimlik bilgilerinize benzer
  • Access_token olarak JWT, oturum simgenize benzer

En güvenli seçenek bellektir . Derin bir dalış için bunu kontrol et

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.