Bozuk Erişim Kontrolü Nedir?
BAC, uygulamadaki bir işlevin veya varlığın, erişimi olmaması gereken bir kişi tarafından erişilebilir olduğu bir uygulama güvenlik açığı sınıfıdır.
Eğer siz de benim gibiyseniz, bu tanım sizi BAC’ın ne anlama geldiğini anlamaya daha fazla yaklaştırmayacak; işte BAC hatalarının bazı hayali örnekleri:
BAC Örneği 1: Bir e-ticaret web sitesi müşteri ayrıntılarının yetkisiz olarak görüntülenmesine izin veriyor
Diyelim ki en sevdiğiniz çevrimiçi kamp mağazanızda su geçirmez yürüyüş botları indirimi var ve siz de bir göz atmaya karar verdiniz. Yakın zamanda evinize taşındınız, bu nedenle bir satın alma işlemi yapmadan önce müşteri profilinizde teslimat adresinizin güncel olup olmadığını kontrol etmek istiyorsunuz. Oturum açın ve sizi aşağıdaki URL’ye yönlendiren hesap ayarlarınıza gidin:
Bu örnekte 482, kullanıcınızın sayısal tanımlayıcısıdır. Uygulamaların nesneleri bir veritabanında depolaması ve onlara benzersiz bir sayısal tanımlayıcıyla başvurması çok yaygındır. Veritabanının satırı şöyle görünebilir:
Kullanıcı kimliği | 482 |
e-posta | [email protected] |
şifre | $2y$10$Y71TNx.PAFw FBySCbJ4EO.pL0LF5 w84t/PEK00DGcaQ5bJSTkUjCK |
adres | 955 Broadway, Boston, MA, ABD |
/users/482 adresine gittiğinizde sayfada e-posta, adres ve kredi numarası gösterilir.
Peki 482’yi 481 gibi başka bir sayıyla değiştirirsek ne olur?
/users/481’e gidersiniz ve başka bir kullanıcının ayrıntıları görüntülenir. Elbette bu ayrıntılar Olumsuz sizin tarafınızdan görülebilir olmalıdır; bu, bir BAC hatasıyla karşılaştığınız anlamına gelir. Bu durum, 0-481 arasındaki tüm kullanıcı ayrıntılarına erişilerek daha da kötüye kullanılabilir; bazı veri ihlalleri tam da bu şekilde meydana gelir.
BAC Örnek 2: Bir banka, yetkisiz tarafların işlemlerine izin veriyor
Bu örnekte, biraz farklı bir BAC güvenlik açığı stilini ele alacağız. Saldırganın, hassas verilere yetkisiz erişime sahip olmak yerine, işlevsellik.
Bir arkadaşınıza para ödemek için banka hesabınızın web sitesine giriş yaptığınızı varsayalım. İşlemi gönderdikten sonra tarayıcınızın şuna benzer bir istek gönderdiğini fark ettiniz:
POST /api/v1/transfer HTTP/1.1 Ana bilgisayar: bank.example.com İçerik Türü: application/json Yetkilendirme: Your_access_token’inizin taşıyıcısı { |
Bilgisayar korsanınızın duyuları karıncalanmaya başlar, bu nedenle “from_account” değerini 470000000 olarak ve “to_account” değerini kendi banka hesap kimliğiniz olarak değiştirirsiniz. İsteği iletirsiniz ve anında hesabınızda 20$ görünür.
Bir BAC hatası buldunuz ve 20$ kazandınız!
Tam zamanında bir hatırlatma: Açık bir izniniz olmadığı sürece bu tür testleri çalıştırmayın çünkü en iyi niyetiniz olsa bile, bu durum başınızı yasal olarak belaya sokabilir.
BAC ve IDOR Arasındaki Fark Nedir?
Basitçe söylemek gerekirse, Güvenli Olmayan Doğrudan Nesne Referansı (IDOR) hataları, BAC hatalarının bir alt kümesidir. IDOR hataları, saldırganın erişmemesi gereken bir nesneye yalnızca kimliğine doğrudan başvurarak erişebildiği bir tür BAC hatasını ifade eder. BAC hatalarından bazı örnekler Olumsuz IDOR hataları şunları içerir:
- Zorunlu göz atma yoluyla ayrıcalık artışı (örneğin, yalnızca /admin’e giderek yönetici ayrıcalıkları kazanmak)
- Bir isteği değiştirerek (örneğin, kullanıcı adınızın kurbanın kullanıcı adı olduğunu söyleyerek) başka bir kullanıcının kaynaklarına erişme yeteneği, ancak aslında bir nesneye tanımlayıcısı aracılığıyla doğrudan erişmeme.
- HTTP fiili tahrifatı yoluyla bozuk erişim kontrolleri: örneğin bir saldırgan, HTTP isteğinde GET isteği yerine POST isteği göndererek güncelleyememesi gereken kayıtları güncelleyebilir.
Modern BAC Hatalarının Yaygınlığı
BAC hatalarının şimdiye kadar çoğunlukla ortadan kaldırılması gerektiğini düşünmek cazip geliyor. Değiller. Aslında, son zamanlarda OWASP’ın ilk on listesinde bir numara haline gelerek ilgi odağı haline geldiler. Neredeyse yalnızca bu tür hatalara odaklanan çok başarılı bazı ödül avcıları var.
Son 10 yılda enjeksiyon hatalarının (SQL enjeksiyonu gibi) sayısında bir düşüş gördük çünkü bu tür hatalar, geliştiricileri işleri güvenli bir şekilde kodlamaya teşvik eden çerçeveler kullanılarak yüksek düzeyde çözülebiliyor. varsayılan. BAC hatalarıyla bunu yapmak çok zordur çünkü uygulamalardaki izin yapıları genellikle karmaşık ve uygulamaya özeldir. Erişim kontrollerinin genellikle özel kurallar olarak uygulanması ve işlev veya nesne başına tanımlanması gerekir. Herhangi birinin gözden kaçırılması halinde, bunun bir güvenlik açığına yol açması muhtemeldir.
BAC Tanımlayıcı Türleri
Özellikle IDOR güvenlik açıkları için, geliştiricilerin tanımlayıcı olarak kullandığı yaygın türdeki şeylerin farkında olmak önemlidir; böylece proxy günlükleri arasında gezinirken bunları hızlı bir şekilde tespit edebilirsiniz.
Kullanıcı Tarafından Seçilen Tanımlayıcılar
Belki de en basiti, bunlar kullanıcının seçtiği kullanıcı adı, e-posta adresi veya URL bilgisi gibi tanımlayıcı türleridir.
Doğal Anahtarlar
Doğal anahtarlar, verilerde doğal olarak oluşan tanımlayıcı türleridir. Örneğin, bir ABD vatandaşından bahsederken tanımlayıcı olarak onun sosyal güvenlik numarasını kullanabilirsiniz.
Kompozit Anahtarlar
Bu anahtarlar nesnedeki birden fazla alandan oluşur; örneğin standart bir e-ticaret uygulamasında, bir siparişin tanımlayıcısını oluşturmak için bir kullanıcı tanımlayıcısını bir ürün tanımlayıcıyla birleştirebilirsiniz.
Sayısal tanımlayıcılar
Yukarıda verilen örnekler sayısal tanımlayıcılardır. Bu, en yaygın tanımlayıcı türüdür; oluşturulan her yeni nesneye, her seferinde bir artan bir sayı atar.
Örneğin, fatura oluşturan bir web uygulamasında ilk faturaya şu adresten erişilebilir:
Aynı şekilde 432. faturaya da şu adresten ulaşılabilir:
Bu tanımlayıcılardan yararlanılması en kolay olanlardır çünkü diğer faturalara erişmek için sayacı basitçe artırabilir veya azaltabilirsiniz.
UUID’ler
UUID (Evrensel Olarak Benzersiz Tanımlayıcı), sıklıkla tanımlayıcı olarak da kullanılan 128 bitlik bir sayıdır. Aynı UUID’yi birden fazla oluşturma olasılığı son derece düşüktür. Bu nedenle yazılım geliştirmede veritabanı girişleri, dağıtılmış sistemlerdeki nesneler veya veritabanlarındaki benzersiz anahtarlar gibi kaynakları tanımlamak için yaygın olarak kullanılırlar.
UUID’ler tipik olarak, aşağıdaki gibi kısa çizgilerle ayrılmış beş gruba bölünmüş onaltılık basamaklardan oluşan bir dize olarak temsil edilir:
550e8400-e29b-41d4-a716-446655440000 |
Özetle, tanımlayıcıları bir şekilde sızdırmadığınız sürece (ki bu bazen uygulamanın normal kullanımıyla mümkündür), UUID’ler tanımlayıcı olarak kullanılıyorsa bozuk erişim kontrollerinden yararlanmak son derece zordur (imkansıza yakın).
Hash’ler
Hash’ler, özellikle dosyalarla uğraşırken sıklıkla tanımlayıcı olarak kullanılır. Dosyaya hash uygulanır ve daha sonra bu hash, o dosyanın tanımlayıcısı olur.
BAC Hatalarını Bulma Teknikleri
BAC hatalarını bulmanın birçok yolu vardır, ancak burada birkaç yaygın teknik bulunmaktadır.
İzin Eşlemesi
Hedefinizi seçtikten sonra iki liste oluşturun. Solda kullanıcı rollerinin bir listesini oluşturun. Sağ tarafta uygulamada gerçekleştirilebilecek eylemlerin bir listesini oluşturun. Örneğin basit bir blog uygulaması için şöyle görünebilir:
Kullanıcı Rolleri |
Eylemler |
Kimliği doğrulanmamış |
Yeni bir blog oluştur |
Editör |
Blogları okuyun |
Yönetici |
Blog gönderisini güncelleme |
Blog gönderisini silme |
Şimdi, her eylemi her kullanıcıya atamak için bir e-tablo ve iki sütun daha kullanın. Biri “İzni olmalı” diyen, diğeri “İzni var” diyen. Her satırı gözden geçirin ve rolün bu izne sahip olup olmamasına bağlı olarak “iznine sahip olmalı” seçeneğini “evet” veya “hayır” olarak güncelleyin:
Aksiyon |
Kullanıcı |
Erişimi olmalı |
Erişimi var mı |
Kimliği doğrulanmamış |
Yeni bir blog oluştur |
HAYIR |
|
Kimliği doğrulanmamış |
Blogları okuyun |
Evet |
|
Kimliği doğrulanmamış |
Blog gönderisini güncelleme |
HAYIR |
|
Kimliği doğrulanmamış |
Blog gönderisini silme |
HAYIR |
|
Editör |
Yeni bir blog oluştur |
HAYIR |
|
Editör |
Blogları okuyun |
Evet |
|
Editör |
Blog gönderisini güncelleme |
Evet |
|
Editör |
Blog gönderisini silme |
HAYIR |
|
Yönetici |
Yeni bir blog oluştur |
Evet |
|
Yönetici |
Blogları okuyun |
Evet |
|
Yönetici |
Blog gönderisini güncelleme |
Evet |
|
Yönetici |
Blog gönderisini silme |
Evet |
Şimdi eğlence başlıyor! “Erişime sahip olmalı” sütunundaki her “Hayır” için, eylemi gerçekleştirip gerçekleştiremeyeceğinizi görmek üzere uygulamayı test edin. Sonunda, “Erişime sahip olmalı” sütununda “Hayır” ve “Erişimi var” sütununda “Evet” yazan satırlar varsa, bir BAC hatası buldunuz demektir. Örneğin:
Aksiyon |
Kullanıcı |
Erişimi olmalı |
Erişimi var mı |
Kimliği doğrulanmamış |
Yeni bir blog oluştur |
HAYIR |
HAYIR |
Kimliği doğrulanmamış |
Blogları okuyun |
Evet |
Evet |
Kimliği doğrulanmamış |
Blog gönderisini güncelleme |
HAYIR |
HAYIR |
Kimliği doğrulanmamış |
Blog gönderisini silme |
HAYIR |
HAYIR |
Editör |
Yeni bir blog oluştur |
HAYIR |
HAYIR |
Editör |
Blogları okuyun |
Evet |
Evet |
Editör |
Blog gönderisini güncelleme |
Evet |
Evet |
Editör |
Blog gönderisini silme |
HAYIR |
Evet |
Yönetici |
Yeni bir blog oluştur |
Evet |
Evet |
Yönetici |
Blogları okuyun |
Evet |
Evet |
Yönetici |
Blog gönderisini güncelleme |
Evet |
Evet |
Yönetici |
Blog gönderisini silme |
Evet |
Evet |
Bu tabloda, bir “Editör”ün bir blog yazısını silememesi gerektiğini ancak silebileceğini görebilirsiniz. Raporlama zamanı!
Daha büyük, daha karmaşık bir uygulama için, izin eşleme son derece tekrarlı ve sıkıcı olabilir, ancak kapsamlı ve eksiksiz olma sabrına sahip olmak, karşılığını verir.
Yetkilendir
Autorize, normal tarama isteklerinizi başka bir kullanıcı olarak tekrar oynatarak BAC hatalarının ortaya çıkarılmasına yardımcı olan bir Burp Suite BApp’tir. Daha sonra, talebin başarılı olup olmadığını belirlemek için meşru talebin yanıtını gayri meşru talebin yanıtıyla karşılaştırır. Daha sonra yanıtları ne kadar benzer olduklarına göre renklendirerek ilginç istekleri kolayca filtrelemenize olanak tanır. Otomatikleştirme hakkında daha fazla bilgi edinin.
Çözüm
Resmidir: Kırık Erişim Kontrolü, OWASP’a göre uygulamalarda bulunan bir numaralı en yaygın güvenlik sorunudur. Program arama deneyimlerime dayanarak durumun gerçekten de böyle olduğunu doğrulayabilirim. Bunlar aynı zamanda anlaşılması oldukça basit bir hatadır, yani öğrenilmesi gereken harika bir ilk hata sınıfıdırlar. Umarım bu blog yazısı size BAC hatalarını öğretmiştir ve dışarı çıkıp kendinizden birkaç tane bulmanız için size ilham vermiştir.
Mutlu hacklemeler!