Selamlar değerli SaüSiber takipçileri,
Web uygulama güvenliğinde bazı zafiyetler vardır ki hem çok yaygındır hem de fark edilmesi bir o kadar zordur. IDOR (Insecure Direct Object Reference) da tam olarak bu kategoride yer alır. Çoğu zaman basit bir ID değişikliğiyle ortaya çıkar, ama etkisi ciddi veri sızıntılarına kadar gidebilir.
Bu yazıda IDOR'un ne olduğunu, neden oluştuğunu ve modern web uygulamalarında neden bu kadar sık karşımıza çıktığını adım adım inceleyeceğiz. Öncesinde web uygulamalarında input kavramı, kural setleri ve yetkilendirme mantığı gibi IDOR'u anlamak için gerekli temel noktalara değineceğiz. Ardından HTTP status code'ların IDOR testlerindeki önemine bakacak ve gerçek bir PortSwigger labı üzerinden IDOR'un pratikte nasıl istismar edilebildiğini göreceğiz.
Kısacası bu yazı, IDOR'u hem teorik hem de uygulamalı olarak anlamak isteyenler için bir rehber niteliğinde olacak. Hazırsanız, temel bilgilerle başlayalım.
Temel Bilgiler
Web uygulamalarında en kritik, haliyle en önemli nokta inputlardır. Inputtan kastımız, kullanıcının veri girişi yapabildiği veya dolaylı olarak değiştirebildiği her şey olabilir: arama motoru, yorum yazma kısımları, web uygulamasındaki URL, HTTP requestindeki her şey bu inputlara dahildir.
Web uygulamalarında kullanıcı bir bilgi talep ettiğinde, uygulama kullanıcıdan aldığı bilgiler ile veri tabanına gider ve talep edilen bilgiyi alır. Bu talep isteğini gönderen kişi sadece kendi verisini görmelidir. Buna kural setleri denir.
Talep isteği, yine yukarıda da söylediğimiz gibi inputlardan gelir. Aslında IDOR'u, bu iki özelliğin kullanılarak oluştuğunu söyleyebiliriz.
IDOR NEDİR?
Açılımı Insecure Direct Object Reference olan IDOR, aslında kural setlerinin dışına çıkarak normalde o kullanıcının erişemeyeceği bir bilgiye ulaşmasıdır.
Gerçek hayattan örnek vermek gerekirse; bir kullanıcı bankanın web sitesinde sadece kendi belgelerini görebilmelidir. Eğer başkasının belgelerine erişebiliyor ise buna IDOR denir. Buradaki object belgeler oluyor.
Direct Reference ise user ID'nin doğrudan değiştirilebilmesi oluyor.
Bu bilgileri birleştirirsek, IDOR web uygulamasında güvensiz kural setlerinden dolayı oluşan, saldırganların doğrudan objeleri değiştirerek erişmemeleri gereken dosyalara erişmeleridir.
Artık IDOR'un da ne olduğunu biliyoruz, o hâlde IDOR için önemli olan bilgilere geçelim.
HTTP Status Codes
IDOR test ederken HTTP status codeları önemli olsa da her zaman status codelarına göre hareket edilmez.
Farz edelim ki bir web uygulamasında 1337 ID'li bir kullanıcı olalım ve web sitesinin adres bilgisini getiren bir kısmı olsun. Bu adresi web site ID'ye göre getirsin; yani biz sadece 1337 ID'sine sahip kullanıcının adreslerini görmeliyiz. Ama bu ID'yi değiştirirsek ne olur?
Gördüğünüz üzere ID değeri değiştiği için HTTP status code'u bize 302 vermesine rağmen 1 ID'li kullanıcının bilgilerini hâlâ görebilmekteyiz. Bunun sebebi, bu web sitesini yapan yazılımcının HTTP status code'u değiştirip gelen adres görüntüleme isteğini sonlandırması gerekirken sadece status code'u değiştirmiş olmasıdır. Bu yüzden 1. kullanıcının adres bilgisini görebilmiş olduk.
Tabii aynı şekilde status code 200 dönüp başkasının adres bilgilerine erişim engellenmiş olabilir. Yani IDOR'a bakarken kesin olarak HTTP status codeları bize doğruyu söylemez.
IDOR için status codeların önemli olmasının bir diğer sebebi de status codelara bakarak web sitenin önce hangi bilgilere baktığını anlayabilmemizdir.
Yani eğer web sitede referans noktası olarak var olduğunu bildiğimiz bir şey verdiğimizde status code olarak 302 dönüyor, eğer referans olarak var olmayan bir referans noktası verdiğimizde 404 dönüyorsa, bu web site önce kullanıcı var mı yok mu diye bakıp ardından bu kullanıcının bu işlem için yetkili olup olmadığına bakıyor olabilir.
Modern Web Uygulamalarında IDOR
Günümüz web uygulamalarında IDOR en fazla bulunan zafiyetlerden bir tanesidir; çünkü web uygulamaları artık çok fazla özellik içermektedir. Bu da objenin çok fazla olması anlamına gelmektedir.
IDOR'un çok fazla bulunma sebeplerinden birisi de diğer saldırı türleri gibi belirli bir yapısının olmaması ve gönderilen zararlı isteklerin aslında websitenin özelliklerinden kaynaklanmasıdır bu yüzden kod analizlerinde IDOR un fark edilmesi zordur
Günümüz web uygulamalarında karışıklık olmaması ve veri tabanın da yoğunluk oluşmaması için mikroservisler kullanılır. Bu sayede, eğer bir servis kullanıcının adresine ihtiyacı varsa, o adrese direkt veritabanından erişmek yerine ilgili mikroservise gider ve ondan adresi alır.
Bu mimarinin dezavantajı, mikroservisin gelen isteklerin doğruluğuna nasıl karar verdiğidir. Eğer saldırgan, mikroservisleri çağırırsa mikroservis bunu nasıl kontrol ediyor?
Web uygulamaları bunu iki farklı şekilde ele alabilir. İlk yaklaşımda, mikroservis gelen isteği doğrudan kendisi değerlendirir; ancak burada asıl sorun, mikroservisin bu değerlendirmeyi arka planda gerçekten doğru ve tutarlı biçimde yapıp yapmadığıdır.
İkinci yaklaşımda ise bu kontrol, mikroservisin çağrıldığı katmanda gerçekleştirilir. Bu durumda da şu soru ortaya çıkar: Acaba bu kontrol, mikroservisi kullanan her noktada gerçekten uygulanıyor mu?
Ayrıca, günümüz web uygulamaları çok büyük olduğu için mikroservisi yazan ile o servisi çağıran yazılımcı farklı kişiler olabilir. Bu durumda, mikroservis istenildiği şekilde bir kontrol yapıyor mu?
Bu tür sorunlar doğru şekilde ele alınmadığında, IDOR zafiyetlerine yol açabilmektedir.
Ayrıca bu problemler yalnızca mikroservis mimarilerinde ortaya çıkmaz; farklı yazılımlar veya bileşenler arasındaki davranış ve uygulama farklarından da kaynaklanabilir.
Artık IDOR zafiyetinin günümüzde neden bu kadar yaygın olduğunu ve HTTP status code'ların neden kritik bir öneme sahip olduğunu öğrendiğimize göre, PortSwigger'ın IDOR labını çözmeye geçebiliriz.
Lab: Insecure direct object references
Labımız diyor ki, web uygulaması sohbet mesajlarını direkt olarak sunucuda tutuyormuş ve bunları URL aracılığı ile alıyormuş. Amacımız da Carlos'un şifresini öğrenmekmiş; o zaman Burp Suite'i açarak bu web siteye giriyorum.
Lab bundan bahsettiği için direkt web sitedeki live chat kısmına giriyorum ve burdaki özellikleri deniyorum.
Sayfadaki özellikleri kullandıktan sonra Burp Suite'teki HTTP History kısmına giriyorum ve arka planda nasıl HTTP istekleri gitmiş, onlara bakıyorum.
Fark ediyorum ki web site konuşmaları kaydediyor ve bu kaydettiği mesajları View Transcript'e bastığım zaman indiriyor.
HTTP isteği olarak da gördüğünüz gibi bir istek dönüyor. Fark ettiğiniz üzere object olarak download-transcript var ve doğrudan sayı alıyor. Web sitesinde eğer ID'si 2 olan bir .txt dosyası varsa, neden başka sayılar da olmasın diye düşünüyorum ve bunu test etmek için bu HTTP isteğini Repeater'e atıyorum. Bu sayede bu HTTP isteğini değiştirip tekrar göndererek sonuçları görebileceğim.
0.txt diye bir dosya yokmuş; ama bu, bizim başka .txt dosyalarını denememize engel değildir.
Bingo! Bu sefer gerçekten erişmememiz gereken bir dosyaya eriştik. Bu yazıyı okuduğumuz zaman görüyoruz ki bir şifre yazıyor. Bu şifreyi Carlos için deneyelim.
Ve şifre Carlos'unmuş, labı çözmüş olduk.
Buraya kadar okuduğunuz için teşekkür ederim, değerli saüsiber takipçileri. Bir başka yazıda görüşmek üzere.
Kaynakça:
Portswigger:
https://portswigger.net/web-security/access-control/idor
Web Security 101 0x02 | IDOR Insecure Direct Object Reference Zafiyetleri Hakkında Her şey: