Bu yazıda erişim kontrolü kavramını ve “bozuk erişim kontrolü” zafiyetini basitleştirilmiş örneklerle inceleyeceğiz.
Erişim Kontrolü Nedir?
Erişim kontrolü” kavramı, kişilerin yetkileri dahilinde, erişmeye hakları olan kaynakları erişebilmesi ve yetkilerine uymayan, erişmeye hakları olmayan kaynaklara eriştirilmemesidir.

Giriş-çıkış için kapının kullanıldığı, sadece anahtarı olanların girebildiği bir yapı. Ama biri çekiç kullanarak kendine başka bir giriş alternatifi yaratmış. Kapı, erişimleri kontrol etmek için yeterli değilmiş ve birileri bu duruma şaşkın.
Bunu, bir ticari işletmenin müşteri alanı ve çalışan olanı olarak düşünebiliriz. Örnek olarak, bir restoranda çalışanlar mutfağa, kasaya ve müşteri alanlarına erişebilirken, müşteriler sadece müşteriler için ayrılan alanlara erişebilir. Eğer bir müşteri, çalışanlara ayrılan bir alana girerse ve fark edilirse ona ne hakla oraya girdiği sorulur, çünkü normal şartlar altında oraya girmeye hakkı yoktur. Çalışan alanına girmeyi başarmışsa ve orada bir aksiyon gerçekleştirebilmişse, bu durumda erişim kontrolünü kısıtlama sürecinde bir problem olduğunu söyleyebiliriz. Bu durum “bozuk erişim kontrolü” olarak tanımlanır.
Dijital ortamlarda da bunun aynısı geçerlidir. Farkı, dinamiklerin bir restoran kadar belirgin olmamasıdır. Bir alışveriş sitesinde yetkisi sipariş vermek olan kullanıcı, ürün düzenleme paneline erişememelidir. Buna hakkı yoktur. Bu panele satıcı yetkisine sahip kullanıcılar erişebilmelidir.
Erişimi Kontrol Etme Süreci Nasıl İşler?
Erişimi kontrol etme süreci, en basit hali ile, önce kişinin yetkisini belirlemek ile başlar. Sonrasında kişinin gerçekleştirmek istediği aksiyon onun “yetkisi dahilinde mi?” olduğunu sorgulamak gelir. Cevap evet ise kişinin erişim hakkı vardır. “Hayır” ise kişinin o alana erişememesi gerekir.
Çalışanların ve müşterilerin birbirinden ayrılan görsel tanımlamalara sahip olmadığı bir yerel esnaf dükkânı düşünün. Herkesin yan yana olduğu bir ortamda bazen kimin müşteri kimin çalışan olduğu anlaşılmaz.
Bunu bazen bir işletmeye girdiğimizde, tişört rengi çalışanların tişört rengine benzeyen bir müşteriye soru sorup sonrasında “ ben burada çalışmıyorum” cevabını aldığımız durumlara da benzetebiliriz.
BAC Restoranına Hoş Geldiniz!
Restoran örneğimizi basitleştirilmiş bir zemin planı ile incelersek, mavi kısımlar çalışanların erişebilecekleri alanları, yeşiller müşterilerin erişebilecekleri alanları temsil ediyor.

Bir müşterinin, depo ve kasa gibi alanlara erişmemesi gerekir. Çalışanların ise, işletmenin hizmetini sürdürebilmesi alana yetkileri dahilindeki alanlara erişmesi gerekir. Müşterilerin, sipariş vermek ve yemeklerini yemek için yemek masalarına erişmesi gerekir. Ödemelerini gerçekleştirmek içinde kasa kısmı ile etkileşime girebilmeleri gerekir. Ama kasa üzerinde yetkisiz işlem gerçekleştirememeleri adına kasa arkasına erişememeleri gerekir. Bu zemin planına bakarak bir müşterinin bu restoranda depoya erişmeye hakkı yoktur. Depoya erişmesi ve orada eylemler gerçekleştirebilmesi durumunda, bu restoranda uygulanan erişim kontrol sürecinde bozukluk vardır.
Güzel. Peki bu dAAA ne?
Hayır, klavyemdeki “a” tuşu sıkışmadı. “AAA” siber güvenlikte bir mantık çerçevesi:
- Authentication (doğrulama): kullanıcının kimliğini doğrulaması
- Authorization (yetkilendirme): Erişimi kısıtlı bölgeye girebilmesi için yetkilendirilmesi
- Accounting (sorumlu tutulabilirlik): Gerçekleştirilen aksiyonların sonuçlarından ilgili kullanıcının sorumlu tutulması
Açıl Susam Açıl – Akıllı Bir Mağara
Eğer Binbir Gece Masalları ‘nda geçen Ali Baba ve Kırk Haramiler hikayesindeki mağara güvenlik farkındalığı yüksek bir bilince sahip olsaydı ve bize AAA mantık çerçevesini anlatmak isteseydi, ortaya nasıl bir hikâye çıkardı sizce?

