- 29 Eki 2018
- 2,745
- 626
Erişim Kontrolü Güvenliği Zafiyetleri ve Yetki Yükseltmesi
Bu konuda erişim kontrolünün ve yetki yükseltmesinin ne olduğundan ve ilgili güvenlik açıklarından bahsedeceğiz. Lableri konunun hemen altındaki yorumlardan bulabilirsiniz.
Erişim Kontrolü Nedir?
Access control diye de geçer veya authorization duymuşsunuzdur. Bir yeri veya diğer kaynakları kimlerin veya nelerin görüntüleyebileceğini, kullanabileceğini veya erişebileceğini düzenleyen bir güvenlik tekniğidir. Web uygulamaları açısından bakacak olursak erişim kontrolü kimlik doğrulama ve oturum yönetimine bağlıdır.
Authentication kullanıcı söylediği kişi mi değil mi diye onaylar
Oturum yönetimi ise hangi ek http isteklerinin aynı kullanıcı tarafından yapıldığını belirler
Erişim kontrolü de kullanıcının gerçekleştireceği şeye izni var mı diye belirler.
Bozuk diyebileceğimiz kötü yapılandırılmış erişim kontrolleri sıkça karşılaşılan kritik güvenlik açıklarıdır. İşletme, organizasyon, yasal kısıtlamaları uygulayan erişim kontrollerinin tasarımı ve yönetimi karmaşıktır. Erişim kontrolü tasarım kararları insanlar tarafından yapılmak zorunda olduğu için hata olma olasılığı yüksektir.
Kullanıcı perspektifinden bakacak olursak erişim kontrolü aşağıda yazdığım gibi kategorilere ayrılabilir:
Dikey Erişim Kontrolleri / Vertical access controls
Vertical access controls, diğer kullanıcıların ulaşamadığı hassas fonksiyonlara erişimi kısıtlayan mekanizmalardır. Dikey Erişim Kontrolleriyle farklı türdeki kullanıcılar farklı uygulama fonksiyonlarına erişebilir. Örneğin bir yönetici (administrator) herhangi bir kullanıcının hesabını değiştirebilir veya silebilir. Bildiğiniz gibi bu gibi işlemleri diğer kullanıcılar gerçekleştiremiyor. Dikey Erişim Kontrolleri görevlerin ayrımı ve falanca şeye daha az ayrıcalık tanınması gibi bunun için tasarlanmış güvenlik modellerinin daha ince detaylı halidir.
Yatay Erişim Kontrolleri / Horizontal access controls
Yatay Erişim Kontrolleri kaynaklara erişimi kısıtlayan mekanizmalardır. Yatay erişim kontrolleri sayesinde farklı kullanıcılar aynı türdeki kaynakların bir alt kümesine erişebilir. Mesela bankacılık uygulamaları kullanıcının hesabındaki işlemlerini görüntülemesine izin veriyor ancak başka bir kullanıcınınkini görmesine izin vermiyor.
Bağlam Bağımlı Erişim Kontrol Modeli / Context-dependent access controls
Context-dependent access controls, işlevselliğe ve kaynaklara olan erişimi kullanıcının etkileşim kurduğu uygulamanın durumuna göre kısıtlayabilen mekanizmalardır. Yani bir kullanıcının işlemleri yanlış sırayla gerçekleştirmesini önler. Örneğin bir e-ticaret sitesi kullanıcıların ödeme yaptıktan sonra alışveriş sepetlerinin içeriğini değiştirmesini engelleyebilir.
Bozuk Erişim Kontrollerine Örnekler
Bozuk erişim kontrolü açıkları varsa bir kullanıcı erişememesi gereken bir işlemi gerçekleştirebiliyor demektir.
Vertical Privilege Escalation (Dikey Ayrıcalık Yükseltme)
Eğer kullanıcı erişememesi gereken fonksiyonlara erişim sağladıysa bu dikey ayrıcalık yükseltmedir. Mesela yetkisi olmayan bir kullanıcı yönetici paneline erişip diğer kullanıcıların hesaplarını silebilirse işte bu ayrıcalık yükseltmedir.
Genellikle hassas fonksiyonlara karşı herhangi bir koruma olmadığında dikey ayrıcalık yükseltmeyle karşılaşırız. Adminin çalıştırabileceği admine özel fonksiyonların adminin hoşgeldiniz sayfasıyla ilişkili olması ama sıradan bir kullanıcının hoşgeldiniz sayfasıyla ilişkili olmamasını örnek olarak düşünebilirsiniz. Ancak kullanıcı hassas fonksiyonların olduğu bu panele girebilir hele ki herkes tarafından erişilebilir olursa direkt link ile gider örneğin şu şekilde:
Bazı durumlarda yöneticilerin kullanması gereken fonksiyonlara sahip olan bu sayfalar robots.txt dosyasında belirtilmiş olabilir. Bu URL belirtilmemiş de olsa saldırgan bir wordlist oluşturup Brute Force yöntemiyle URL'i bulabilir. Bazen bu hassas fonksiyonların olduğu panel sağlam korunmaz ama URL'i çok az tahmin edilebilecek şekilde ayarlarlar. Bu doğru bir yöntem değildir çünkü URL her ne kadar gizlenmiş olsa da bulmak için birçok yöntem denenebilir.
Örneğin URL şu şekilde olsun:
Bu direkt olarak saldırgan tarafından tahmin edilemeyebilir ama mesela kullanıcı arayüzünü oluşturan JavaScript içerisinde verilmiş olabilir:
Bu script kullanıcının arayüzüne link ekliyor eğer kullanıcı adminse tabi.
Parametre Tabanlı Erişim Kontrol Yöntemleri
Bazı uygulamalar kullanıcının erişim haklarını giriş yapma anında belirler ve bu bilgiler çerezler gibi kullanıcı tarafından kontrol edilebilecek şekilde depolanır. Yani uygulama gönderilen değerlere göre erişim haklarını belirler. Örneğin:
Yukarıdaki gibi kullanıcılar basitçe birkaç değeri değiştirip yöneticinin erişim haklarına sahip olabilir.
Bazı uygulamalar, kullanıcının rolüne bağlı olarak belirli URL'lere ve HTTP yöntemlerine erişimi kısıtlayarak platform katmanında erişim kontrolleri uygular. Örneğin bir uygulama aşağıdaki gibi kurallar yapılandırabilir:
Bu kural, managers grubundaki kullanıcılar için /admin/deleteUser URL'sindeki POST yöntemine erişimi reddeder. Bu durumda çeşitli şeyler yanlış gidebilir ve erişim denetimi atlamalarına yol açabilir.
Bazı uygulama çerçeveleri, X-Original-URL ve X-Rewrite-URL gibi orijinal istekte URL'yi geçersiz kılmak için kullanılabilecek çeşitli standart dışı HTTP başlıklarını destekler. Bir web sitesi URL'ye dayalı erişimi kısıtlamak için titiz ön uç denetimleri kullanıyorsa, ancak uygulama URL'nin bir istek başlığı aracılığıyla geçersiz kılınmasına izin veriyorsa, aşağıdaki gibi bir istek kullanarak erişim denetimlerini atlamak mümkün olabilir:
Lab: https://portswigger.net/web-security/access-control/lab-url-based-access-control-can-be-circumvented
İstekte kullanılan HTTP yöntemiyle ilgili olarak alternatif bir saldırı ortaya çıkabilir. Yukarıdaki ön uç kontrolleri URL ve HTTP yöntemine göre erişimi kısıtlar. Bazı web siteleri, bir eylem gerçekleştirirken alternatif HTTP istek yöntemlerine tolerans gösterir. Bir saldırgan kısıtlanmış bir URL üzerinde eylem gerçekleştirmek için GET (veya başka bir) yöntemini kullanabilirse, platform katmanında uygulanan erişim kontrolünü atlatabilir.
Lab: https://portswigger.net/web-security/access-control/lab-method-based-access-control-can-be-circumvented
Gelen istekleri yönlendirirken, web siteleri yolun tanımlanmış bir uç noktayla ne kadar sıkı eşleşmesi gerektiğine göre değişir. Örneğin, tutarsız büyük harf kullanımına tolerans gösterebilirler, bu nedenle /ADMIN/DELETEUSER yönündeki bir istek yine de aynı /admin/deleteUser uç noktasına eşlenebilir. Bu kendi başına bir sorun değildir, ancak erişim kontrol mekanizması daha az toleranslıysa, bunları iki farklı uç nokta olarak ele alabilir ve sonuç olarak uygun kısıtlamaları uygulayamayabilir.
Spring framework kullanan geliştiriciler useSuffixPatternMatch seçeneğini etkinleştirmişse benzer tutarsızlıklar ortaya çıkabilir. Bu, rastgele bir dosya uzantısına sahip yolların, dosya uzantısı olmayan eşdeğer bir uç noktayla eşleştirilmesine olanak tanır. Başka bir deyişle, /admin/deleteUser.anything adresine yapılan bir istek yine de /admin/deleteUser kalıbıyla eşleşecektir. Spring 5.3 öncesinde bu seçenek varsayılan olarak etkindir.
Diğer sistemlerde /admin/deleteUser ve /admin/deleteUser/ adreslerinin farklı uç noktalar olarak ele alınıp alınmadığı konusunda tutarsızlıklarla karşılaşabilirsiniz. Bu durumda, sadece yola sondaki eğik çizgiyi ekleyerek erişim kontrollerini atlayabilirsiniz.
Yatay ayrıcalık yükseltme, bir kullanıcının o türden kendi kaynakları yerine başka bir kullanıcıya ait kaynaklara erişim sağlayabildiği durumlarda ortaya çıkar. Örneğin, bir çalışanın yalnızca kendi istihdam ve bordro kayıtlarına erişebilmesi gerekirken aslında diğer çalışanların kayıtlarına da erişebiliyorsa, bu yatay ayrıcalık yükseltmedir.
Yatay ayrıcalık yükseltme saldırıları, dikey ayrıcalık yükseltmeye benzer türde istismar yöntemleri kullanabilir. Örneğin, bir kullanıcı normalde aşağıdaki gibi bir URL kullanarak kendi hesap sayfasına erişebilir:
Şimdi, bir saldırgan id parametre değerini başka bir kullanıcınınkiyle değiştirirse, saldırgan ilişkili veriler ve işlevlerle birlikte başka bir kullanıcının hesap sayfasına erişim kazanabilir.
Lab: https://portswigger.net/web-security/access-control/lab-user-id-controlled-by-request-parameter
Bazı uygulamalarda, istismar edilebilir parametre tahmin edilebilir bir değere sahip değildir. Örneğin, bir uygulama kullanıcıları tanımlamak için artan bir sayı yerine global olarak benzersiz tanımlayıcılar (GUID'ler) kullanabilir. Burada, bir saldırgan başka bir kullanıcı için tanımlayıcıyı tahmin edemeyebilir veya tahmin edemeyebilir. Ancak, diğer kullanıcılara ait GUID'ler, kullanıcı mesajları veya incelemeleri gibi kullanıcılara atıfta bulunulan uygulamanın başka yerlerinde ifşa edilebilir.
Lab: https://portswigger.net/web-security/access-control/lab-user-id-controlled-by-request-parameter-with-unpredictable-user-ids
Bazı durumlarda, bir uygulama kullanıcının kaynağa erişmesine izin verilmediğini tespit eder ve giriş sayfasına bir yönlendirme döndürür. Ancak, yönlendirmeyi içeren yanıt yine de hedeflenen kullanıcıya ait bazı hassas veriler içerebilir, bu nedenle saldırı yine de başarılı olur.
Lab: https://portswigger.net/web-security/access-control/lab-user-id-controlled-by-request-parameter-with-data-leakage-in-redirect
Genellikle, yatay bir ayrıcalık yükseltme saldırısı, daha ayrıcalıklı bir kullanıcıyı tehlikeye atarak dikey bir ayrıcalık yükseltmeye dönüştürülebilir. Örneğin, yatay bir yetki artırımı, saldırganın başka bir kullanıcıya ait parolayı sıfırlamasına veya ele geçirmesine olanak tanıyabilir. Saldırgan yönetici bir kullanıcıyı hedef alır ve hesabını ele geçirirse, yönetici erişimi elde edebilir ve böylece dikey ayrıcalık yükseltme gerçekleştirebilir.
Örneğin, bir saldırgan yatay ayrıcalık yükseltme için daha önce açıklanan parametre kurcalama tekniğini kullanarak başka bir kullanıcının hesap sayfasına erişim elde edebilir:
Hedef kullanıcı bir uygulama yöneticisi ise, saldırgan bir yönetici hesabı sayfasına erişim elde edecektir. Bu sayfa, yöneticinin parolasını ifşa edebilir veya değiştirmek için bir araç sağlayabilir ya da ayrıcalıklı işlevlere doğrudan erişim sağlayabilir.
Lab: https://portswigger.net/web-security/access-control/lab-user-id-controlled-by-request-parameter-with-password-disclosure
IDOR, erişim denetimi güvenlik açıklarının bir alt kategorisidir. IDOR, bir uygulama nesnelere doğrudan erişmek için kullanıcı tarafından sağlanan girdiyi kullandığında ve bir saldırgan yetkisiz erişim elde etmek için girdiyi değiştirebildiğinde ortaya çıkar. Erişim kontrollerinin atlatılmasına yol açabilecek birçok uygulama hatasından sadece bir örnek olmasına rağmen OWASP 2007 Top Ten'de yer almasıyla popüler hale gelmiştir.
Lab: https://portswigger.net/web-security/access-control/lab-insecure-direct-object-references
Veritabanı nesnelerine doğrudan referansı bulunan IDOR açığı
Back-end veritabanından bilgi alarak müşteri hesabı sayfasına erişmek için aşağıdaki URL'yi kullanan bir web sitesi düşünün:
Burada müşteri numarası, back-end veritabanında gerçekleştirilen sorgularda doğrudan bir kayıt indeksi olarak kullanılmaktadır. Başka bir denetim yoksa bir saldırgan diğer müşterilerin kayıtlarını görüntülemek için erişim denetimlerini atlayarak customer_number değerini kolayca değiştirebilir. Bu, yatay ayrıcalığın yüksetilmesine yol açan bir IDOR güvenlik açığıdır.
Saldırgan, erişim kontrollerini atlayarak kullanıcıyı ek ayrıcalıklara sahip bir kullanıcıyla değiştirerek yatay ve dikey ayrıcalık yükseltmesi gerçekleştirebilir. Diğer olasılıklar arasında örnek olarak saldırgan kullanıcının hesapları sayfasına girdikten sonra parola sızıntısından yararlanmak veya parametreleri değiştirmek yer alır.
Statik dosyalara doğrudan referansı bulunan IDOR açığı
IDOR güvenlik açıkları genellikle hassas kaynaklar server-side dosya sistemindeki statik dosyalarda bulunduğunda ortaya çıkar. Örneğin, bir web sitesi artan bir dosya adı kullanarak sohbet mesajı transkriptlerini diske kaydedebilir ve kullanıcıların aşağıdaki gibi bir URL'yi ziyaret ederek bunları almasına izin verebilir:
Bu durumda bir saldırgan, başka bir kullanıcı tarafından oluşturulan bir transcripti almak ve potansiyel olarak kullanıcı kimlik bilgilerini ve diğer hassas verileri elde etmek için dosya adını değiştirebilir.
Lab: Lab: Insecure direct object references | Web Security Academy
Çok adımlı süreçlerde erişim kontrolü açıkları
Birçok web sitesi önemli işlevleri bir dizi adımda gerçekleştirir. Bu genellikle çeşitli girdilerin veya seçeneklerin yakalanması gerektiğinde veya eylem gerçekleştirilmeden önce kullanıcının ayrıntıları gözden geçirmesi ve onaylaması gerektiğinde yapılır. Örneğin, kullanıcı bilgilerini güncellemeye yönelik bir yönetim işlevi aşağıdaki adımları içerebilir:
Lab: https://portswigger.net/web-security/access-control/lab-multi-step-process-with-no-access-control-on-one-step
Bazı web siteleri erişim kontrollerini HTTP isteğinde gönderilen Referer başlığına dayandırır. Referer başlığı genellikle bir isteğin başlatıldığı sayfayı belirtmek için tarayıcılar tarafından isteklere eklenir.
Örneğin, bir uygulamanın /admin adresindeki ana yönetim sayfası üzerinde erişim kontrolünü güçlü bir şekilde uyguladığını, ancak /admin/deleteUser gibi alt sayfalar için yalnızca Referer başlığını incelediğini varsayalım. Referer başlığı ana /admin URL'sini içeriyorsa, isteğe izin verilir.
Bu durumda, Referer başlığı bir saldırgan tarafından tamamen kontrol edilebildiğinden, gerekli Referer başlığını sağlayarak hassas alt sayfalara doğrudan istekleri taklit edebilir ve böylece yetkisiz erişim elde edebilirler.
Lab: https://portswigger.net/web-security/access-control/lab-referer-based-access-control
Bazı web siteleri, kullanıcının coğrafi konumuna bağlı olarak kaynaklar üzerinde erişim kontrolleri uygular. Bu, örneğin, devlet mevzuatı veya ticari kısıtlamaların geçerli olduğu bankacılık uygulamaları veya medya hizmetleri için geçerli olabilir. Bu erişim kontrolleri genellikle web proxy'leri, VPN'ler kullanılarak veya istemci tarafı coğrafi konum belirleme mekanizmaları manipüle edilerek atlatılabilir.
Erişim kontrolü güvenlik açıkları genellikle derinlemesine savunma yaklaşımı benimsenerek ve aşağıdaki ilkeler uygulanarak önlenebilir:
Kaynak: Access control vulnerabilities and privilege escalation | Web Security Academy
Çevirmenler: @Gauloran @Secret Person @Dolyetyus
Bu konuda erişim kontrolünün ve yetki yükseltmesinin ne olduğundan ve ilgili güvenlik açıklarından bahsedeceğiz. Lableri konunun hemen altındaki yorumlardan bulabilirsiniz.
Erişim Kontrolü Nedir?
Access control diye de geçer veya authorization duymuşsunuzdur. Bir yeri veya diğer kaynakları kimlerin veya nelerin görüntüleyebileceğini, kullanabileceğini veya erişebileceğini düzenleyen bir güvenlik tekniğidir. Web uygulamaları açısından bakacak olursak erişim kontrolü kimlik doğrulama ve oturum yönetimine bağlıdır.
Authentication kullanıcı söylediği kişi mi değil mi diye onaylar
Oturum yönetimi ise hangi ek http isteklerinin aynı kullanıcı tarafından yapıldığını belirler
Erişim kontrolü de kullanıcının gerçekleştireceği şeye izni var mı diye belirler.
Bozuk diyebileceğimiz kötü yapılandırılmış erişim kontrolleri sıkça karşılaşılan kritik güvenlik açıklarıdır. İşletme, organizasyon, yasal kısıtlamaları uygulayan erişim kontrollerinin tasarımı ve yönetimi karmaşıktır. Erişim kontrolü tasarım kararları insanlar tarafından yapılmak zorunda olduğu için hata olma olasılığı yüksektir.
Kullanıcı perspektifinden bakacak olursak erişim kontrolü aşağıda yazdığım gibi kategorilere ayrılabilir:
- Dikey erişim kontrolleri (Vertical access controls)
- Yatay erişim kontrolleri (Horizontal access controls)
- İçerik ve Bağlam Bağımlı Erişim Kontrol (Content and Context-Dependent Access Controls)
Dikey Erişim Kontrolleri / Vertical access controls
Vertical access controls, diğer kullanıcıların ulaşamadığı hassas fonksiyonlara erişimi kısıtlayan mekanizmalardır. Dikey Erişim Kontrolleriyle farklı türdeki kullanıcılar farklı uygulama fonksiyonlarına erişebilir. Örneğin bir yönetici (administrator) herhangi bir kullanıcının hesabını değiştirebilir veya silebilir. Bildiğiniz gibi bu gibi işlemleri diğer kullanıcılar gerçekleştiremiyor. Dikey Erişim Kontrolleri görevlerin ayrımı ve falanca şeye daha az ayrıcalık tanınması gibi bunun için tasarlanmış güvenlik modellerinin daha ince detaylı halidir.
Yatay Erişim Kontrolleri / Horizontal access controls
Yatay Erişim Kontrolleri kaynaklara erişimi kısıtlayan mekanizmalardır. Yatay erişim kontrolleri sayesinde farklı kullanıcılar aynı türdeki kaynakların bir alt kümesine erişebilir. Mesela bankacılık uygulamaları kullanıcının hesabındaki işlemlerini görüntülemesine izin veriyor ancak başka bir kullanıcınınkini görmesine izin vermiyor.
Bağlam Bağımlı Erişim Kontrol Modeli / Context-dependent access controls
Context-dependent access controls, işlevselliğe ve kaynaklara olan erişimi kullanıcının etkileşim kurduğu uygulamanın durumuna göre kısıtlayabilen mekanizmalardır. Yani bir kullanıcının işlemleri yanlış sırayla gerçekleştirmesini önler. Örneğin bir e-ticaret sitesi kullanıcıların ödeme yaptıktan sonra alışveriş sepetlerinin içeriğini değiştirmesini engelleyebilir.
Bozuk Erişim Kontrollerine Örnekler
Bozuk erişim kontrolü açıkları varsa bir kullanıcı erişememesi gereken bir işlemi gerçekleştirebiliyor demektir.
Vertical Privilege Escalation (Dikey Ayrıcalık Yükseltme)
Eğer kullanıcı erişememesi gereken fonksiyonlara erişim sağladıysa bu dikey ayrıcalık yükseltmedir. Mesela yetkisi olmayan bir kullanıcı yönetici paneline erişip diğer kullanıcıların hesaplarını silebilirse işte bu ayrıcalık yükseltmedir.
Genellikle hassas fonksiyonlara karşı herhangi bir koruma olmadığında dikey ayrıcalık yükseltmeyle karşılaşırız. Adminin çalıştırabileceği admine özel fonksiyonların adminin hoşgeldiniz sayfasıyla ilişkili olması ama sıradan bir kullanıcının hoşgeldiniz sayfasıyla ilişkili olmamasını örnek olarak düşünebilirsiniz. Ancak kullanıcı hassas fonksiyonların olduğu bu panele girebilir hele ki herkes tarafından erişilebilir olursa direkt link ile gider örneğin şu şekilde:
Bazı durumlarda yöneticilerin kullanması gereken fonksiyonlara sahip olan bu sayfalar robots.txt dosyasında belirtilmiş olabilir. Bu URL belirtilmemiş de olsa saldırgan bir wordlist oluşturup Brute Force yöntemiyle URL'i bulabilir. Bazen bu hassas fonksiyonların olduğu panel sağlam korunmaz ama URL'i çok az tahmin edilebilecek şekilde ayarlarlar. Bu doğru bir yöntem değildir çünkü URL her ne kadar gizlenmiş olsa da bulmak için birçok yöntem denenebilir.
Örneğin URL şu şekilde olsun:
Kod:
https://insecure-website.com/administrator-panel-yb556Bu direkt olarak saldırgan tarafından tahmin edilemeyebilir ama mesela kullanıcı arayüzünü oluşturan JavaScript içerisinde verilmiş olabilir:
JavaScript:
<script>
var isAdmin = false;
if (isAdmin) {
...
var adminPanelTag = document.createElement('a');
adminPanelTag.setAttribute('https://insecure-website.com/administrator-panel-yb556');
adminPanelTag.innerText = 'Admin panel';
...
}
</script>Bu script kullanıcının arayüzüne link ekliyor eğer kullanıcı adminse tabi.
Parametre Tabanlı Erişim Kontrol Yöntemleri
Bazı uygulamalar kullanıcının erişim haklarını giriş yapma anında belirler ve bu bilgiler çerezler gibi kullanıcı tarafından kontrol edilebilecek şekilde depolanır. Yani uygulama gönderilen değerlere göre erişim haklarını belirler. Örneğin:
Kod:
https://insecure-website.com/login/home.jsp?admin=true
https://insecure-website.com/login/home.jsp?role=1Yukarıdaki gibi kullanıcılar basitçe birkaç değeri değiştirip yöneticinin erişim haklarına sahip olabilir.
Platformun yanlış yapılandırılmasından kaynaklanan bozuk erişim kontrolü
Bazı uygulamalar, kullanıcının rolüne bağlı olarak belirli URL'lere ve HTTP yöntemlerine erişimi kısıtlayarak platform katmanında erişim kontrolleri uygular. Örneğin bir uygulama aşağıdaki gibi kurallar yapılandırabilir:
Kod:
DENY: POST, /admin/deleteUser, managersBu kural, managers grubundaki kullanıcılar için /admin/deleteUser URL'sindeki POST yöntemine erişimi reddeder. Bu durumda çeşitli şeyler yanlış gidebilir ve erişim denetimi atlamalarına yol açabilir.
Bazı uygulama çerçeveleri, X-Original-URL ve X-Rewrite-URL gibi orijinal istekte URL'yi geçersiz kılmak için kullanılabilecek çeşitli standart dışı HTTP başlıklarını destekler. Bir web sitesi URL'ye dayalı erişimi kısıtlamak için titiz ön uç denetimleri kullanıyorsa, ancak uygulama URL'nin bir istek başlığı aracılığıyla geçersiz kılınmasına izin veriyorsa, aşağıdaki gibi bir istek kullanarak erişim denetimlerini atlamak mümkün olabilir:
Kod:
POST / HTTP/1.1
X-Original-URL: /admin/deleteUser
...Lab: https://portswigger.net/web-security/access-control/lab-url-based-access-control-can-be-circumvented
İstekte kullanılan HTTP yöntemiyle ilgili olarak alternatif bir saldırı ortaya çıkabilir. Yukarıdaki ön uç kontrolleri URL ve HTTP yöntemine göre erişimi kısıtlar. Bazı web siteleri, bir eylem gerçekleştirirken alternatif HTTP istek yöntemlerine tolerans gösterir. Bir saldırgan kısıtlanmış bir URL üzerinde eylem gerçekleştirmek için GET (veya başka bir) yöntemini kullanabilirse, platform katmanında uygulanan erişim kontrolünü atlatabilir.
Lab: https://portswigger.net/web-security/access-control/lab-method-based-access-control-can-be-circumvented
URL eşleştirme tutarsızlıklarından kaynaklanan bozuk erişim kontrolü
Gelen istekleri yönlendirirken, web siteleri yolun tanımlanmış bir uç noktayla ne kadar sıkı eşleşmesi gerektiğine göre değişir. Örneğin, tutarsız büyük harf kullanımına tolerans gösterebilirler, bu nedenle /ADMIN/DELETEUSER yönündeki bir istek yine de aynı /admin/deleteUser uç noktasına eşlenebilir. Bu kendi başına bir sorun değildir, ancak erişim kontrol mekanizması daha az toleranslıysa, bunları iki farklı uç nokta olarak ele alabilir ve sonuç olarak uygun kısıtlamaları uygulayamayabilir.
Spring framework kullanan geliştiriciler useSuffixPatternMatch seçeneğini etkinleştirmişse benzer tutarsızlıklar ortaya çıkabilir. Bu, rastgele bir dosya uzantısına sahip yolların, dosya uzantısı olmayan eşdeğer bir uç noktayla eşleştirilmesine olanak tanır. Başka bir deyişle, /admin/deleteUser.anything adresine yapılan bir istek yine de /admin/deleteUser kalıbıyla eşleşecektir. Spring 5.3 öncesinde bu seçenek varsayılan olarak etkindir.
Diğer sistemlerde /admin/deleteUser ve /admin/deleteUser/ adreslerinin farklı uç noktalar olarak ele alınıp alınmadığı konusunda tutarsızlıklarla karşılaşabilirsiniz. Bu durumda, sadece yola sondaki eğik çizgiyi ekleyerek erişim kontrollerini atlayabilirsiniz.
Yatay ayrıcalık yükseltme
Yatay ayrıcalık yükseltme, bir kullanıcının o türden kendi kaynakları yerine başka bir kullanıcıya ait kaynaklara erişim sağlayabildiği durumlarda ortaya çıkar. Örneğin, bir çalışanın yalnızca kendi istihdam ve bordro kayıtlarına erişebilmesi gerekirken aslında diğer çalışanların kayıtlarına da erişebiliyorsa, bu yatay ayrıcalık yükseltmedir.
Yatay ayrıcalık yükseltme saldırıları, dikey ayrıcalık yükseltmeye benzer türde istismar yöntemleri kullanabilir. Örneğin, bir kullanıcı normalde aşağıdaki gibi bir URL kullanarak kendi hesap sayfasına erişebilir:
HTTP:
https://insecure-website.com/myaccount?id=123Şimdi, bir saldırgan id parametre değerini başka bir kullanıcınınkiyle değiştirirse, saldırgan ilişkili veriler ve işlevlerle birlikte başka bir kullanıcının hesap sayfasına erişim kazanabilir.
Lab: https://portswigger.net/web-security/access-control/lab-user-id-controlled-by-request-parameter
Bazı uygulamalarda, istismar edilebilir parametre tahmin edilebilir bir değere sahip değildir. Örneğin, bir uygulama kullanıcıları tanımlamak için artan bir sayı yerine global olarak benzersiz tanımlayıcılar (GUID'ler) kullanabilir. Burada, bir saldırgan başka bir kullanıcı için tanımlayıcıyı tahmin edemeyebilir veya tahmin edemeyebilir. Ancak, diğer kullanıcılara ait GUID'ler, kullanıcı mesajları veya incelemeleri gibi kullanıcılara atıfta bulunulan uygulamanın başka yerlerinde ifşa edilebilir.
Lab: https://portswigger.net/web-security/access-control/lab-user-id-controlled-by-request-parameter-with-unpredictable-user-ids
Bazı durumlarda, bir uygulama kullanıcının kaynağa erişmesine izin verilmediğini tespit eder ve giriş sayfasına bir yönlendirme döndürür. Ancak, yönlendirmeyi içeren yanıt yine de hedeflenen kullanıcıya ait bazı hassas veriler içerebilir, bu nedenle saldırı yine de başarılı olur.
Lab: https://portswigger.net/web-security/access-control/lab-user-id-controlled-by-request-parameter-with-data-leakage-in-redirect
Yataydan dikeye ayrıcalık yükseltme
Genellikle, yatay bir ayrıcalık yükseltme saldırısı, daha ayrıcalıklı bir kullanıcıyı tehlikeye atarak dikey bir ayrıcalık yükseltmeye dönüştürülebilir. Örneğin, yatay bir yetki artırımı, saldırganın başka bir kullanıcıya ait parolayı sıfırlamasına veya ele geçirmesine olanak tanıyabilir. Saldırgan yönetici bir kullanıcıyı hedef alır ve hesabını ele geçirirse, yönetici erişimi elde edebilir ve böylece dikey ayrıcalık yükseltme gerçekleştirebilir.
Örneğin, bir saldırgan yatay ayrıcalık yükseltme için daha önce açıklanan parametre kurcalama tekniğini kullanarak başka bir kullanıcının hesap sayfasına erişim elde edebilir:
HTTP:
https://insecure-website.com/myaccount?id=456Hedef kullanıcı bir uygulama yöneticisi ise, saldırgan bir yönetici hesabı sayfasına erişim elde edecektir. Bu sayfa, yöneticinin parolasını ifşa edebilir veya değiştirmek için bir araç sağlayabilir ya da ayrıcalıklı işlevlere doğrudan erişim sağlayabilir.
Lab: https://portswigger.net/web-security/access-control/lab-user-id-controlled-by-request-parameter-with-password-disclosure
Insecure direct object references
IDOR, erişim denetimi güvenlik açıklarının bir alt kategorisidir. IDOR, bir uygulama nesnelere doğrudan erişmek için kullanıcı tarafından sağlanan girdiyi kullandığında ve bir saldırgan yetkisiz erişim elde etmek için girdiyi değiştirebildiğinde ortaya çıkar. Erişim kontrollerinin atlatılmasına yol açabilecek birçok uygulama hatasından sadece bir örnek olmasına rağmen OWASP 2007 Top Ten'de yer almasıyla popüler hale gelmiştir.
Lab: https://portswigger.net/web-security/access-control/lab-insecure-direct-object-references
IDOR kontrolü güvenlik açıkları nasıl önlenir?
Bu bölümde, IDOR'un ne olduğunu ve bazı yaygın güvenlik açıklarını açıklayacağız.IDOR nedir?
Insecure direct object references (Türkçe: Güvenli olmayan doğrudan nesne referansları), bir uygulama kullanılarak nesnelere doğrudan erişmek için kullanıcı inputunu kullandığında ortaya çıkan bir tür erişim denetimi güvenlik açığıdır. IDOR terimi, OWASP 2007 Top 10'da yer almasıyla popüler hale geldi. Ancak bu, erişim kontrollerinin atlatılmasına yol açabilen birçok erişim kontrolü uygulama hatasından sadece bir tanesidir. IDOR güvenlik açıkları en yaygın olarak yatay ayrıcalık yükseltme ile ilişkilidir ancak dikey ayrıcalık yükseltme ile ilgili olarak da ortaya çıkabilirler.IDOR örnekleri
Resource'lara veya fonksiyonlara doğrudan erişmek için kullanıcı tarafından kontrol edilen parametre değerlerinin kullanıldığı birçok erişim kontrol güvenlik açığı örneği vardır.Veritabanı nesnelerine doğrudan referansı bulunan IDOR açığı
Back-end veritabanından bilgi alarak müşteri hesabı sayfasına erişmek için aşağıdaki URL'yi kullanan bir web sitesi düşünün:
Kod:
https://insecure-website.com/customer_account?customer_number=132355Saldırgan, erişim kontrollerini atlayarak kullanıcıyı ek ayrıcalıklara sahip bir kullanıcıyla değiştirerek yatay ve dikey ayrıcalık yükseltmesi gerçekleştirebilir. Diğer olasılıklar arasında örnek olarak saldırgan kullanıcının hesapları sayfasına girdikten sonra parola sızıntısından yararlanmak veya parametreleri değiştirmek yer alır.
Statik dosyalara doğrudan referansı bulunan IDOR açığı
IDOR güvenlik açıkları genellikle hassas kaynaklar server-side dosya sistemindeki statik dosyalarda bulunduğunda ortaya çıkar. Örneğin, bir web sitesi artan bir dosya adı kullanarak sohbet mesajı transkriptlerini diske kaydedebilir ve kullanıcıların aşağıdaki gibi bir URL'yi ziyaret ederek bunları almasına izin verebilir:
Kod:
https://insecure-website.com/static/12144.txtBu durumda bir saldırgan, başka bir kullanıcı tarafından oluşturulan bir transcripti almak ve potansiyel olarak kullanıcı kimlik bilgilerini ve diğer hassas verileri elde etmek için dosya adını değiştirebilir.
Lab: Lab: Insecure direct object references | Web Security Academy
Çok adımlı süreçlerde erişim kontrolü açıkları
Birçok web sitesi önemli işlevleri bir dizi adımda gerçekleştirir. Bu genellikle çeşitli girdilerin veya seçeneklerin yakalanması gerektiğinde veya eylem gerçekleştirilmeden önce kullanıcının ayrıntıları gözden geçirmesi ve onaylaması gerektiğinde yapılır. Örneğin, kullanıcı bilgilerini güncellemeye yönelik bir yönetim işlevi aşağıdaki adımları içerebilir:
- Belirli bir kullanıcı için ayrıntıları içeren formu yükleyin.
- Değişiklikleri gönderin.
- Değişiklikleri gözden geçirin ve onaylayın.
Lab: https://portswigger.net/web-security/access-control/lab-multi-step-process-with-no-access-control-on-one-step
Yönlendirici tabanlı erişim kontrolü
Bazı web siteleri erişim kontrollerini HTTP isteğinde gönderilen Referer başlığına dayandırır. Referer başlığı genellikle bir isteğin başlatıldığı sayfayı belirtmek için tarayıcılar tarafından isteklere eklenir.
Örneğin, bir uygulamanın /admin adresindeki ana yönetim sayfası üzerinde erişim kontrolünü güçlü bir şekilde uyguladığını, ancak /admin/deleteUser gibi alt sayfalar için yalnızca Referer başlığını incelediğini varsayalım. Referer başlığı ana /admin URL'sini içeriyorsa, isteğe izin verilir.
Bu durumda, Referer başlığı bir saldırgan tarafından tamamen kontrol edilebildiğinden, gerekli Referer başlığını sağlayarak hassas alt sayfalara doğrudan istekleri taklit edebilir ve böylece yetkisiz erişim elde edebilirler.
Lab: https://portswigger.net/web-security/access-control/lab-referer-based-access-control
Konum tabanlı erişim kontrolü
Bazı web siteleri, kullanıcının coğrafi konumuna bağlı olarak kaynaklar üzerinde erişim kontrolleri uygular. Bu, örneğin, devlet mevzuatı veya ticari kısıtlamaların geçerli olduğu bankacılık uygulamaları veya medya hizmetleri için geçerli olabilir. Bu erişim kontrolleri genellikle web proxy'leri, VPN'ler kullanılarak veya istemci tarafı coğrafi konum belirleme mekanizmaları manipüle edilerek atlatılabilir.
Erişim kontrolü güvenlik açıkları nasıl önlenir
Erişim kontrolü güvenlik açıkları genellikle derinlemesine savunma yaklaşımı benimsenerek ve aşağıdaki ilkeler uygulanarak önlenebilir:
- Erişim kontrolü için asla tek başına gizlemeye güvenmeyin.
- Bir kaynağın herkes tarafından erişilebilir olması amaçlanmadığı sürece, varsayılan olarak erişimi reddedin.
- Mümkün olan her yerde, erişim kontrollerini uygulamak için uygulama çapında tek bir mekanizma kullanın.
- Kod düzeyinde, geliştiricilerin her kaynak için izin verilen erişimi beyan etmelerini zorunlu hale getirin ve varsayılan olarak erişimi reddedin.
- Tasarlandıkları gibi çalıştıklarından emin olmak için erişim kontrollerini kapsamlı bir şekilde denetleyin ve test edin.
Kaynak: Access control vulnerabilities and privilege escalation | Web Security Academy
Çevirmenler: @Gauloran @Secret Person @Dolyetyus
Moderatör tarafında düzenlendi:
