JWT belirteçlerinin sunucu tarafında işlenmesine yönelik en iyi uygulamalar [kapalı]

( bu konu kendi başına bir soru olduğundan ve NodeJS'ye vb.

Kimlik doğrulamalı bir REST API sunucusu uyguluyorum ve bir kullanıcının / login uç noktasında kullanıcı adı / parola ile oturum açabilmesi için JWT belirteci işlemeyi başarıyla uyguladım, bunun üzerine bir sunucu sırrından bir JWT belirteci oluşturulur ve istemcisi. Daha sonra belirteç, kimliği doğrulanmış her API isteğinde istemciden sunucuya iletilir ve bunun üzerine belirteci doğrulamak için sunucu sırrı kullanılır.

Bununla birlikte, gerçekten güvenli bir sistem oluşturmak için token'ın tam olarak nasıl ve ne ölçüde doğrulanması gerektiğine dair en iyi uygulamaları anlamaya çalışıyorum. Jetonun "doğrulanmasına" tam olarak ne dahil edilmelidir? İmzanın sunucu sırrı kullanılarak doğrulanması yeterli mi, yoksa belirteç ve / veya belirteç yükünü sunucuda depolanan bazı verilerle karşılaştırmalı mıyım?

Belirteç tabanlı bir kimlik doğrulama sistemi, bir simge elde etmenin bir kullanıcının parolasını elde etmekten eşit veya daha zor olması koşuluyla, her istekte kullanıcı adı / parolayı geçirmek kadar güvenli olacaktır. Ancak, gördüğüm örneklerde, bir belirteç oluşturmak için gereken tek bilgi kullanıcı adı ve sunucu tarafı sırrıdır. Bu, kötü niyetli bir kullanıcının bir dakika boyunca sunucu sırrına ilişkin bilgi edindiğini varsayarsak, artık herhangi bir kullanıcı adına belirteçler üretebileceği anlamına gelmiyor mu? ama aslında tüm kullanıcı hesaplarına?

Bu beni sorulara getiriyor:

1) JWT belirteç doğrulaması, yalnızca sunucu sırrının bütünlüğüne bağlı olarak veya ayrı bir doğrulama mekanizmasıyla birlikte belirtecin kendisinin imzasını doğrulamakla mı sınırlandırılmalıdır?

• Bazı durumlarda, / login uç noktası üzerinden başarılı bir şekilde oturum açıldığında bir oturumun kurulduğu belirteçlerin ve sunucu oturumlarının birleşik kullanımını gördüm. API istekleri belirteci doğrular ve ayrıca belirteçte bulunan kodu çözülmüş verileri oturumda depolanan bazı verilerle karşılaştırır. Ancak, oturum kullanmak çerez kullanmak anlamına gelir ve bir anlamda belirteç tabanlı bir yaklaşım kullanma amacını ortadan kaldırır. Ayrıca belirli müşteriler için sorunlara neden olabilir.

• Bir saldırganın "geçerli" belirteçler üretebilmesi için sunucu sırrının ele geçirilmesi durumunda bile, yalnızca / login uç noktası aracılığıyla oluşturulan tam belirteçlerin üretilebilmesini sağlamak için, sunucunun şu anda kullanılmakta olan tüm simgeleri bir memcache veya benzerinde tuttuğu düşünülebilir. kabul edilecektir. Bu makul mü yoksa sadece gereksiz / aşırı mı?

2) JWT imza doğrulaması belirteçleri doğrulamanın tek yolu ise, yani sunucu sırrının bütünlüğü kırılma noktasıysa, sunucu sırları nasıl yönetilmelidir? Bir ortam değişkeninden okundu ve dağıtılan yığın başına bir kez oluşturuldu mu (rastgele mi?)? Periyodik olarak yeniden yenilenen veya döndürülen (ve eğer öyleyse, rotasyondan önce oluşturulan ancak rotasyondan sonra doğrulanması gereken mevcut geçerli jetonların nasıl işleneceği, belki de sunucu herhangi bir zamanda geçerli ve önceki sırrı tutarsa ​​yeterlidir) ? Başka bir şey?

