IDOR (Insecure Direct Object References) Zafiyeti Nedir ve Nasıl Önlenir?
Selamlar ben Nisa bugün sizlerle IDOR zafiyetini öğreneceğiz ve IDOR zafiyeti ile ilgili Lablar’lar çözeceğiz
IDOR Zafiyeti Nedir?
Insecure Direct Object Reference (IDOR), saldırganların bir web uygulamasında URL’ler veya parametrelerde kullanılan tanımlayıcıları (identifier) manipüle ederek nesnelere yetkisiz şekilde erişebilmesi veya bu nesneleri değiştirebilmesi sonucu ortaya çıkan bir güvenlik açığıdır. Bu zafiyet, uygulamanın belirli verilere erişim için gerekli yetki kontrollerini düzgün şekilde yapmamasından kaynaklanır.
Size IDOR ile ilgili birkaç örnek göstermek isterim.
URL Parametresi ile Başka Kullanıcının Profiline Erişim
Kullanıcı Girişi:
GET /profile?user_id=123
Saldırganın yaptığı değişiklik:
GET /profile?user_id=124
Sonuç:
Uygulama yetki kontrolü yapmadığı durumda saldırgan diğer kullanıcıların profillerini görüntüleyebilir.
API Üzerinden Yetkisiz Veri Okuma
API İsteği:
GET /api/orders/456
Saldırganın Yaptığı Değişiklik:
GET /api/orders/457
Sonuç:
Saldırgan başkasına ait verileri görebilir.
POST Body Üzerinden Profil Güncelleme (Gizli Alan Manipülasyonu)
Kullanıcı Profili:
<input type=”hidden” name=”user_id” value=”1000″>
Saldırganın Değişikliği:<input type=”hidden” name=”user_id” value=”1002″>
Belge Erişimi (Dosya IDOR)
Kullanıcı İsteği:
GET /invoice/download?id=9001
Saldırganın İsteği:
GET /invoice/download?id=9002
Sonuç:
Kullanıcıya ait belgeler indirilebiliyor.
IDOR ile Şifre Sızıntısı
GET /api/user/details?user_id=321
Sonuç:
API cevabından passwrd_hash, reset_token vb. gibi cevap geliyorsa;
Hesap ele geçirilebilir.
IDOR Zafiyeti İle İlgili Lab Çözümleri
Lab çözerken Burp Suite Community uygulamasını kullanacağız.
- Burp Suite Community uygulamasından Proxy → HTTP History geliyoruz ve hedef üstünde yaptığımız tüm işlemlerin arşivleri burada gözüküyor.
Hedefimize bağlandıktan sonra ilk olarak Live Chat kısmına geliyoruz ve rastgele bir mesaj yazıp sisteme yolluyoruz sonrasında ise View transcript diyoruz.
Burp Suite’te /download-tarnscrip/2.txt request’e geliyor.
Sonrasında Send to Repeater diyoruz.
Ardından GET /download-transcript/2.txt kısmını /download-transcript/1.txt olarak değiştiriyor ve ardından Send diyoruz.
Response’ta my password is 7rxuiapohfsu85xcft89 diyor ve bu Carlos’un şifresi ardından. LAb’a geri dönüyor ve My Account’a geliyoruz.
Son olarak
Username: Carlos
Password: 7rxuiapohfsu85xcft89
Carlos’un hesabına giriş yapıyor ve başarıyla bitiriyoruz.
Burp Suit açık bir şekilde Lab’a geçiş yapıyoruz.
Bize açıklamada verilen wiener:peter ile giriş yapıyoruz.
Hesaba giriş yaptıktan sonra Burp Suit geçmişinden.
Get /my-account?id=wiener request’e geliyor.
Sonrasında Send to Repeater diyoruz.
GET /my-account?id=wiener kısmını
GET /my-account?id=carlos olarak değiştiriyoruz ve ardından Send diyoruz.
Çıktı olarak ise bize API Key veriyor onu kopyalıyoruz ve hedef sitedeki Submit solution kısmına yapıştıryoruz.
İkinci Lab’ımızı da başarıyla çözdük.
Lab-3
Kullandığım Lab Neighbour
İlk olarak Burp Suit ile hedef siteye keşfe çıkıyoruz.
Bizi bir Login sayfası karşılıyor. Alt kısımda ise Don’t have an account? Use the guest account (CTRL+U) ile bizi sayfa kaynak koduna yönlendiriyor.
Kaynak kodunda ise bize login olabilceğimiz guest:guest ile bilgisi veriliyor sıra login olup Burp Suit’ten arşive bakmak kalıyor.
Burp Suit’te ise GET /profil.php?user=guest request’e geliyor.
Ordan sonra Send to Repeater diyoruz.
Burda ise GET /profile.php?user=guest’i GET /profile.php?user=admin olarak değiştiriyoruz. Ardından Send diyoruz.
Bize flag çıktısı veriliyor artık sadece flag kontrolü kalıyor flag’i kopyalıyoruz ve Try Hack Me ‘de flag kısmına yapıştırıyoruz.
Üçüncü Lab’mızı da başarıyla bitiriyoruz.
Lab-4
Kullandığım Lab Corridor
Bu Lab diğer lablardan biraz farklı bu labda Burp Suit kullanmayacağız. Şimdi ise hedef sisteme gidiyoruz.
Bizi böyle bir sayfa karşılıyor ve burda CTRL+U yaparak sayfa kaynak kodlarına bakıcaz.
Kaynak kodlarında ise bizi bazı hashler karşılıyor. Bu hashleri CrackStation kullanarak hangi Encoding olduğuna bakacağız.
Burada type kısmına bakacağız bize md5 olarak vermiş. Sonraki adımımız ise CyberChef‘den 0 md5 çevrildiğinde çıkan hash’i kullanacağız.
Burada sıfır kullanmamızın nedeni ise web/app tarafında diziler (array’ler) 1’den değil 0’dan başlar.
Burada cfcd208495d565ef66e7dff9f98764da çıktısını alıyoruz. Bu çıktıyı kopyalıyoruz.
Sitenin URL’sine http://10.48.179.189/cfcd208495d565ef66e7dff9f98764da yapıştıryoruz bu URL bize flag’i verecektir.
Başarılı bir şekilde flag’e ulaştık sadece bunu kontrol etmek kaldı ve hemen lab’ın sayfasına gidip deniyoruz.
Ve Lab başarılı bir şekilde sonuçlandı.
IDOR Zafiyeti Nasıl Önlenir
IDOR zafiyetini önlemek için, kullanıcıların erişmeye çalıştığı her nesne için yetki kontrolü uygulanmalıdır. Çoğu web framework’ü bu kontrolleri kolaylaştıran mekanizmalar sunar. Ayrıca karmaşık tanımlayıcılar, ek bir güvenlik katmanı (defense-in-depth) olarak kullanılabilir; ancak unutulmamalıdır ki, asıl kritik olan erişim kontrolüdür.
Tanımlayıcıları URL’de veya POST gövdelerinde açık bir şekilde göstermemeye çalışın. Tanımlayıcılar yerine session (oturum) kullanarak o an kimliği doğrulanmamış kullanıcıyı belirleyin.
Artan sayısal tanımlayıcalar yerine (enumerable) daha karışık ve rastgele tanımlayıcalar kullanılmalı. Ek olarak UUID veya benzeri uzun ve rastgele değerler birincil anahtar olarak tercih edilebilir. Tanımlayıcıları şifrelemekten kaçınılmalıdır, çünkü bunu güvenli bir şekilde yapmak oldukça zordur.
.
IDOR(Insecure Direct Object References) Özet Bilgi
Insecure Direct Object Reference (IDOR), bir web uygulamasının nesnelere erişim sırasında yeterli yetkilendirme (authorization) kontrollerini uygulamaması sonucunda ortaya çıkan kritik bir erişim kontrolü zafiyetidir. Bu zafiyet, genellikle URL parametreleri, form verileri veya API isteklerinde kullanılan doğrudan nesne tanımlayıcılarının (örneğin kullanıcı ID’si, dosya ID’si, sipariş numarası) manipüle edilebilmesiyle istismar edilir.
IDOR zafiyetine sahip uygulamalarda, kimliği doğrulanmış bir kullanıcı, kendisine ait olmayan kaynaklara erişebilir, bu kaynakları görüntüleyebilir, değiştirebilir veya silebilir. Bu durum; kişisel verilerin ifşası, yetkisiz işlem gerçekleştirme ve hesap ele geçirme gibi ciddi güvenlik ihlallerine yol açabilir.
Bu zafiyetin önlenmesi için, nesneye erişim yapılan her istekte sunucu taraflı yetkilendirme kontrollerinin zorunlu olarak uygulanması gerekmektedir. Uygulama, yalnızca kullanıcının kimliğini doğrulamakla yetinmemeli, aynı zamanda ilgili kaynağa erişim yetkisine sahip olup olmadığını da doğrulamalıdır. Ek olarak, tahmin edilebilir ardışık tanımlayıcılar yerine rastgeleleştirilmiş veya UUID tabanlı tanımlayıcıların kullanılması, savunmayı güçlendiren tamamlayıcı bir önlem olarak değerlendirilebilir. Ancak bu yaklaşım, hiçbir zaman erişim kontrolünün yerine geçmemelidir.
