Vahşi Ortamda Bozuk Erişim Kontrolü Güvenlik Açıkları Nasıl Bulunur?


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ı

{
“from_account”: “472938294”,
“to_account”: “483928403”,
“tutar”: 20.00,
“para birimi”: “USD”,
“transfer_description”: “Pizza için teşekkürler!”
}

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.

Bozuk erişim kontrolünü bulma aracını otomatikleştirin

Çö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!



Source link