Belki de sunucu sırrının tehlikeye girme riski söz konusu olduğunda aşırı derecede paranoyak oluyorum, ki bu elbette tüm kriptografik durumlarda ele alınması gereken daha genel bir sorundur ...

Ben de başvurum için jetonlarla oynuyorum. Hiçbir şekilde uzman olmasam da konuyla ilgili bazı deneyimlerimi ve düşüncelerimi paylaşabilirim.

JWT'lerin amacı esas olarak bütünlüktür. Sunucunuz için kendisine sağlanan jetonun orijinal olduğunu ve sunucunuz tarafından sağlandığını doğrulayan bir mekanizma sağlar. Sırrınız aracılığıyla oluşturulan imza bunu sağlar. Yani, evet, eğer sırrınız bir şekilde sızdırılırsa, bu kişi sunucunuzun kendi olduğunu düşüneceği tokenlar oluşturabilir. Belirteç tabanlı bir sistem, yalnızca imza doğrulaması nedeniyle kullanıcı adı / şifre sisteminizden daha güvenli olacaktır. Ve bu durumda, yine de birisinin sırrınız varsa, sisteminizin, sahte belirteçler yapan birinden daha başa çıkması gereken başka güvenlik sorunları vardır (ve o zaman bile, sırrı değiştirmek, eski sırla yapılan tüm belirteçlerin artık geçersiz olmasını sağlar).

Yüke gelince, imza size yalnızca size sağlanan jetonun tam olarak sunucunuzun gönderdiği zamanki gibi olduğunu söyleyecektir. Yük içeriklerinin uygulamanız için geçerli veya uygun olduğunun doğrulanması açıkça size bağlıdır.

Sorularınız için:

1.) Sınırlı deneyimime göre, jetonlarınızı ikinci bir sistemle doğrulamak kesinlikle daha iyidir. Basitçe imzayı doğrulamak, jetonun sırrınızla oluşturulduğu anlamına gelir. Oluşturulan herhangi bir jetonu bir tür DB'de (redis, memcache / sql / mongo veya başka bir depolama) depolamak, yalnızca sunucunuzun oluşturduğu jetonları kabul etmenizi sağlamanın harika bir yoludur. Bu senaryoda, sırrınız sızdırılsa bile, üretilen herhangi bir token zaten geçerli olmayacağından çok önemli olmayacaktır. Sistemimle benimsediğim yaklaşım budur - oluşturulan tüm belirteçler bir DB'de (redis) saklanır ve her istekte, belirteci kabul etmeden önce belirtecimde olduğunu doğrularım. Bu şekilde, belirteçler herhangi bir nedenle iptal edilebilir, örneğin bir şekilde doğaya salınan belirteçler, kullanıcı oturumu kapatma, şifre değişiklikleri, gizli değişiklikler vb.

2.) Bu, pek tecrübem olmayan bir şey ve bir güvenlik uzmanı olmadığım için hala aktif olarak araştırdığım bir şey. Herhangi bir kaynak bulursanız, bunları buraya göndermekten çekinmeyin! Şu anda, sadece diskten yüklediğim özel bir anahtar kullanıyorum, ancak açıkçası bu en iyi veya en güvenli çözüm olmaktan çok uzak.

JWT'leri uygulamanızda uygularken göz önünde bulundurmanız gereken bazı şeyler şunlardır:

• JWT ömrünüzü nispeten kısa tutun ve ömrünün sunucuda yönetilmesini sağlayın. Yapmazsanız ve daha sonra JWT'lerinizde daha fazla bilgiye ihtiyaç duymanız gerekirse, değişikliğinizi uygulayabilmek için 2 sürümü desteklemeniz veya eski JWT'lerinizin süresinin dolmasını beklemeniz gerekir. Yalnızca iatjwt'deki alana bakarsanız ve alanı görmezden gelirseniz, sunucuda kolayca yönetebilirsiniz exp.

• JWT'nize isteğin url'sini eklemeyi düşünün. Örneğin, JWT'nizin uç noktada kullanılmasını istiyorsanız, yalnızca bu yolda kullanıldığından emin olmak için JWT'nizdeki /my/test/pathgibi bir alan 'url':'/my/test/path'ekleyin. Bunu yapmazsanız, insanların JWT'lerinizi başka uç noktalarda, hatta kendileri için yaratılmadıklarında bile kullanmaya başladığını görebilirsiniz. Bunun yerine bir md5 (url) eklemeyi de düşünebilirsiniz, çünkü JWT'de büyük bir url'ye sahip olmak JWT'yi çok daha büyük hale getirecek ve oldukça büyük olabilirler.

• JWT'ler bir API'de uygulanıyorsa, JWT süre sonu her kullanım durumu tarafından yapılandırılabilir olmalıdır. Örneğin, JWT'ler için 10 farklı kullanım durumu için 10 uç noktanız varsa, her uç noktanın farklı zamanlarda sona eren JWT'leri kabul etmesini sağlayabileceğinizden emin olun. Bu, bazı uç noktaları diğerlerinden daha fazla kilitlemenize olanak tanır; örneğin, bir uç nokta tarafından sunulan veriler çok hassas ise.

• JWT'lerin belirli bir süre sonra sona ermesi yerine, her ikisini de destekleyen JWT'leri uygulamayı düşünün:

  • N kullanım - yalnızca süresi dolmadan önce N kez kullanılabilir ve
  • belirli bir süre sonra sona erer (yalnızca tek kullanımlık bir jetonunuz varsa, kullanılmadığı takdirde sonsuza kadar yaşamasını istemezsiniz, değil mi?)

• Tüm JWT kimlik doğrulama hataları, JWT kimlik doğrulamasının neden başarısız olduğunu belirten bir "hata" yanıt başlığı oluşturmalıdır. örneğin "süresi doldu", "kullanım kalmadı", "iptal edildi", vb. Bu, uygulayıcıların JWT'lerinin neden başarısız olduğunu anlamalarına yardımcı olur.

• Bilgi sızdırdıklarından ve bilgisayar korsanlarına bir denetim ölçüsü verdiklerinden JWT'lerinizin "başlıklarını" yok saymayı düşünün. Bu, çoğunlukla algbaşlıktaki alanla ilgilidir - bunu göz ardı edin ve sadece üstbilginin desteklemek istediğiniz şey olduğunu varsayın, çünkü bu, korsanların Nonealgoritmayı kullanmaya çalışmasını önleyerek imza güvenlik kontrolünü kaldırır.

• JWT'ler, jetonu hangi uygulamanın oluşturduğunu açıklayan bir tanımlayıcı içermelidir. Örneğin, JWT'leriniz 2 farklı müşteri, mychat ve myclassifiedsapp tarafından oluşturuluyorsa, her biri proje adını veya JWT'deki "iss" alanına benzer bir şeyi içermelidir, ör. "İss": "mychat"

