Durum bilgisi olmayan (oturumsuz) ve çerezsiz kimlik doğrulama nasıl yapılır?


107

Bob, bir şeyi başarmak için bir web uygulaması kullanıyor. Ve:

  • Tarayıcısı diyette, bu nedenle çerezleri desteklemiyor .
  • Web uygulaması popülerdir ve belirli bir anda birçok kullanıcıyla ilgilenir - iyi ölçeklendirilmesi gerekir . Oturumu tutmak eşzamanlı bağlantıların sayısına bir sınır getirdiği ve elbette göz ardı edilemeyecek bir performans cezası getireceği sürece oturumsuz bir sisteme sahip olmak isteyebiliriz :)

Bazı önemli notlar:

  • ulaşım güvenliğine sahibiz ( HTTPS ve en iyi arkadaşları);
  • Perdelerin ardında, web uygulaması mevcut kullanıcı adına harici hizmetlere pek çok işlemi devreder (bu sistemler Bob'u kullanıcılarından biri olarak tanır) - bu, onlara Bob'un kimlik bilgilerini iletmemiz gerektiği anlamına gelir .

Şimdi, Bob'un kimliğini nasıl doğrulayacağız (her istekte)? Böyle bir şeyi uygulamanın makul bir yolu hangisidir?

  • HTML formunda gizli alanlar aracılığıyla kimlik bilgileriyle tenis oynamak ... top kimlik bilgilerini ( kullanıcı adı ve şifre ) içerir ve iki raket sırasıyla tarayıcı ve web uygulamasıdır. Başka bir deyişle, verileri çerezler yerine form alanları aracılığıyla ileri geri taşıyabiliriz. Her web isteğinde, tarayıcı kimlik bilgilerini gönderir. Yine de, tek sayfalık bir uygulama söz konusu olduğunda , kimlik bilgilerini içeren web formu web sayfasının tüm ömrü boyunca canlı tutulabileceğinden , tenis oynamak yerine lastik bir duvara karşı squash oynamak gibi görünebilir. (ve sunucu, kimlik bilgilerini geri vermeyecek şekilde yapılandırılacaktır).
  • kullanıcı adı ve şifreyi sayfa bağlamında depolamak - JavaScript değişkenleri vb. Burada tek sayfa gereklidir, IMHO.
  • şifrelenmiş belirteç tabanlı kimlik doğrulama. Bu durumda, oturum açma eylemi, şifrelenmiş bir güvenlik belirtecinin (kullanıcı adı + parola + başka bir şey) oluşturulmasıyla sonuçlanır. Bu jeton müşteriye geri sunulacak ve gelecek isteklere jeton eşlik edecek. Bu mantıklı mı? Zaten HTTPS'ye sahibiz ...
  • diğerleri ...
  • son çare: bunu yapmayın, oturumda kimlik bilgilerini saklayın! Oturum iyidir. Kurabiye olsun veya olmasın.

Daha önce açıklanan fikirlerden herhangi biriyle ilgili olarak aklınıza herhangi bir web / güvenlik endişesi geliyor mu? Örneğin,

  • zaman aşımı - kimlik bilgileriyle birlikte bir zaman damgası tutabiliriz (zaman damgası = Bob'un kimlik bilgilerini girdiği zaman). Örneğin ne zaman ŞİMDİ - zaman damgası> eşiği , isteği reddedebiliriz.
  • Siteler arası komut dosyası koruması - hiçbir şekilde farklı olmamalı, değil mi?

Bunu okumak için zaman ayırdığınız için çok teşekkür ederim :)


2
Her URL'ye bir jeton ekleyebilirsiniz. ASP.NET bunu yapmak için (eski) bir moda sahiptir. Bu, işe yarayabileceğini kanıtlıyor.
usr

1
Herkes nerede? :)
turdus-merula

2
Mevcut seçenekler hakkında oldukça iyi bir fikriniz olduğunu düşünüyorum. Mantığınıza güvenin ve kendiniz karar verin.
usr

Silverlight Flash gibi bir eklenti bir seçenek mi?
Giu

@usr iyi bir fikir olup olmadığından emin değilim, sanki bir hacker'ın websever günlüklerinize ulaşması jetonunuzu çalabilir ve sisteminize giriş yapabilir.
GibboK

Yanıtlar:


74

Ah, bu soruları seviyorum - seans olmadan bir seansı sürdürmek.

Uygulama değerlendirmeleri sırasında bunu yapmanın birçok yolunu gördüm. Popüler yollardan biri, bahsettiğiniz tenis oynama şeklidir - her istekte kullanıcı kimliğini doğrulamak için kullanıcı adı ve şifre göndermek. Bu bence güvenli değil, özellikle uygulama tek sayfa değilse. Ayrıca, özellikle gelecekte kimlik doğrulamasına ek olarak uygulamanıza yetkilendirme eklemek istiyorsanız da ölçeklenebilir değildir (yine de oturum açma bilgilerine dayalı bir şey geliştirebileceğinizi tahmin ediyorum)