AÇIL SUSAM AÇIL
Ali Baba, mağaranın girişine gelmiş.
Ali Baba: “Açıl susam açıl.” demiş. Ama bu mağara siber güvenliğine önem veren bir mağaraymış.
Mağara: “Sen kimsin.”
Ali Baba: “Ben Ali Baba ‘nın ta kendisiyim.“
Mağara: “Senin Ali Baba olduğuna inanmam için, bana sadece onun bileceği bir şey söylemen lazım. Bana Ali Baba en çok hangi kurabiyeyi sever onu söyle.” [AUTHENTICATION]
Ali Baba: “Ben en çok çikolatalı kurabiye severim.”
Mağara: “Doğru bildin. Mağaradan içeri girdiğinde, girişteki meşaleyi al ve içerdiği olduğun süre boyunca yanında taşı. Bu, içeri girmen için benim sana izin verdiğimin kanıtı olacak.” [AUTHORIZATION]
Ali Baba: Peki hazineden bir şey alırsam bunu fark edebilecek misin?
Mağara: Sen içeri girmeden önce tüm hazine sayıldı ve sen çıktıktan sonra tekrar sayılacak. Girmene izin verdiğim yol ise tek bir sandık odasına gidiyor ve diğer odaların kapısı kilitli. [ACCOUNTING]
Ali Baba: İlk defa siber güvenlik farkındalığına dair tüm beleş sertifikaları toplamış bir mağara görüyorum.
|
İletişim sürecini incelediğimizde, basit seviyede bir önlem uygulandığını görebiliriz. Peki ya bir başkası, Ali Baba ‘nın sevdiği kurabiyeyi öğrenip, kim olduğu hakkında yalan söyleyebilir miydi?
Evet. Söyleyebilirdi. Daha da ileri gidip hazineden altında çalsaydı, kayıtlara göre suçlu Ali Baba olur muydu?
Evet. Olurdu. Bu durumda Ali Baba ‘nın hem kimliği taklit edilmiş, hem de adına suç işlenmiş olacaktı. Bütün bunlar olurken belki de Ali Baba sadece evinde oturup televizyon izliyor olacaktı.
Peki eğer bir saldırgan hazine odalarının nerede olduğunu biliyor olsaydı, kapıdan girmek yerine kazarak tüm odalara ulaşabilir miydi?
Evet ulaşabilirdi. O zaman burada bir “bozuk erişim kontrolü” söz konusu olurdu.
Burada biraz durup verilen örneği inceleyerek mağara kapısını atlatabilecek tüm örnekleri düşünün. Birçok farklı taktik olabileceğini fark etmişsinizdir.
Buraya kadar okuduğunuz çeşitli örneklerde, yetki tanımlama süreçlerini kandırabileceğiniz birkaç yöntem çoktan aklınıza gelmiştir. Bundan sonrasında tek fark bu taktiklerin dijital hallerini incelemek olacak.
Uygulama Güvenliğinde BAC Zafiyetleri
Uygulama yapılarında BAC zafiyetine sebep olabilecek çeşitli teknikler vardır. Eğer güvenli kodlama prensiplerine uyulmamışsa, bir kullanıcı hesabı, sadece URL ‘yi girerek admin panellerine ulaşmayı bile deneyebilir. Bu tarz zafiyetlerin varlığı aynı zamanda “en az yetki” prensibininde ihlali sayılır.
Burp aracı ile istek manipülasyonları gerçekleştirmek ile BAC zafiyetini keşfetmek en popüler tekniklerden biri sayılabilir. Diğer zafiyetlerle kombine ederekte BAC zafiyetini keşfetmek popüler bir tekniktir. URL üzerinde manipülasyonlar gerçekleştirmekte BAC zafiyetinin keşfedilmesini sağlayabilir. Bazı angajman kurallarında (Rules of Engagement – RoE) göre zafiyetleri zincirlemek, kapsam dışı sayılabilir, test ederken buna dikkat edilmelidir.
BAC Örnekleri:
HEDEFE ULAŞMAK