• JWT'ler, günlük dosyalarında oturum açmamalıdır. Bir JWT'nin içeriği kaydedilebilir, ancak JWT'nin kendisi kaydedilemez. Bu, geliştiricilerin veya başkalarının JWT'leri günlük dosyalarından alamamasını ve diğer kullanıcı hesaplarına bir şeyler yapamamasını sağlar.
• Bilgisayar korsanlarının imzalamadan jeton oluşturmasını önlemek için JWT uygulamanızın "Yok" algoritmasına izin vermediğinden emin olun. JWT'nizin "başlığını" göz ardı ederek bu hata sınıfından tamamen kaçınılabilir.
• Kesinlikle kullanmayı düşünün iat(yayınlanan) yerine expsizin JWTS içinde (son kullanma). Neden? Yana iatJWT oluşturuldu temelde yollarla, bu JWT oluşturma tarihine göre, sona sunucuda ayarlamasını sağlar. Gelecekte biri exp20 yıl sonra vefat ederse , JWT temelde sonsuza kadar yaşar! JWT'lerin ileride olması durumunda süresinin otomatik olarak sona ereceğini unutmayın iat, ancak istemcinin zamanının sunucu saatiyle biraz uyumsuz olması durumunda biraz kıpırdama odası (örneğin 10 saniye) bekleyin .
• Bir json yükünden JWT'ler oluşturmak için bir uç nokta uygulamayı düşünün ve tüm uygulama istemcilerinizi JWT'lerini oluşturmak için bu uç noktayı kullanmaya zorlayın. Bu, JWT'lerin tek bir yerde nasıl oluşturulduğu ile istediğiniz güvenlik sorunlarını kolayca çözebilmenizi sağlar. Bunu doğrudan uygulamamızda yapmadık ve şimdi JWT sunucu tarafı güvenlik güncellemelerini yavaşça dağıtmamız gerekiyor çünkü 5 farklı istemcimizin uygulama için zamana ihtiyacı var. Ayrıca, oluşturma uç noktanızın JWT'lerin oluşturması için bir dizi json yükünü kabul etmesini sağlayın; bu, müşterileriniz için bu uç noktaya gelen http isteklerinin sayısını azaltacaktır.
• JWT'leriniz, oturum bazında kullanımı da destekleyen uç noktalarda kullanılacaksa, JWT'nize isteği karşılamak için gereken hiçbir şey koymadığınızdan emin olun. Uç noktanızın JWT sağlanmadığında bir oturumla çalışmasını sağlarsanız bunu kolayca yapabilirsiniz.
• Bu nedenle, JWT'nin genel olarak konuşması, bir tür kullanıcı kimliği veya grup kimliği içerir ve bu bilgilere dayanarak sisteminizin bir kısmına erişime izin verir. Özellikle hassas verilere erişim sağlıyorsa, uygulamanızın bir alanındaki kullanıcıların diğer kullanıcıların kimliğine bürünmesine izin vermediğinizden emin olun. Neden? JWT oluşturma süreciniz yalnızca "dahili" hizmetler tarafından erişilebilir olsa bile, geliştiriciler veya diğer dahili ekipler herhangi bir kullanıcı için verilere erişmek için JWT'ler oluşturabilir, örneğin rastgele bir müşterinin şirketinin CEO'su. Örneğin, uygulamanız müşteriler için mali kayıtlara erişim sağlıyorsa, bir JWT oluşturarak bir geliştirici herhangi bir şirketin mali kayıtlarını alabilir! Ve bir bilgisayar korsanı iç ağınıza bir şekilde girerse, aynı şeyi yapabilir.
• Bir JWT içeren herhangi bir url'nin herhangi bir şekilde önbelleğe alınmasına izin verecekseniz, farklı kullanıcılar için izinlerin JWT'ye değil, URL'ye dahil edildiğinden emin olun. Neden? Çünkü kullanıcılar, almamaları gereken verileri elde edebilir. Örneğin, bir süper kullanıcının uygulamanıza giriş yaptığını ve aşağıdaki url'yi istediğini /mysite/userInfo?jwt=XXXve bu url'nin önbelleğe alındığını varsayalım. Çıkış yaparlar ve birkaç dakika sonra, normal bir kullanıcı uygulamanıza giriş yapar. Önbelleğe alınmış içeriği alacaklar - bir süper kullanıcı hakkında bilgilerle birlikte! Bu, özellikle Akamai gibi bir CDN kullandığınız ve bazı dosyaların daha uzun süre yaşamasına izin verdiğiniz durumlarda, istemcide daha az ve sunucuda daha fazla olma eğilimindedir. Bu, ilgili kullanıcı bilgilerini url'ye ekleyerek ve bunu sunucuda doğrulayarak düzeltilebilir, örneğin önbelleğe alınmış istekler için bile/mysite/userInfo?id=52&jwt=XXX
• Jwt'nizin bir oturum tanımlama bilgisi gibi kullanılması amaçlanıyorsa ve yalnızca jwt'nin oluşturulduğu makinede çalışması gerekiyorsa, jwt'nize bir jti alanı eklemeyi düşünmelisiniz . Bu temelde bir CSRF belirtecidir ve JWT'nizin bir kullanıcının tarayıcısından diğerlerine geçirilememesini sağlar.

