Bu soru, biraz farklı bir biçimde, uzunluk olarak burada ele alınmıştır:
RESTful Kimlik Doğrulaması
Ancak bu sunucu tarafından ele alınır. Buna müşteri tarafından bakalım. Bunu yapmadan önce, önemli bir başlangıç var:
Javascript Kripto Umutsuz
Matasano'nun bu konudaki makalesi ünlüdür, ancak içerdiği dersler oldukça önemlidir:
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/
Özetlemek:
- Ortadaki bir adam, kripto kodunuzu önemsiz bir şekilde değiştirebilir
<script>
function hash_algorithm(password){ lol_nope_send_it_to_me_instead(password); }</script>
- Ortadaki adam saldırısı, SSL olmayan bir bağlantı üzerinden herhangi bir kaynağı sunan bir sayfaya karşı önemsizdir.
- SSL aldıktan sonra, gerçek kripto para kullanıyorsunuz.
Ve kendime ait bir sonuç eklemek için:
- Başarılı bir XSS saldırısı, SSL kullansanız bile, saldırganın müşterinizin tarayıcısında kod yürütmesine neden olabilir. başkasının tarayıcısındaki herhangi bir javascript kodu.
Bu, bir JavaScript istemcisi kullanmak istiyorsanız birçok RESTful kimlik doğrulama düzenini imkansız veya aptal hale getirir. Haydi bakalım!
HTTP Temel Yetkilendirme
İlk ve en önemlisi, HTTP Temel Yetkilendirme. En basit şemalar: her istekte bir ad ve şifre iletmeniz yeterlidir.
Bu, elbette kesinlikle SSL gerektirir, çünkü her istekte bir Base64 (geri dönüşümlü olarak) kodlanmış ad ve şifre geçirirsiniz. Hatta dinleyen herkes önemsiz bir şekilde kullanıcı adı ve şifre alabilir. "Temel Yetkilendirme güvensizdir" argümanlarının çoğu, "HTTP Üzerinden Temel Yetkilendirme" den gelen korkunç bir fikirdir.
Tarayıcı, pişmiş HTTP Temel Kimlik Doğrulama desteği sağlar, ancak günah gibi çirkindir ve muhtemelen uygulamanız için kullanmamalısınız. Alternatif, JavaScript'te kullanıcı adı ve parolayı saklamaktır.
Bu en RESTful çözümüdür. Sunucu herhangi bir durum bilgisi gerektirmez ve kullanıcı ile her bir etkileşimin kimliğini doğrular. Bazı REST meraklıları (çoğunlukla saman adamlar), herhangi bir devleti sürdürmenin sapkın olduğunu ve başka bir kimlik doğrulama yöntemi düşünürseniz ağızda köpüreceğini ısrarla vurguluyor. Bu tür standartlara uygunluğun teorik faydaları vardır - kutunun dışında Apache tarafından desteklenir - kalbinizi isterseniz, nesnelerinizi .htaccess dosyaları tarafından korunan klasörlerde saklayabilirsiniz!
Sorun ? İstemci tarafında bir kullanıcı adı ve parola önbelleğe alıyorsunuz. Bu, evil.ru'ya daha iyi bir çatlak verir - en temel XSS güvenlik açıkları bile, istemcinin kullanıcı adını ve şifresini kötü bir sunucuya ışınlamasına neden olabilir. Parolayı karma yaparak ve tuzlandırarak bu riski hafifletmeyi deneyebilirsiniz, ancak unutmayın: JavaScript Kripto Umutsuzdur . Bu riski Tarayıcı Temel Kimlik Doğrulama desteğine bırakarak hafifletebilirsiniz, ancak daha önce de belirtildiği gibi çirkin günah.
HTTP Özet Yetkisi
JQuery ile Özet kimlik doğrulaması mümkün müdür?
Daha "güvenli" bir kimlik doğrulama, bu bir istek / yanıt karma sorusudur. JavaScript Kripto dışında Umutsuz , bu yüzden sadece SSL üzerinde çalışır ve hala istemci tarafında kullanıcı adını ve şifreyi önbelleğe almanız gerekir, bu da HTTP Temel Yetkilendirme'den daha karmaşık hale gelir, ancak daha güvenli değildir .
Ek İmza Parametreleriyle Sorgu Kimlik Doğrulaması.
Parametrelerinizi nonce ve zamanlama verileriyle şifrelediğiniz (tekrarlama ve zamanlama saldırılarına karşı korumak için) başka bir daha "güvenli" kimlik doğrulama. Bunun en iyi örneklerinden biri, bildiğim kadarıyla bir REST sunucusunda kimlik doğrulaması uygulamak için oldukça çarpıcı bir yol olan OAuth 1.0 protokolüdür.
http://tools.ietf.org/html/rfc5849
Oh, ancak JavaScript için OAuth 1.0 istemcisi yok. Neden?
JavaScript Kripto Umutsuz , unutmayın. JavaScript OAuth 1.0'a SSL olmadan katılamaz ve istemcinin kullanıcı adını ve şifresini yerel olarak depolamanız gerekir - bu da Digest Auth ile aynı kategoriye girer - HTTP Temel Kimlik Doğrulama'dan daha karmaşıktır, ancak artık güvenli değildir .
Jeton
Kullanıcı bir kullanıcı adı ve parola gönderir ve karşılığında isteklerin kimliğini doğrulamak için kullanılabilecek bir belirteç alır.
Bu, HTTP Temel Yetkilendirme'den biraz daha güvenlidir, çünkü kullanıcı adı / şifre işlemi tamamlanır tamamlanmaz hassas verileri atabilirsiniz. Jetonlar "durum" teşkil ettiği ve sunucu uygulamasını daha karmaşık hale getirdiği için de daha az RESTful'dir.
SSL Sabit
Ancak, bir jeton almak için hala ilk kullanıcı adını ve şifreyi göndermeniz gerekiyor. Hassas bilgiler hala tehlikeye atılabilir JavaScript'inize dokunuyor.
Kullanıcılarınızın kimlik bilgilerini korumak için, saldırganları JavaScript'inizden uzak tutmanız ve yine de kablo üzerinden bir kullanıcı adı ve şifre göndermeniz gerekir. SSL Gerekli.
Jetonun Sona Ermesi
"Hey, bu simge çok uzun olduğunda, atın ve kullanıcının tekrar kimlik doğrulaması yap" gibi simge politikalarını uygulamak yaygındır. veya "Bu belirteci kullanmasına izin verilen tek IP adresinin olduğundan eminim XXX.XXX.XXX.XXX". Bu politikaların çoğu oldukça iyi fikirlerdir.
Firesheeping
Bununla birlikte, SSL olmadan bir belirteç kullanmak, 'sidejacking' adlı bir saldırıya karşı hala savunmasızdır: http://codebutler.github.io/firesheep/
Saldırgan, kullanıcının kimlik bilgilerini almaz, ancak yine de sizin kullanıcı gibi davranabilir, bu da oldukça kötü olabilir.
tl; dr: Tel üzerinden şifrelenmemiş jetonlar göndermek, saldırganların bu jetonları kolayca yakalayabileceği ve kullanıcı gibi davranabileceği anlamına gelir. FireSheep bunu çok kolaylaştıran bir programdır.
Ayrı, Daha Güvenli Bir Bölge
Çalıştırdığınız uygulama ne kadar büyük olursa, hassas verileri işleme biçiminizi değiştiren bazı kodları enjekte edemeyeceklerinden kesinlikle daha zor olur. CDN'nize kesinlikle güveniyor musunuz? Reklamverenleriniz? Kendi kod tabanınız?
Kredi kartı bilgileri için ortaktır ve kullanıcı adı ve şifre için daha az yaygındır - bazı uygulayıcılar 'hassas veri girişini' uygulamalarının geri kalanından ayrı bir sayfada, olabildiğince sıkı bir şekilde kontrol edilebilecek ve kilitlenebilecek bir sayfa, tercihen bir ile kimlik avı yapmak zordur.
Çerez (sadece Jeton anlamına gelir)
Kimlik doğrulama jetonunu bir çereze koymak mümkündür (ve yaygındır). Bu, jetonla yetkinin hiçbir özelliğini değiştirmez, daha kolay bir şeydir. Önceki argümanların tümü hala geçerlidir.
Oturum (hala sadece Jeton anlamına gelir)
Oturum Kimlik Doğrulaması yalnızca Token kimlik doğrulamasıdır, ancak biraz farklı bir şey gibi görünmesini sağlayan birkaç farklılıkla:
- Kullanıcılar, kimliği doğrulanmamış bir belirteçle başlar.
- Arka uç, kullanıcının belirtecine bağlı bir 'durum' nesnesini korur.
- Jeton bir çerezde sağlanır.
- Uygulama ortamı detayları sizden uzaklaştırır.
Bununla birlikte, gerçekten, Token Auth'tan farklı değil.
Bu, RESTful uygulamasından daha da uzaklaşır - durum nesneleriyle, durum bilgisi olan bir sunucudaki düz R 'yolunda daha da ileri gidersiniz.
OAuth 2.0
OAuth 2.0 "Yazılım A, Yazılım B'nin Kullanıcı X'in oturum açma kimlik bilgilerine erişmesine gerek kalmadan Yazılım B'nin Kullanıcı X'in verilerine nasıl erişebileceğini" sorununa bakar.
Uygulama, bir kullanıcının bir jeton alması için standart bir yoldur ve daha sonra bir üçüncü taraf hizmetinin "evet, bu kullanıcı ve bu jetonla eşleşmesi" ve verilerinin bir kısmını bizden alabilirsiniz.
Temel olarak, OAuth 2.0 sadece bir token protokolüdür. Diğer belirteç protokolleriyle aynı özellikleri gösterir - bu belirteçleri korumak için yine de SSL'ye ihtiyacınız vardır - bu belirteçlerin nasıl üretildiğini değiştirir.
OAuth 2.0'ın size yardımcı olabileceği iki yol vardır:
- Başkalarına Kimlik Doğrulama / Bilgi Sağlama
- Kimlik Doğrulamasını / Diğerlerinden Bilgi Alma
Ama konu söz konusu olduğunda, sen sadece ... jeton kullanıyorsun.
Sorunuza geri dönün
Yani, sorduğunuz soru şudur: "Simgemi bir çerezde saklamalı mıyım ve ortamımın otomatik oturum yönetiminin ayrıntılarla ilgilenmesini sağlamalı mıyım yoksa jetonumu Javascript'te saklamalı ve bu detayları kendim ele almalı mıyım?"
Cevap: sizi mutlu eden her şeyi yapın .
Otomatik oturum yönetimi ile ilgili olan şey, sahnelerin arkasında sizin için çok fazla büyü olması. Genellikle bu ayrıntıları kendiniz kontrol etmek daha hoştur.
21 yaşındayım, bu yüzden SSL evet
Diğer cevap: Her şey için https kullanın veya brigandlar kullanıcılarınızın şifrelerini ve jetonlarını çalacaktır.