Veritabanı kimliklerini açığa çıkarmak

134

Veritabanı kimliklerini ifşa etmenin (örneğin URL'lerde) bir güvenlik riski olduğunu duydum, ancak nedenini anlamakta güçlük çekiyorum.

Neden bir risk veya neden olmadığına dair herhangi bir görüş veya bağlantı var mı?

DÜZENLEME: Elbette erişim kapsamlıdır, örneğin kaynağı göremezseniz foo?id=123bir hata sayfası alırsınız. Aksi takdirde, URL'nin kendisi gizli olmalıdır.

DÜZENLEME: URL gizli ise, muhtemelen sınırlı bir ömrü olan, örneğin 1 saat için geçerli ve yalnızca bir kez kullanılabilen oluşturulmuş bir simge içerecektir.

DÜZENLEME (aylar sonra): Bunun için şu anda tercih ettiğim uygulamam UUIDS'i kimlikler için kullanmak ve bunları açığa çıkarmaktır. Kimlik olarak ardışık sayılar (genellikle bazı DB'lerde performans için) kullanıyorsam, her giriş için alternatif bir anahtar olarak bir UUID belirteci oluşturmayı severim ve bunu açığa çıkarırım.

database security

— OriP
kaynak

109

Uygun koşullar göz önüne alındığında, tanımlayıcıların açığa çıkması bir güvenlik riski oluşturmaz. Ve pratikte, tanımlayıcıları açığa çıkarmadan bir web uygulaması tasarlamak son derece külfetli olacaktır.

İşte uymanız gereken bazı iyi kurallar:

Bir işleme erişimi kontrol etmek için rol tabanlı güvenliği kullanın. Bunun nasıl yapılacağı, seçtiğiniz platforma ve çerçeveye bağlıdır, ancak birçoğu, bir eylem biraz yetki gerektirdiğinde tarayıcıları otomatik olarak bir kimlik doğrulama adımına yönlendirecek bildirim temelli bir güvenlik modelini destekler.
Bir nesneye erişimi kontrol etmek için programlı güvenlik kullanın. Bunu çerçeve düzeyinde yapmak daha zordur. Daha sık olarak, kodunuza yazmanız gereken bir şeydir ve bu nedenle hataya daha yatkındır. Bu kontrol, yalnızca kullanıcının işlem için yetkiye sahip olmasını sağlamakla kalmayıp aynı zamanda değiştirilen belirli nesne üzerinde gerekli haklara sahip olmasını sağlayarak rol tabanlı denetimin ötesine geçer. Rol tabanlı bir sistemde, yalnızca yöneticilerin zam verebileceğini kontrol etmek kolaydır, ancak bunun ötesinde, çalışanın belirli bir yöneticinin departmanına ait olduğundan emin olmanız gerekir.
Çoğu veritabanı kaydı için 1 ve 2 koşulları yeterlidir. Ancak tahmin edilemeyen kimliklerin eklenmesi, biraz ekstra sigorta veya bu fikri benimserseniz "derinlemesine güvenlik" olarak düşünülebilir. Bununla birlikte, öngörülemeyen tanımlayıcıların bir zorunluluk olduğu bir yer, kimliğin kendisinin bir isteği doğruladığı oturum kimlikleri veya diğer kimlik doğrulama belirteçleridir. Bunlar kriptografik bir RNG tarafından oluşturulmalıdır.

— erickson
kaynak

27

IMO, öngörülemeyen kimliklerin eklenmesi "belirsizlik yoluyla güvenlik" yaklaşımıdır ve yanlış bir güvenlik duygusuna yol açabilir. (1) ve (2) 'ye odaklanmak ve erişim kontrolünüzün sağlam olduğundan emin olmak daha iyidir.

— stucampbell

4

Kriptografik bir RNG kullanmak kesinlikle "belirsizlik yoluyla güvenlik" değildir. Saldırgan, onları nasıl oluşturduğunuzu bilse bile nesne tanımlayıcılarını tahmin etmeye daha yakın değildir. Belirsizlik yoluyla güvenlik, kullandığınız algoritma keşfedilirse kötüye kullanılabileceği anlamına gelir. Anahtarlar veya bir RNG'nin dahili durumu gibi sırların saklanması anlamına gelmez.

— erickson

1

@stucampbell Belki, ama bu tahmin edilemeyen kimlikler kullanmamanız gerektiği anlamına gelmez. Hatalar meydana gelir, bu nedenle tahmin edilemeyen kimlikler ekstra bir güvenlik mekanizmasıdır. Ayrıca, erişim kontrolü bunları kullanmanın tek nedeni değildir: öngörülebilir kimlikler, belirli bir zaman dilimi içindeki yeni müşterilerin sayısı gibi hassas bilgileri ortaya çıkarabilir. Gerçekten böyle bir bilgiyi ifşa etmek istemezsiniz.