Burada, nereye gitmek istediğini bilen bir köpeğin, normal yürüyüş sırasında kullandığı refleksleri, tırmanışa göre uyarlayarak merdiveni tırmanma çabasını görüyoruz.
Bir uygulamada, ilgili yetkili kişilerin erişebildiği bir sorgu paneli düşünelim ve bu panelin URL ‘sini bildiğimizi varsayalım.
Elimizdeki kullanıcının bu sorgu paneline erişebilecek kullanıcı kategorisinde olmadığını varsayalım. Düşük yetkili kullanıcıdan giriş yapıp direkt olarak URL ‘ye gitmeyi deneyebiliriz. Bununla BAC keşfetme imkanımız düşüktür, ama sıfır değildir. Eğer istekleri incelerken yetki parametresinin kullanıcı tarafından (client-side) sunucuya gönderildiği bir yer görüyorsak, oradaki yetki tanımlayıcısı üzerinde değişiklikler yaparak hedeflediğimiz URL üzerinde erişim elde edilmesi söz konusu olabilir.
Görüntü_Gelsin=Ama_Hangisi???

Kullanıcılara bir yol sunulursa ama yan yollara giriş kapatılmazsa, onları istediklerini yapmamaları için hiçbir şey durduramaz.
Yaptığımız ödemelerin faturalarını görebildiğimiz bir web uygulaması düşünelim. En son yaptığım ödemenin faturasını tıkladığımda link bu şekilde.
samplesite.com/payments?img=2311
Görüntü numarasını ( img=5483 ) değiştirerek başka bir kullanıcıya ait bir ödemeyi görüntülemek denenebilir. Eğer başarı ile başka bir ödeme faturası görüntülenebilirse burada IDOR zafiyeti vardır.
Bu bir fotoğraf tanımlayıcı numarası değil de bir alışveriş sitesinde bir sepet tanımlayıcı numarası da olabilirdi.
DAHA FAZLA YETKİ

Canlılar, bir diğerinin yetki alanına girmemesi konusunda keskin çizgiler ile kısıtlanmazsa, herhangi bir sebepten dolayı, sınırları zorlamayı kesinlikle denerler.
Bir web uygulamasında uygulamanın kullanım amacı ile alakalı gruplar oluşturabildiğimizi ve bu gruplara diğer kullanıcıların katılabildiğini ve verildikleri yetkilere göre aksiyonlar gerçekleştirebildiğini düşünelim. Bu tarz formata sahip olan uygulamalar Discord veya Slack gibi uygulamalar ve benzerleri olabilir.
BURP aracını açıp, uygulamayı bir süre gezdikten sonra isteklerin birinin içindeki parametrelerde;
” UserType=participicator “
ifadesini içeren bir post isteği gördüğümüzü düşünelim. Buradaki “participicator” (katılımcı) belirtecini, odanın sahibi olan kullanıcıda gördüğümüz belirteç ile değiştirmeyi deneyebiliriz. Odayı oluşturan kullanıcıda ;
” UserType=room_owner “
ifadesini görmüş isek, katılımcı kullanıcının ilgimizi çeken isteğine o ifadeyi yazıp göndermeyi deneyebiliriz. İsteği gönderdikten sonra oda sahibi yetkilerine, aslında o yetkiye sahip olmaması gereken kullanıcı üzerinde de sahip olabilmiş isek burada da istek manipülasyonu yaparak, erişim kontrolü sürecini bypass etmemiz üzerinden doğan bir BAC zafiyeti söz konusudur.
FAZLA KİR FİLTRELERİ TIKAYABİLİR

