Özel, yönetilemez URL'ler şifre tabanlı kimlik doğrulamasına eşdeğer midir?

Bir kaynağı web üzerinde göstermek istiyorum. Bu kaynağı korumak istiyorum: yalnızca belirli kişilerin erişimine açık olduğundan emin olmak için.

Bir tür şifre tabanlı kimlik doğrulama ayarlayabilirim . Örneğin, kaynağa yalnızca dosya göndermeden önce gelen doğru kimlik bilgileri (belki de bazı kullanıcıların veri tabanına karşı) gelen isteklerini kontrol eden bir web sunucusu üzerinden erişime izin verebilirim.

Alternatif olarak sadece özel bir URL kullanabilirim . Yani, kaynağı basitçe tahmin edilemeyecek bir yoldan, örneğin https://example.com/23idcojj20ijf...tam dizgiyi bilenlere erişimi kısıtlayan bir şekilde barındırabilirim.

Bu kaynağa erişmek isteyen bir kötülük bakış açısından, bu yaklaşımlar eşdeğer midir? Değilse, onları farklı kılan nedir? Sürdürülebilirlik açısından, birini veya diğerini uygulamadan önce bilmem gereken yaklaşımın artıları ve eksileri var mı?

Özel bir URL, URL'nin bit boyutu kimlik bilgilerininkiyle aynı olsa bile, kimlik bilgileriyle kimlik doğrulamasından biraz daha zayıftır. Bunun nedeni, URL'nin daha kolay "sızıntı yapması" olabilir. Tarayıcıda önbelleğe alınır, sunucuda oturum açar vb. Giden bağlantılarınız varsa, özel URL diğer sitelerdeki yönlendirici başlığında görünebilir. (Omzunuza bakan kişiler tarafından da görülebilir.)

Sızıntı yaparsa (kaza sonucu veya kullanıcının dikkatsizliği nedeniyle), herkese açık ve Google tarafından endekslenebilir; bu da bir saldırganın sitenize sızan tüm URL'leri kolayca aramasını sağlar!

Bu nedenle, özel URL'ler genellikle yalnızca şifre sıfırlama gibi tek seferlik işlemler için kullanılır ve genellikle yalnızca sınırlı bir süre için etkindirler.

Bilgi güvenliği'nde ilgili bir konu var: Rastgele URL'ler profil fotoğraflarını korumanın güvenli bir yolu mu? - bir cevap bu haberi paylaşıyor: Dropbox, Google’da vergi beyannamelerinin sona ermesinden sonra eski paylaşılan bağlantıları devre dışı bırakıyor . Bu yüzden sadece teorik bir risk değil.

Not:

Birçok insan "özel" bir URL'yi kimlik doğrulamasıyla karıştırıyor gibi görünüyor. Ayrıca, bağlantıyı güvenilir bir varlık aracılığıyla göndermenin iki faktörlü kimlik doğrulaması için bir girişim olduğu anlaşılıyor. Açık olmak gerekirse, tahmin edilmesi yeterince zor olsa da halka açık bir kaynaktan bahsediyoruz.

Özel bir URL kullanırken, her zaman bunun tehlikeye girebileceğini varsaymalısınız - böyle bir URL'yi tasarlamalısınız; böylece, tehlikeye atılsa bile, kaynak saldırgana bilgi sızdırmaz.

Özel / tahmin edilmesi zor URL’ler, şifre tabanlı kimlik doğrulaması ile aynı değildir. Doğal olarak, özel URL'ler hiç özel değildir - bunlar halka açık kaynaklardır. "Özel" URL teriminin bir yanlış isim olduğunu düşünüyorum, bunun yerine "belirsiz" URL’lerdir.

"Özel" bir URL kullanmanın kabul edilebilir olduğu bazı durumlar vardır, ancak bunlar şifre doğrulama veya anahtar tabanlı kimlik doğrulama gibi geleneksel kimlik doğrulama yöntemlerinden doğal olarak daha az güvenlidir.

Yaygın olarak kullanılan "özel" URL’leri gördüğüm yerlerden bazıları:

1. Şifre Sıfırlama e-postaları
2. Sertifika Oluşturma e-postaları
3. Hesap / e-posta onay e-postaları
4. Satın alınan içeriğin teslimi (e-kitaplar, vb.)
5. Uçuş check-in, baskı biniş kartı, diğer kimlik doğrulama işlemleri geleneksel kimlik doğrulamanın yanı sıra özel URL'ler de kullanır