Tamamen durum bilgisiz olmasa da popüler bir mekanizma (JavaScript yürütmenizin olduğunu varsayarsak), oturum çerezini JavaScript'e yerleştirmektir. İçimdeki güvenlik görevlisi buna bağırıyor, ama aslında işe yarayabilir - her isteğin birX-Authentication-Tokenbaşlık veya bunun gibi bir şey ve kullanıcıyı doğrulamak için arka uçtaki bir veritabanına, bellekte dosya deposuna vb. eşlersiniz. Bu belirteç, belirttiğiniz zaman için bir zaman aşımına sahip olabilir ve zaman aşımına uğrarsa, kullanıcının yeniden oturum açması gerekir. Oldukça ölçeklenebilir - eğer onu bir veritabanında saklarsanız, tek bir SQL ifadesi yürütülür ve doğru dizinlerle, aynı anda birden çok kullanıcıyla bile yürütülmesi çok az zaman alacaktır. Buradaki yük testi kesinlikle yardımcı olacaktır. Soruyu doğru okursam, bu sizin şifrelenmiş belirteç mekanizmanız olurdu - ancak, kullanıcı adı + parola + başka herhangi bir kombinasyon kullanmak yerine 32 karakterden oluşan kriptografik olarak rastgele bir simge kullanmanızı şiddetle öneririm - bu şekilde kalır öngörülemez, ancak yine de kullanıcı kimliği veya benzeri bir şeyle ilişkilendirebilirsiniz.

Hangisini kullanırsanız kullanın, size güvenli bir şekilde gönderildiğinden emin olun. HTTPS sizi kablo boyunca korur, ancak oturum belirtecini URL aracılığıyla (veya daha kötüsü, URL aracılığıyla kimlik bilgilerini) sızdırmanız durumunda sizi korumaz. Bir başlık kullanmanızı veya bu mümkün değilse, jetonu her seferinde bir POST isteği yoluyla göndermenizi öneririm (bu, kullanıcının tarayıcısında gizli bir form alanı olduğu anlamına gelir.) POST isteği kullanmanın ikinci yaklaşımı CSRF savunmalarını kullanmalıdır, yalnızca durumda, jetonun kendisinin bir tür CSRF savunması olabileceğinden şüpheleniyorum.

Son olarak, ancak en az değil, arka uçta süresi dolmuş jetonları temizlemek için bir mekanizmaya sahip olduğunuzdan emin olun. Bu, geçmişte pek çok uygulamanın sıkıntısı olmuştur - hiçbir zaman ortadan kalkmayacak gibi görünen, hızla büyüyen kimlik doğrulama belirteçleri veritabanı. Birden fazla kullanıcı girişini desteklemeniz gerekiyorsa, sayıyı sınırladığınızdan veya her bir belirteç için daha kısa bir süre sınırınız olduğundan emin olun. Daha önce de söylediğim gibi yük testi bunun cevabı olabilir.

Aklıma gelen başka güvenlik endişeleri var, ancak bunlar bu aşamada ele alınamayacak kadar geniş - tüm kullanım (ve kötüye kullanım) vakalarını aklınızda tutarsanız, muhtemelen oldukça iyi bir uygulama yapabilmelisiniz. bu sistem.


Oyun çerçevesinin yaptığını yapıp kullanıcıya imzalı bir çerez göndermiyor musunuz? Ardından, bu çerez sonraki her istek için sunucuya geri gönderildi mi?
j

8
> Tarayıcısı diyette, bu nedenle çerezleri desteklemiyor.
Karthik Rangarajan

4
Bu önerilerden herhangi biri gerçekte vatansız / oturumsuz mu? Senin beş ana paragrafların (yazının 2013/12/19 baskısının gibi): 1. , tanıtım edilir 2. ekstra kludgy Web2.0 ™ -Flavored oturumları önermektedir, 3. sadece ihtar olduğunu 4. tartışmaktadır etkileri statefulness arasında ve 5. belirsiz bir outro ... bu nasıl olsun kabul etmedi edilir ?? En iyi ihtimalle teğetsel olarak bilgilendirici!
JamesTheAwesomeDude

1

Oturum açma seçeneği hakkında - genellikle oturumları misafirler için de desteklemek istediğinizi düşünüyorum.

Dolayısıyla, girişi zorunlu kılmak istiyorsanız, şifreli simge seçeneği iyi olabilir. Bir şekilde misafir oturumu için de iyi olabilir. Başka bir yönde, jetonu URL'ye eklemek ve tenis seçeneği arasında birleşirdim.

Yalnızca URL'de kimlik bilgileri göndermenin tehlikeli olabileceğine dikkat edin. Örneğin, jetonu HTTP yönlendirme başlığı aracılığıyla veya hatta trafiğinizi inceleyen veya bilgisayarınızı izleyen biri tarafından sızdırabilirsiniz.

Başka bir şey de, tanımlama bilgilerini kullanabilseniz bile, kendinizi Siteler Arası İstek Sahteciliği (CSRF) saldırılarından korumak için rastgele belirteç veya rastgele doğrulayıcı eklemenizi tavsiye ederim.


3
Oturum, sunucuda depolanan durumdur. Soru, durum bilgisiz kimlik doğrulamasını ister.
Kwebble
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.