belirteç parametresine sahip https URL'si: ne kadar güvenli?

Sitemizde, kullanıcılara özel bilgilerine (bir form aracılığıyla verilir) dayalı bir simülasyon sunuyoruz. Simülasyon sonuçlarına daha sonra geri dönmelerine izin vermek istiyoruz, ancak onları bir oturum açma / parola hesabı oluşturmaya zorlamadan.

Onlara sonuçlarını geri alabilecekleri bir bağlantı içeren bir e-posta göndermeyi düşündük. Ancak, doğal olarak, bu URL'yi güvenli hale getirmeliyiz çünkü özel veriler tehlikede.

Bu nedenle, URL'de bir jeton (40 karakterlik harf ve rakam kombinasyonu veya bir MD5 Hash gibi) geçirmeyi ve SSL kullanmayı planlıyoruz.

Sonunda şöyle bir e-posta alacaklardı:

Merhaba,
Sonuçlarınızı https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn adresinde geri alın

Bu konu hakkında ne düşünüyorsun? Yeterince güvenli mi? Token üretimi için bana ne önerirsiniz? URL parametrelerini bir https isteğinde geçirmeye ne dersiniz?

SSL, sorgu parametrelerini aktarım sırasında koruyacaktır; ancak, e-postanın kendisi güvenli değildir ve e-posta, hedefine ulaşmadan önce herhangi bir sayıda sunucuda geri dönebilir.

Ayrıca web sunucunuza bağlı olarak tam URL, günlük dosyalarına kaydedilebilir. Verilerin ne kadar hassas olduğuna bağlı olarak, BT çalışanlarınızın tüm belirteçlere erişmesini istemeyebilirsiniz.

Ek olarak, sorgu dizesini içeren URL, kullanıcı geçmişinize kaydedilerek aynı makinedeki diğer kullanıcıların URL'ye erişmesine izin verir.

Son olarak ve bunu çok güvensiz kılan şey, URL'nin herhangi bir kaynağa, hatta üçüncü taraf kaynaklara yönelik tüm isteklerin Referer başlığında gönderilmesidir. Dolayısıyla, örneğin Google Analytics kullanıyorsanız, Google'a URL jetonunu ve tümünü göndereceksiniz.

Bence bu kötü bir fikir.

Bunun için bir kurabiye kullanırdım. İş akışı şu şekilde olmalıdır:

1. Kullanıcı sitenize ilk kez geliyor.
2. Site bir çerez ayarlıyor
3. Kullanıcı verileri girer. Veriler, çerezde saklanan bazı anahtarlar kullanılarak DB'de saklanır.
4. Kullanıcı ayrıldığında, ona https: bağlantısı içeren bir e-posta gönderirsiniz
5. Kullanıcı geri döndüğünde site çerezi keşfeder ve kullanıcıya eski verileri sunabilir.

Artık kullanıcı, farklı bir makinede farklı bir tarayıcı kullanmak istiyor. Bu durumda, bir "transfer" düğmesi sunun. Kullanıcı bu düğmeyi tıkladığında bir "jeton" alacaktır. Çerezi sıfırlamak için bu belirteci başka bir bilgisayarda kullanabilir. Bu şekilde kullanıcı, jetonu ne kadar güvenli aktarmak istediğine karar verir.

SSL, aktarım sırasında verilerin içeriğini korur, ancak URL'den emin değilim.

Ne olursa olsun, bir saldırganın bu URL belirtecini yeniden kullanmasını önlemenin bir yolu, her simgenin yalnızca bir kez kullanılabileceğinden emin olmaktır. Hatta meşru kullanıcının bağlantıyı kullanmaya devam edebilmesi için bir çerez bile ayarlayabilirsiniz, ancak ilk erişimden sonra yalnızca çerezi olan biri için çalışacaktır.

Kullanıcının e-postası tehlikeye atılırsa ve bir saldırgan önce bağlantıyı alırsa, o zaman size sorulur. Ancak kullanıcının daha büyük sorunları da var.

E-posta doğası gereği güvensizdir. Bu bağlantıya tıklayıp verilere ulaşabilen biri varsa, onu gerçekten korumuyorsunuz demektir.

Token, SSL üzerinden geçerken güvenlidir. Sahip olacağınız sorun, URL'yi görüntüleyebilmesiyle (amaçlanmayanlar) insanlara sunulmasıdır.