Çok kirlenmiş bir hava filtresi, aracın kararmış egzoz dumanı çıkarmasına sebep olabilir. Bu durumda, havayı temizlemesi gereken filtre, fazlaca kirlendiği için görevini yerine getiremez, hatta durumu daha da kötüleştirir.
İlk örneğimizdeki gibi, geçmiş tüm faturaları gösteren bir web uygulaması özelliği düşünelim. Burada HTTP parameter pollution (parametre kirletme) tekniği ile erişim kontrollerini bypass ederek başka bir kullanıcının geçmiş faturalarını görüntülemeyi deneyebiliriz. Bu teknik var olan URL üzerine daha fazla parametre ekleyerek hedeflenen amaca ulaşmaya çalışmayı içerir. Bu örnek için benim kullanıcı ID ‘min “567” olduğunu ve hedefimin ID ‘sinin “123” olduğunu varsayalım. Kendi geçmiş faturalarımı görüntülediğimde bulunduğum URL ‘nin şu şekilde olduğunu varsayalım:
samplesite.com/invoices?user_id=567
Hedeflediğim kullanıcı ID ‘si ile kendi ID ‘mi değiştirdiğimde, uygulama buna izin vermediğini düşünürsek, bu noktada yapmam gereken şey farklı bir taktik denemektir. HTTP parameter pollution taktiğinin basit bir örneğini deneyerek aşağıdaki şekilde bir manipülasyon gerçekleştirelim:
samplesite.com/invoices?user_id=567&user_id=123
URL ‘yi bu hale getirdiğimde diğer kullanıcının geçmiş faturalarını görmeyi başarırsam, bu uygulama üzerinde parametre kirletme zafiyetiyle oluşan bir erişim kontrolü ihlali olduğu söylenebilir.
Burada önce yetki seviyem içinde olan kendi ID ‘ime erişmeye çalışmam, uygulama tarafından yetkilendirilmem ve sonrasında uygulamanın yetersiz erişim kontrolü prosedürlerinden faydalanarak son erişim noktamı hedef kullanıcımın ID ‘si olarak göstererek zafiyeti gerçekleştirmiş olurum.
|
|
KURABİYENİN TARİFİNİ ALABİLİR MİYİM?