Buradaki ortak nokta, rastgele URL’lerin tipik olarak yalnızca tek seferlik işlemler için iyi olmasıdır. Ayrıca, geleneksel kimlik doğrulama ve rastgele URL'ler birbirini dışlayan değil - aslında, bir kaynak sunarken ek güvenlik sağlamak için birbirleriyle birlikte kullanılabilirler.

Robert Harvey’nin belirttiği gibi, rasgele / özel bir URL’yi güvenli bir şekilde kullanmanın tek yolu, sayfayı dinamik olarak oluşturmak ve URL’yi kullanıcının kimliği doğrulanmış sayılabilecek şekilde sunmaktır. Bu e-posta, SMS, vb. Olabilir.

Rasgele oluşturulmuş / özel bir URL genellikle birkaç özelliğe sahiptir:

1. Makul bir süre sonra sona ermelidir.
2. Tek kullanımlık bir URL olmalıdır: IE, ilk erişime girdikten sonra süresi bitmelidir.
3. Kullanıcının güvenli bir şekilde kimliğini doğrulamak için kullanıcının kimliğini güvence altına alması gereken başka bir işletmeye ertelemelidir. (Bağlantıyı e-posta veya SMS yoluyla göndererek vb.)
4. Modern bir bilgisayarın URL'yi son kullanma tarihinden önceki zaman dilimi içinde kaba bir şekilde zorlaması imkansız olmalıdır - ya kaynağı ortaya çıkaran API'yi sınırlandırarak veya tahmin edilemeyecek kadar yeterli entropi ile bir URL bitiş noktası oluşturarak.
5. Kullanıcı hakkında bilgi sızdırmamalıdır. IE: Sayfa bir şifreyi sıfırlamaksa: sayfa, talep edenin hesap bilgilerini görüntülememelidir. Alice bir şifre sıfırlama bağlantısı isterse ve Bob URL’yi bir şekilde tahmin ederse, Bob’in kimin şifresini sıfırladığını bilmesi gerekmez.
6. Kullanıcı hakkında bilgi sızdırıyorsa, geleneksel kimlik doğrulamanın üstünde kullanılmalıdır; örneğin, bir çerez seti varsa veya oturum kimliği hala geçerliyse, bir sayfa kimliği doğrulanmış bir kullanıcı olarak kabul edilebilir.

Farklı kaynaklar farklı güvenlik seviyeleri gerektirir. Örneğin, bazı arkadaşlarınızla gizli bir tarif paylaşmak isterseniz, onlarla paylaşmak için rastgele / özel bir URL kullanmak kabul edilebilir. Ancak, kaynak bir kişinin kimliğini çalmak veya hesaplarını diğer hizmet sağlayıcılarla riske atmak için kullanılabilirse, büyük olasılıkla bu kaynağa erişimi kısıtlama konusunda çok daha fazla önem verirsiniz.

Neredeyse tüm kimlik doğrulama şemaları, bir sır bildiğinizi kanıtlamak için kaynamaktadır. Gizli bir şifre veya gizli bir URL bildiğinizi kanıtlayarak, bazı servislerde kendinizi doğrulayın veya ...

Bazı daha gelişmiş protokoller (örneğin, OAUTH, Kerberos, ...), sırrı gerçekten iletmeden sırrı bildiğinizi kanıtlamanızı sağlar . Bu önemlidir, çünkü tahmin etmenin yanı sıra “yönetilemez” bir sır elde etmenin daha fazla yolu vardır.

Sizinle aynı İnternet kafede oturuyordum, "yönetilemez" URL’nizi yazdığınızda WiFi bağlantınızı gizlice dinledim. Bu noktada, eğer SSL kullanmıyorsanız ya da SSL uygulamanızdaki en yeni hatadan yararlanabilseydim, o zaman ben de sizin sırrınızı bilirdim.

Zaten bu konuda çok sayıda iyi cevap var, fakat doğrudan soruyu ele almak için:

Bu kaynağa erişmek isteyen bir kötülük bakış açısından, bu yaklaşımlar eşdeğer midir? Değilse, onları farklı kılan nedir?

Bir tanım yapmama izin verin. "Kimlik doğrulama", bir kimlik iddiasını kanıtlamak için kimlik bilgileri sağlamaktır. Erişim kontrolü genellikle kullanıcının tanımlanmasına dayanır.

Gizli URL’niz belirli bir kullanıcıya bağlı değil. Diğerlerinin de belirttiği gibi, bir proxy’nin günlük dosyasına veya google tarafından endekslenen bir arama isteğine veya sızabileceği birçok yolla sonuçlanabilir.

Öte yandan, benzersiz bir kullanıcı hesabına bir şifre bağlanır. Sıfırlama olanağınız veya yalnızca kullanıcının ev konumundan veya bilinen IP adresinden veya herhangi bir sayıda diğer kontrollerden kullanılmasına izin verebilirsiniz.