— user247702

1

@Stijn, kaç müşterim olduğunu ifşa etmeyi gerçekten "gerçekten istemiyorum" diyemezsin. Demek istediğim, McDonald's'ın 10 milyar hamburger servis ettiklerini belirten büyük bir tabelası var. Bu bir güvenlik riski değil, bir tercihtir. Ayrıca, yine de endişeleneceğimiz çoğu uygulamada herhangi bir URL görmeden önce oturum açmanız gerekir. Bu nedenle, verileri kimin kazdığını bilirdik.

— Wayne Bloss

1

Bu konuşmada bahsetmediğim bir şey, sorun giderme ve kullanım kolaylığı açısından, kullanıcıları belirli bir kaynağa yönlendirmeye yardımcı olmak veya kullanabilmelerini sağlamak için bir url'de kimliklerin gösterilmesinin çok kullanışlı olabileceğidir. tam olarak hangi kaynağı görüntülediklerini söylemek için. Yalnızca bir fikir sunmak için otomatik artırmayı daha yüksek bir değerde başlatarak iş zekası endişelerinden çoğunlukla kaçınabilirsiniz.

— Chockomonkey

47

Bir veri güvenliği riski olmasa da , hem veri boyutunu hem de hızını ortaya çıkardığı için bu kesinlikle bir iş zekası güvenlik riskidir. İşletmelerin bundan zarar gördüğünü gördüm ve bu anti-model hakkında derinlemesine yazdım. Sadece bir deney oluşturmuyorsanız ve bir iş yapmıyorsanız, özel kimliklerinizi herkesin gözünden uzak tutmanızı şiddetle tavsiye ederim. https://medium.com/lightrail/prevent-business-intelligence-leaks-by-using-uuids-instead-of-database-ids-on-urls-and-in-apis-17f15669fd2e

— Peter
kaynak

4

Son olarak, güvenlik riskinden başka yönler getiren mantıklı bir cevap.

— 2019, 13

2

Kabul edilen cevap bu olmalıdır. Saldırganın güvenliğinizi aşabileceğini varsayarsanız (ki bunu her zaman yapmalısınız), bu tür bilgileri sadece başkalarına vermek istemezsiniz.

— Kriil

@Kriil Güvenliğinizi atlamalarına bile gerek yok. Sadece bir hesap oluşturmaları gerekiyor!

— Peter

32

Kimliklerin ne anlama geldiğine bağlı.

Rekabetçi nedenlerden dolayı kaç üyesi olduğunu kamuya açıklamak istemeyen, ancak sıralı kimlikleri kullanarak bunu URL'de yine de ortaya koyan bir site düşünün: http://some.domain.name/user?id=3933

Öte yandan, kullanıcının oturum açma adını kullandıysa: http://some.domain.name/user?id=some kullanıcının bilmediği hiçbir şeyi açıklamamışlardır.

— biraz
kaynak

2

sıralı kimlikler kullanıyorsanız haklısınız, ancak değilse bu hiçbir şeyi açığa

— çıkarmaz

@orip: Dediğim gibi, bu, birinin birkaç kimliği inceleyerek neler keşfedebileceğine bağlı. Bir desen var mı? Bu bilgileri sahip olmaları amaçlanmayan bilgileri elde etmek için kullanabilirler mi?

— bazı

@John: Düzenleme için teşekkürler. İngiliz :) benim anadilim değil

— Bazı

6

Tam olarak şunu yaptım: bir rakibin kullanıcı tabanının boyutunu belirlemek için sıralı kimlik numaraları kullandım.

— Micah

3

Onlar heryerde. Birçok mağaza, sipariş kimliği için sıralı bir numara kullanır. Bir tarihte bir sipariş verin ve başka bir tarihte bir sipariş verin ve bu dönemde kaç sipariş aldıklarını bilirsiniz. Siparişlerin değerinin ne kadar olduğunu bilmeseniz bile, yine de işin ne kadar iyi gittiğine dair bir gösterge alırsınız.

— bazı

25

Genel düşünce şu çizgide ilerlemektedir: "Uygulamanızın iç işleyişi hakkında herkese çok az bilgi verin."

Veritabanı kimliğinin açığa çıkarılması, bazı bilgilerin açıklanması olarak sayılır.

Bunun nedenleri, bilgisayar korsanlarının uygulamalarınızın iç işleyişiyle ilgili herhangi bir bilgiyi size saldırmak için kullanabilmeleri veya bir kullanıcının, görmemesi gereken bir veritabanına girmek için URL'yi değiştirebilmesidir.

— Arjan Einbu
kaynak

1