Dışarda yediğim ve beğendiğim bir kurabiyeyi, evde her istediğimde tekrar yapmak için tarifini öğrenmeyi çok isterim. Hem dışarda içine ne katıyorlar belli değil.
Uygulamalar, giriş yaptıktan sonra kullanıcıyı tanımlamak için çerezler (cookies) verir. Kullanıcının, uygulama üzerindeki yetkilendirildiği aksiyonları gerçekleştirmesi ve oturumunu aktif tutması görevini görürler. Kullanıcı adı ve şifre, tarayıcı, cihaz IP’ si gibi tanımlayıcılar kullanılarak kişiye özel olmaları sağlanabilir. Çerezlerin uygulanması konusunda farklı teknikler vardır ve günümüzdeki ihtiyaçlara göre uygulamalar üzerinde birbirlerinden farklı şekilde bulunduklarını görebilirsiniz.
Bir web uygulaması düşünelim, bu web uygulaması giriş yaptıktan sonra kullanıcı adını ve günün tarihini birleştirip, base64 ile encode edip kullanıcıya veriyor olsun. Testlerimi gerçekleştirdiğim kendi kullanıcımın çerezini decode edip, diğer kullanıcıların adını biliyorsam, o günün tarihi ile çerezlerini oluşturmayı ve eğer o gün gerçek kullanıcılarda giriş yapmış ise canlı olan çerezleri tespit ederek kullanıcılar adına eylemler gerçekleştirmek denenebilir. Eğer bu denemelerde başarılı olursa, burada çerezlerin deşifre edilmesinden doğan “zayıf oturum yönetimi” (weak session management) zafiyeti vardır. Owasp top 10 açısından BAC kategorisine dahildir. Zayıf oturum yönetimi süreci, erişim kontrolü kısıtlamalarının yetersiz kalmasına neden olmaktadır.
İpucu: çerez deşifre edilememesi için sıklıkla tuzlama (salting) işleminden geçirilir. Ama kullanılmadığı durumlarda çerez craft ederek başka kullanıcılar üzerinde eylemler gerçekleştirmek için [kullanıcı_adı] + [şifre] kombinasyonu denenebilir. Çerezler içinde kullanıcı adı ve şifre geçmesi bu tarz zafiyetlerde karşılaşılabilen bir durumdur.
|
|
BAC ZAFİYETİNİ GİDERMEK İÇİN ÖNERİLER
Hedef kullanıcıların, uygulama üzerinde sahip olacağı yetkiler ve kısıtlamalar geliştirilme aşamasında belirlenmeli. Yetkilere uygun kısıtlayıcı prensiplerin uygulandığına emin olunmadan canlı ortama taşınmamalıdır.
Uygulama, gerçekleştirilecek aksiyon için sadece kullanıcı tarafından aldığı girişe bağlı kalmamalı, kullanıcının gerçekleştirmek istediği eylemin, yetkileri dahilinde olup olmadığını server tarafında da kontrol etmelidir. Tehdit aktörleri, Burp gibi araçlar kullanarak, geliştiricilerin kullanıcı ara yüzünde izin vermediği aksiyonlar gerçekleştirmeye çalışabilirler. Kullanıcı tarafından gelen bilgiler ve parametreler, filtrelenmeden ya da kontrol edilmeden işlenmemelidir. Birden fazla parametre içeren url ‘ler üzerinde hangi parametrenin işleneceğine dair kurallar belirlenmelidir. Yeterince kısıtlanmamış ortamlarda kullanıcı girişine hiçbir zaman güvenilmemelidir.
|
|
Erişim Kontrolü Önlemi Türleri
- Fiziksel: Elektronik veya yapısal olarak alt kategorilere ayrılır
- Mantıksal (logical)
|
|
Örnek Sorular
Kişilerin, erişimi kısıtlı bir alana erişmesi için bir dijital kart okuyucuya, kart okutarak geçtikleri bir kapı vardır. Bu erişim kısıtlayıcı önlemin türü nedir?
Cevap: Bu elektronik bir fiziksel önlemdir.
|
|
Kişiler, bir alışveriş web sitesinde ürün sipariş edebilmektedir. Satıcılar da, siteye ürünlerini yükleyebilmektedir. Bu sitede müşteri hesabı ile giriş yapmış bir kişi, ürün yükleme panelini görememekte ve eliyle url ’yi yazdığında da 401 Not authorized (yetkilendirilmemiş) uyarısını almaktadır. Bu web sitesi kullanıcıların yetki seviyesini server tarafında kontrol ederek, yetkileri dahilindeki sayfaları görmelerini ve yetkileri içinde bulunmayan özellikleri kullandırtmayan bir kontrol mekanizmasına sahiptir. Bu kontrol mekanizmasının türü nedir?
Cevap: Bu mantıksal bir dijital önlemdir.
|
|
Peki Neden?
Yukarıdaki sorularda örnekler ve cevaplar birbirlerinden farklıdır. Peki neden?
Kart okuyucuya okutulan kart neden elektronik bir fiziksel önlem olarak tanımlanır, ama mantıksal olarak tanımlanmaz? Çünkü örneğimizde sadece kart okutularak geçilen bir kısıtlama kontrolü vardır. Bu, başkasının kartına sahip olan biri o önlemi geçebilir demektir.
Alışveriş sitesinde, server tarafında yetki kontrolü gerçekleştiren kısıtlama önlemi neden mantıksaldır? Çünkü kişinin yetki seviyesini veri tabanından alır, erişmek istediği özellik onun hakları dahilinde mi olduğunu kontrol eder. “Yetkisi dahilinde mi?” sorusunun cevabı “evet” ise, özelliğe erişebilir. “Hayır” ise erişemez.
|
|
Özet:
– Erişim kontrolünden önce yetki seviyeleri ve farkları oluşturulur.
-Erişim kontrolü, yetki seviyesine göre nelerin yapılabileceğine dair farkların oluşturularak koşullara bağlanmasıdır.
– Prensiplerin yetersiz uygulanmasından doğar.
– “Yetkisi dahilinde mi?” “Evet” “Hayır”
– IDOR zafiyeti, BAC kategorisinden bir zafiyettir.