Bir kullanıcı adı / şifre size erişimin daha ayrıntılı kontrolünü verir.

Erişim kontrolü bir kaynağın (nesnenin) bir kaynağa (nesnenin) erişimine izin verir. URL örneğinizde kimlik, "URL’yi herhangi bir yöntemle alan herhangi biri" olur.

Mümkünse kullanıcı adı / şifre ile gidin. URL'ler zaman içinde beklenmedik şekillerde sızar.

Gizli bir URL, gizli bir şifre kadar güvenlidir. Ancak, şifreler URL’lerden daha gizli tutulur, çünkü herkes ve programları şifrelerin gizli kalması gerektiğini bilir.

Örneğin, tarayıcınız ekranda bir şifre göstermez, yalnızca izninizle şifreleri saklar ve bu şifre depolamasını (örneğin bir ana şifre ile açılan şifreli depolama gibi) korumak için araçlar sunar. Buna karşılık, URL'leri her zaman ekranda gösterecek, muhtemelen yönlendirici başlığından sızıntı yapabilir ve başka bir korumaya gerek kalmadan tarama geçmişinizde otomatik olarak saklar.

Aynı şekilde, HTTP proxy sunucuları genellikle şifreleri günlüğe kaydetmezken, URL'ler genel olarak günlüğe kaydedilir.

Kimlik doğrulama için URL’lerin kullanılması, URL’lerin paylaşılmasının kimlik doğrulamasını paylaştığı anlamına gelir;

Ve elbette, gizli URL'ler, gizli şifrelerin tüm zayıflıklarını devralır. Özellikle, kimlik doğrulama için bir şifre kullanmak, bu şifreyi sunucuya ve iletişiminizi okuyabilen herkese gösterir.

Herhangi bir yerde not edilmemiş olan bir başka öğe 'tahminlerin' azaltılmasıdır. Çoğu şifre doğrulama sistemi için, daha fazla doğrulama girişimi kilitlenmeden veya sınırlandırılmadan önce bir kullanıcı için bir şifre tahmin etme konusunda sınırlı sayıda girişimde bulunursunuz.

URL şemanıza karşı 'tahminler' ile benzer bir şey yapmanıza rağmen, uygulanması biraz zor olacaktır. URL oluşturma işleminiz için tanınabilir bir düzen varsa, o zaman birisinin 'rasgele' URL alanınız üzerinde çalışacak şekilde ayarlanması durması zor olabilir.

Henüz bahsetmediğim bir başka yön daha var - URL kısaltıcılar.

Yakın tarihli bir yayında (Nisan 2016), URL kısaltıcı hizmetlerin, rastgele oluşturulmuş "yönetilemez" URL'ler tarafından sağlanan artan güvenliği tamamen geçersiz kıldığı iddia edildi. Kısa hizmetin URL alanı, rastgele oluşturulmuş URL'nizden çok daha küçüktür - bu, daha kısa bir hizmetle paylaşılan bu tür "güvenli" URL'lerin beklenenden daha kolay bir şekilde tahmin edilebileceği anlamına gelir.

Göstermek için - rastgele URL’nizin 128bit uzunluğunda olduğunu varsayalım (yani bir kılavuz). Ayrıca, rastgele sayı üreticinizin gerçekten güçlü olduğunu ve bu bitleri tek tip bir şekilde oluşturduğunuzu varsayalım. Bir 128bit numarayı tahmin etmek çok zordur ve oldukça zaman alabilir - URL’niz etkin bir şekilde 128bit anahtar korumalıdır.

Ardından, birisinin bu URL'yi google URL kısaltıcısında paylaştığını varsayalım. Bugün bu hizmet 10 karakter uzunluğunda bir kimlik yayar, harf ve rakamlardan oluşur. (26 + 10) ^ 10 ~ = 3,6 * 10 ^ 15 <2 ^ 52 - bu nedenle anahtar gücünü 128 bit'ten 52 bit'e düşürdük.

Jeneratörlerin diğer tüm alanlardan dolayı tüm alanı kullanmadıklarını ve kaba kuvvetleri yan kanallarla (büyük olasılıkla önceden tahsis edilmiş rastgele URL arabellekleri) birleştiren etkili bir saldırı kurabileceğinizi ekleyin.

Orijinal makale: http://arxiv.org/pdf/1604.02734v1.pdf Makaleyi
özetleyen bir blog yazısı (yazar tarafından): https://freedom-to-tinker.com/blog/vitaly/gone-in- altı karakter-kısa URL'ler düşünülmüş-zararlı-için-bulut hizmetleri /