Görmemeleri gereken kaynaklara erişim - yalnızca izinleri kontrol etmezsem (ki yapıyorum, aksi takdirde farklı bir güvenlik sorunum var). "İç işleyiş" hakkında bilgi ifşa etmek - bu tam olarak benim sorum. O niçin bir problem olsun ki?

— orip

8

@orip: Her şey mümkün olduğunca güvenli olmakla ilgili. Hata yapmayan türden bir programcıysanız, bu bir sorun değildir. Aksi takdirde, daha az ayrıntı açığa çıkarmak, hata yaparsanız (ne zaman) hata yaparsanız kodunuzdan yararlanmayı zorlaştırır. Tek başına haklısın, bu güvenlik eklemiyor.

— Adam Bellaire

@Adam: Yüzeysel güvenlik, güvenliksizlikten daha kötü olabilir. Hiçbir güvenlik olmadan açıksınız, yüzeysel güvenlik ile bunun ihmal edilemeyecek bir şey eklediğini düşünebilirsiniz.

— orip

16

Veritabanı kimlikleri için GUID'leri kullanıyoruz. Bunları sızdırmak çok daha az tehlikelidir.

— Joshua
kaynak

Ben de bunu öneririm. Veritabanınızdaki GUID'leri tahmin etme olasılığı çok daha düşüktür.

— Jon Erickson

6

Bu bir performans cezasıyla gelir. Buraya

— Jeshurun

2

Kılavuzları kullanmakla ilgili ilginç olan şey, müşterilerin veritabanı kimlikleri oluşturmasına izin verebilmenizdir. İlginç olan 2, otomatik artan kimliklerin yaptığı gibi parçalanmış veritabanları ile hiçbir problemlerinin olmamasıdır.

— Brian White

Bu GUID'leri, kullanıcıları, yorumları, gönderileri tanımlamak için kimlik öznitelikleri olarak html kodunda da kullanıyor musunuz? Bir kullanıcının hangi bağlantıya tıkladığını veya hangi gönderiye yorum yapmak istediğini belirtmek için?

— trzczy

7

Veritabanınızda tamsayı kimlikleri kullanıyorsanız, qs değişkenlerini değiştirerek, kullanıcıların yapmaması gereken verileri görmesini kolaylaştırabilirsiniz.

Örneğin, bir kullanıcı bu qs'deki id parametresini kolayca değiştirebilir ve http: // someurl? İd = 1 olmaması gereken verileri görebilir / değiştirebilir

— Jason
kaynak

7

İzinleri kontrol etmezsem farklı bir güvenlik sorunum var.

— orip

ama cevap doğru: "mayıs"

— Seun Osewa

1

Soru, izinleri kontrol edip etmeyeceğiniz değil. Tanımadığınız yeni işe alınan kişi izinleri kontrol edecekse.

— Brian White

@BrianWhite - işte bu yüzden bir kod inceleme süreci istiyorsun, böylece onları üretime geçmeden önce eğitebilirsin.

— candu

2

Yaptığımız şey, URL veya form değişkenlerinde kullanıldığında tamsayı kimliklerini şifrelemektir.

— Brian White

6

İstemcinize veritabanı kimliklerini gönderdiğinizde , her iki durumda da güvenliği kontrol etmek zorunda kalırsınız . Kimlik bilgilerini web oturumunuzda tutarsanız, bunu yapmak isteyip istemediğinizi / yapmanız gerektiğini seçebilirsiniz, bu da potansiyel olarak daha az işlem anlamına gelir.

Sürekli olarak bir şeyleri erişim kontrolünüze devretmeye çalışıyorsunuz;) Başvurunuzda durum böyle olabilir , ancak kariyerim boyunca bu kadar tutarlı bir arka uç sistemi görmedim. Çoğunun web dışı kullanım için tasarlanmış güvenlik modelleri vardır ve bazılarının sonradan ek rolleri vardır ve bunlardan bazıları çekirdek güvenlik modelinin dışına sabitlenmiştir (çünkü rol farklı bir operasyonel bağlamda eklenmiştir, örneğin web'den önce).

Bu yüzden sentetik oturum yerel kimliklerini kullanıyoruz çünkü kurtulabildiğimiz kadar gizliyor.

Ayrıca, numaralandırılmış değerler ve benzerleri için geçerli olabilecek tamsayı olmayan anahtar alanları sorunu da vardır. Bu verileri sterilize etmeyi deneyebilirsiniz, ancak sonunda küçük bobby bırakma masaları gibi olacaksınız .

— krosenvold
kaynak

4

İlginç olsa da, her istek için tüm girdileri (URL parametreleri dahil) kontrol etmenin web için çok uygun olduğunu düşünüyorum.

— orip

Veritabanı kimliklerini açığa çıkarmak - güvenlik riski?