SSN gibi özel bilgilerse, e-posta yoluyla bir URL göndereceğimi sanmıyorum. Site için bir kullanıcı adı ve şifre oluşturmalarını tercih ederim. Bu tür bilgileri tehlikeye atan bir e-postayı sizin ve onlar için tehlikeye atmak çok kolaydır. Birinin hesabına zarar verilirse, gerçekte kimin hatası olduğu sorulacaktır. Kesin bir CYA açısından ne kadar güvenli olursa o kadar iyidir.

Ciddi gizlilik sorunlarının olduğu bir durum için bunun yeterince güvenli olduğunu gerçekten düşünmem. URL'yi (muhtemelen açık metin) bir e-postayla gönderiyor olmanız, açık ara en zayıf bağlantıdır. Bundan sonra, (gerçek bir kimlik doğrulama mekanizmasının yapısından yoksun), iyi yapılandırılmış bir kullanıcı adı ve parola kurulumundan daha savunmasız olma olasılığı yüksek olan, belirteçlere kaba kuvvet saldırıları riski vardır.

Tesadüfen, https isteğindeki parametrelerle ilgili hiçbir sorun yoktur.

Olduğu gibi, kötü bir fikir olur. Kolay kullanım ile güvenliği korkutacaksınız. Daha önce söylendiği gibi, SSL yalnızca sunucu ve istemci tarayıcısı arasındaki bilgi aktarımını koruyacak ve yalnızca orta adam saldırısını önleyecektir. E-postalar çok riskli ve güvensizdir.

En iyisi, bilgilere erişmek için bir Kullanıcı adı ve parola kimlik doğrulaması olacaktır.

Kurabiye fikrini az çok seviyorum. Çerez bilgilerini de şifrelemelisiniz. Ayrıca, bir saldırı olasılığını sınırlamak için, salt ve anahtar kelime öbeği artı $ _SERVER ['HTTP_USER_AGENT'] içeren jetonu oluşturmalısınız. Doğrulama kullanımı için müşteri hakkında olabildiğince fazla hassas olmayan bilgiyi çerezde saklayın.

Anahtar kelime, kolay kullanım için çerezde saklanabilir, ancak çerezin de çalınabileceğini unutmayın = (.

Müşterinin, verisiyle birlikte veritabanında da saklanan anahtar ifadeyi yazmasına izin verin.

Veya anahtar, kişinin $ _SERVER ['HTTP_USER_AGENT'] parametrelerinde farklılık gösteren farklı bir makine kullanması veya sadece çerezi kaçırması durumunda kullanılabilir. Böylece çerez aktarılabilir veya ayarlanabilir.

Ayrıca, hassas verilerin veritabanında şifrelenmiş olduğundan emin olun. Asla bilemezsin ;)

Herhangi bir bilgisayar korsanı veritabanınıza erişirse, birçok kişisel bilginin serbestçe verilebileceğinin farkında mısınız?

Ondan sonra bunun fikir kadar kötü olmadığını söyleyebilirim. Hashing için çok güvenli olmadıkları için MD5 veya SHA1'i kullanmam. Kolayca "şifreleri çözülebilir" (şifreleme olmadığını biliyorum).

Aksi takdirde, e-posta ile gönderilmeyen ikinci bir bilgiyi bir parola olarak kullanabilirim. Nedeni oldukça basit, eğer birisi kullanıcının e-postasına erişirse (oturumunuzu sonlandırmazsanız hotmail ile oldukça kolaydır), kullanıcının gönderdiği tüm bilgilere erişebilir.

HTTPS'nin sitenizden son kullanıcıya gönderilen verileri güvenli hale getireceğini ve şifreleyeceğini unutmayın. Başka hiçbir şey, onu güvenli bir tünel olarak kabul edin. Ne daha fazla, ne de daha az.

Fikrinizden anladığıma göre, teoride birisi rastgele 40 karakterlik bir dizi veya MD5 karması yazıp başka birinin ayrıntılarını alabilir. Bu pek olası olmasa da, yalnızca bir kez olması gerekir.

Daha iyi bir çözüm, kullanıcıya bir belirteç gönderdikten sonra, adı, posta kodu, ssn veya bunların bir kombinasyonu gibi bazı ayrıntıları girmesini istemektir.