Uzman olduğumu sanmıyorum ama Jwt hakkında bazı düşüncelerimi paylaşmak istiyorum.

• 1: Akshay'ın dediği gibi, jetonunuzu doğrulamak için ikinci bir sisteme sahip olmak daha iyidir.

  a .: Bununla başa çıkma şeklim: Üretilen hash'i süresi dolmuş bir oturum deposunda saklıyorum. Bir belirteci doğrulamak için sunucu tarafından verilmiş olması gerekir.

  b.: Kullanılan imza yönteminin kontrol edilmesi gereken en az bir şey var. Örneğin :

  header :
  {
    "alg": "none",
    "typ": "JWT"
  }
  

JWT'yi doğrulayan bazı kütüphaneler, hash'i kontrol etmeden bunu kabul eder. Bu, bir hacker'ın jetonu imzalarken kullandığını bilmeden kendisine bazı haklar verebileceği anlamına gelir. Bunun olmayacağından daima emin olun. https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/

c .: Oturum kimliğine sahip bir çerez kullanmak, jetonunuzu doğrulamak için yararlı olmayacaktır. Birisi bir lambda kullanıcısının oturumunu ele geçirmek isterse, sadece bir dinleyici kullanması gerekir (örneğin: wireshark). Bu bilgisayar korsanı her iki bilgiye de aynı anda sahip olacaktı.

• 2: Her sır için aynıdır. Bunu bilmenin her zaman bir yolu vardır.

Bununla başa çıkma şeklim 1.a noktasıyla bağlantılı. : Rastgele değişkenle karıştırılmış bir sırrım var. Sır, her belirteç için benzersizdir.

Bununla birlikte, gerçekten güvenli bir sistem oluşturmak için token'ın tam olarak nasıl ve ne ölçüde doğrulanması gerektiğine dair en iyi uygulamaları anlamaya çalışıyorum.

Mümkün olan en iyi güvenliği istiyorsanız, en iyi uygulamaları körü körüne takip etmemelisiniz. En iyi yol, ne yaptığınızı anlamak (sorunuzu gördüğümde sorun olmadığını düşünüyorum) ve ardından ihtiyacınız olan güvenliği değerlendirmektir. Mossad gizli verilerinize erişmek isterse, her zaman bir yol bulacaktır. (Bu blog gönderisini beğendim: https://www.schneier.com/blog/archives/2015/08/mickens_on_secu.html )

Burada birçok iyi cevap var. En alakalı olduğunu düşündüğüm yanıtlardan bazılarını birleştirip birkaç öneri daha ekleyeceğim.

1) JWT belirteç doğrulaması, yalnızca sunucu sırrının bütünlüğüne bağlı olarak veya ayrı bir doğrulama mekanizmasıyla birlikte belirtecin kendisinin imzasını doğrulamakla mı sınırlandırılmalıdır?

Hayır, belirteç sırrının tehlikeye atılmasıyla ilgili olmayan nedenlerden dolayı. Bir kullanıcı bir kullanıcı adı ve parola aracılığıyla her oturum açtığında, yetkilendirme sunucusu ya oluşturulan belirteci ya da oluşturulan belirteçle ilgili meta verileri depolamalıdır. Bu meta verileri bir yetkilendirme kaydı olarak düşünün. Belirli bir kullanıcı ve uygulama çifti, herhangi bir zamanda yalnızca bir geçerli token veya yetkiye sahip olmalıdır. Kullanışlı meta veriler, erişim jetonuyla ilişkili kullanıcı kimliği, uygulama kimliği ve erişim jetonunun verildiği zamandır (bu, mevcut erişim jetonlarının iptaline ve yeni bir erişim jetonunun verilmesine izin verir). Her API isteğinde, belirtecin uygun meta verileri içerdiğini doğrulayın. Her erişim belirtecinin ne zaman verildiğiyle ilgili bilgileri saklamanız gerekir, böylece bir kullanıcı, hesap kimlik bilgilerinin güvenliği ihlal edildiğinde mevcut erişim belirteçlerini iptal edebilir ve yeniden oturum açıp yeni bir erişim belirteci kullanmaya başlayabilir. Bu, veritabanını erişim belirtecinin verildiği zamanla (oluşturulan yetkilendirme zamanı) güncelleyecektir. Her API isteğinde, erişim belirtecinin düzenlenme zamanının, oluşturulan yetkilendirme zamanından sonra olduğunu kontrol edin.

Diğer güvenlik önlemleri arasında JWT'leri kaydetmemek ve SHA256 gibi güvenli bir imzalama algoritması gerektirmek yer alıyordu.

2) JWT imza doğrulaması belirteçleri doğrulamanın tek yolu ise, yani sunucu sırrının bütünlüğü kırılma noktasıysa, sunucu sırları nasıl yönetilmelidir?

Sunucu gizli dizilerinin tehlikeye atılması, bir saldırganın herhangi bir kullanıcı için erişim belirteçleri vermesine olanak tanır ve erişim belirteci verilerinin 1. adımda depolanması, sunucunun bu erişim belirteçlerini kabul etmesini engellemez. Örneğin, bir kullanıcıya bir erişim belirteci verildiğini ve daha sonra bir saldırganın o kullanıcı için bir erişim belirteci oluşturduğunu varsayalım. Erişim belirtecinin yetkilendirme zamanı geçerli olacaktır.

Akshay Dhalwala'nın dediği gibi, sunucu tarafındaki sırrınız tehlikeye atılırsa, başa çıkmanız gereken daha büyük sorunlar vardır çünkü bu, bir saldırganın dahili ağınızı, kaynak kodu deponuzu veya her ikisini de tehlikeye attığı anlamına gelir.

Bununla birlikte, güvenliği ihlal edilmiş bir sunucu sırrının zararını azaltmak ve sırları kaynak kodda saklamaktan kaçınmak için bir sistem, https://zookeeper.apache.org gibi bir koordinasyon hizmeti kullanarak belirteç gizli rotasyonu içerir.. Birkaç saatte bir uygulama sırrı oluşturmak için bir cron işi kullanın (erişim belirteçleriniz ne kadar süreyle geçerli olursa olsun) ve güncellenmiş sırrı Zookeeper'a aktarın. Belirteç sırrını bilmesi gereken her uygulama sunucusunda, ZK düğüm değeri her değiştiğinde güncellenen bir ZK istemcisi yapılandırın. Bir birincil ve ikincil sırrı saklayın ve belirteç sırrı her değiştirildiğinde, yeni belirteç sırrını birincil, eski belirteç sırrını ikincil olarak ayarlayın. Bu şekilde, mevcut geçerli belirteçler, ikincil sırra karşı doğrulanacaklarından yine de geçerli olacaktır. İkincil sırrın yerini eski birincil sırrı aldığında, ikincil sır ile verilen tüm erişim belirteçlerinin süresi yine de dolmuş olur.

IETF'in oAuth Çalışma Grubunda devam eden bir RFC'si var bkz: https://tools.ietf.org/id/draft-ietf-oauth-jwt-bcp-05.html