October 22, 2026
Bir Hacker Gibi Düşünmek — #17
IDOR Nedir? Bir URL’deki Sayıyı Değiştirmek Nasıl Yetkisiz Erişime Yol Açabilir?
By Abdulkadir Kayacan
6 min read
IDOR Nedir? Bir URL'deki Sayıyı Değiştirmek Nasıl Yetkisiz Erişime Yol Açabilir?
Bir web sitesine giriş yaptığını ve profil sayfana ulaştığını düşün. Adres çubuğunda şöyle bir URL görüyorsun:
https://example.com/account/1042https://example.com/account/1042Buradaki 1042 sayısı, hesabına ait bir kaydı temsil ediyor olabilir. Peki bu sayıyı 1043 olarak değiştirdiğinde başka bir kullanıcının hesabına ait bilgiler açılırsa ne olur?
Belki uygulamanın tasarımında yalnızca kendi hesabına erişebilmen gerekiyordu. Ancak sunucu, istediğin kaydın sana ait olup olmadığını kontrol etmiyorsa başka bir kullanıcının bilgilerine erişebilirsin.
İşte bu durum, web güvenliğinde sık karşılaşılan zafiyetlerden biri olan IDOR (Insecure Direct Object Reference) kavramıyla ilişkilidir. Türkçeye Güvensiz Doğrudan Nesne Referansı olarak çevrilebilir.
IDOR, bir kullanıcının erişmemesi gereken bir nesneye, uygulamanın yetersiz yetkilendirme kontrolleri nedeniyle erişebilmesidir. Bu nesne bir profil, fatura, özel mesaj, belge, sipariş veya başka bir kullanıcıya ait herhangi bir kayıt olabilir.
Bu yazıda IDOR'un nasıl ortaya çıktığını, kimlik doğrulama ile yetkilendirme arasındaki farkı, saldırganların bu tür hataları nasıl araştırdığını ve geliştiricilerin bunları nasıl önleyebileceğini inceleyeceğiz.
Önce üç kavramı birbirinden ayıralım
IDOR'u anlayabilmek için üç temel kavramı bilmek gerekir: Kimlik, kimlik doğrulama ve yetkilendirme.
Kimlik (Identity), uygulamanın hangi kullanıcıdan söz ettiğini belirler. Örneğin kullanıcı adı, kullanıcı kimliği veya hesabı temsil eden başka bir tanımlayıcı bu amaçla kullanılabilir.
Kimlik doğrulama (Authentication), kullanıcının iddia ettiği kişi olduğunu doğrulama sürecidir. Kullanıcı adı ve parola ile giriş yapmak veya çok faktörlü kimlik doğrulama kullanmak buna örnektir.
Yetkilendirme (Authorization) ise doğrulanmış kullanıcının hangi kaynaklara erişebileceğini ve hangi işlemleri gerçekleştirebileceğini belirler.
Bu ayrım son derece önemlidir. Bir kullanıcının sisteme başarıyla giriş yapmış olması, uygulamadaki bütün kayıtlara erişebileceği anlamına gelmez.
Örneğin bir alışveriş sitesinde giriş yapmış olabilirsin. Bu, kendi siparişlerini görüntüleme yetkisine sahip olduğun anlamına gelebilir. Ancak aynı siteye kayıtlı diğer müşterilerin siparişlerini görüntüleme yetkisine sahip olduğun anlamına gelmez.
IDOR, çoğu zaman kimlik doğrulamanın çalıştığı ancak nesne düzeyindeki yetkilendirmenin eksik veya hatalı olduğu durumlarda ortaya çıkar.
IDOR tam olarak nasıl çalışır?
Bir web uygulamasında kullanıcıların kişisel bilgilerine erişebildiği bir profil sayfası olduğunu düşünelim. Kullanıcı giriş yaptıktan sonra şu URL üzerinden kendi bilgilerini görüntülüyor:
https://example.com/profile?id=1001https://example.com/profile?id=1001Buradaki id=1001 değeri, görüntülenecek profilin kimliğini belirtiyor olabilir. Kullanıcı URL'deki bu değeri 1002 olarak değiştirdiğinde başka bir kişinin profil bilgilerini görebiliyorsa ve uygulama bu erişimi engellemiyorsa, ortada bir IDOR zafiyeti bulunabilir.
Sorunun kaynağı, kimlik numarasının tahmin edilebilir olması değil, sunucunun kullanıcının ilgili kaynağa erişme yetkisi olup olmadığını doğru şekilde kontrol etmemesidir. Çünkü bir kullanıcının sisteme giriş yapmış olması, diğer kullanıcıların verilerine erişebileceği anlamına gelmez.
Üstelik IDOR yalnızca URL'deki sayıları değiştirmekle sınırlı değildir. Aynı sorun, bir API isteğinin gövdesindeki kimlik değerinde, bir dosyanın adresinde veya bir sipariş numarasında da ortaya çıkabilir. Örneğin bir e-ticaret sitesinde kullanıcı kendi siparişini görüntüleyebilirken başka bir sipariş numarası göndererek başka bir müşterinin sipariş ayrıntılarına erişebiliyorsa, uygulama nesne düzeyinde yetkilendirme kontrolünü doğru uygulamıyor demektir.
Güvenli bir uygulama, her istekte kullanıcının kim olduğunu belirlemekle yetinmez; erişilmek istenen kaynağa erişme yetkisini de sunucu tarafında doğrular. Böylece kimlik değeri değiştirilse bile yetkisiz erişim engellenir.
IDOR yalnızca URL'deki sayıyı değiştirmek değildir
IDOR örneklerinde genellikle URL içindeki sayının değiştirilmesinden söz edilir. Bunun nedeni, bazı uygulamaların veritabanındaki kayıtları doğrudan sayısal kimliklerle göstermesidir.
Ancak nesne kimlikleri farklı yerlerde bulunabilir. Örneğin:
- URL'nin yol bölümünde:
/users/1042 - Sorgu parametresinde:
?invoice_id=5001 - JSON istek gövdesinde:
"document_id": 27 - Bir API isteğinin başlıklarında veya başka parametrelerinde
Örneğin bir uygulama, kullanıcının kendi profil bilgilerini güncellemek için şu tür bir istek kullanabilir:
PUT /api/profile/1042 HTTP/1.1
Host: example.com
Content-Type: application/jsonPUT /api/profile/1042 HTTP/1.1
Host: example.com
Content-Type: application/jsonİstek gövdesinde de değiştirilecek bilgiler bulunabilir. Uygulama yalnızca kullanıcının giriş yapmış olmasını kontrol ediyor, ancak 1042 numaralı profilin o kullanıcıya ait olup olmadığını denetlemiyorsa başka profiller üzerinde yetkisiz işlem yapılması riski doğabilir.
Benzer durumlar yalnızca verileri görüntüleme sırasında değil, değiştirme ve silme işlemlerinde de ortaya çıkabilir.
Bu nedenle bir güvenlik araştırmacısı sadece tarayıcıdaki adres çubuğuna bakmaz. Uygulamanın API isteklerini, hangi nesne kimliklerinin kullanıldığını ve sunucunun erişim kararlarını nasıl verdiğini de inceler.
IDOR'un etkisi ne kadar ciddi olabilir?
IDOR'un etkisi, erişilebilen nesnenin türüne ve uygulamanın izin verdiği işlemlere bağlıdır.
Bir kullanıcı başka bir kullanıcının herkese açık profilini görebiliyorsa bu bir yetkilendirme problemi olmayabilir. Ancak aynı yöntemle özel mesajlara, kişisel belgelere, faturalara veya hesap bilgilerine erişilebiliyorsa ciddi bir veri gizliliği ihlali ortaya çıkabilir.
Bazı durumlarda yalnızca okuma işlemleri etkilenir. Kullanıcı, kendisine ait olmayan bir kaydı görüntüleyebilir. Başka durumlarda kayıtların değiştirilmesi veya silinmesi de mümkün olabilir. Bu tür durumlar, nesne düzeyinde yetkilendirme kontrollerinin hem okuma hem de yazma işlemlerinde uygulanması gerektiğini gösterir.
Örneğin bir kullanıcı, başka bir müşterinin siparişini görüntüleyememeli; aynı şekilde o siparişi iptal edememeli veya teslimat adresini değiştirememelidir.
Bu nedenle IDOR, yalnızca bir URL manipülasyonu tekniği olarak düşünülmemelidir. Asıl mesele, uygulamanın her nesne üzerinde hangi kullanıcının hangi işlemleri yapabileceğini doğru belirleyip belirlemediğidir.
IDOR ile Broken Access Control arasındaki ilişki
OWASP, Broken Access Control kavramını, uygulamanın kullanıcıların izin verilen sınırların dışındaki işlemleri gerçekleştirmesini engelleyememesiyle ilişkili geniş bir güvenlik kategorisi olarak ele alır.
IDOR, bu geniş kategorinin yaygın örneklerinden biridir.
Başka bir ifadeyle, her IDOR vakası bir erişim kontrolü problemidir; ancak her erişim kontrolü problemi IDOR değildir. Örneğin yalnızca yöneticilere açık bir sayfaya normal kullanıcıların erişebilmesi de Broken Access Control kapsamına girebilir, fakat bu durum mutlaka bir nesne referansının kötüye kullanılmasını gerektirmez.
Bu ayrım, güvenlik raporları hazırlarken önemlidir. Bir bulguyu doğru adlandırmak, sorunun nerede olduğunu anlamayı ve uygun çözümü belirlemeyi kolaylaştırır.
Geliştiriciler IDOR'u nasıl önleyebilir?
IDOR'a karşı temel savunma, sunucu tarafında her nesneye erişim sırasında yetkilendirme kontrolü yapmaktır.
Örneğin kullanıcı bir faturayı görüntülemek istediğinde uygulama yalnızca faturanın var olup olmadığını kontrol etmemelidir. Aynı zamanda bu faturanın o kullanıcıya ait olup olmadığını veya kullanıcının başka bir nedenle bu faturaya erişim yetkisi bulunup bulunmadığını da doğrulamalıdır.
Bu kontrol istemci tarafında bırakılmamalıdır. Bir web sayfasında başka kullanıcıların kayıtlarına ait bağlantıları gizlemek faydalı olabilir, ancak bu tek başına güvenlik sağlamaz. Kullanıcı doğrudan API isteği göndererek gizlenen bağlantıya ulaşmayı deneyebilir. Son kararı sunucu vermelidir.
Bir başka önemli yaklaşım, veritabanı sorgularını kullanıcının erişim kapsamına göre tasarlamaktır. Örneğin uygulama bir faturayı yalnızca kimliği üzerinden aramak yerine, faturanın kimliğini ve kullanıcının sahiplik bilgisini birlikte dikkate alabilir. Böylece sorgu yalnızca istenen kaydı bulmakla kalmaz, erişim sınırını da uygular.
Ancak sahiplik her zaman tek yetkilendirme kuralı değildir. Bir şirket uygulamasında yöneticiler, ekip üyeleri veya belirli rollere sahip çalışanlar başka kişilerin kayıtlarına erişmek zorunda olabilir. Böyle durumlarda uygulama, iş kurallarına göre açıkça tanımlanmış bir yetkilendirme modeli kullanmalıdır.
Rastgele ve tahmin edilmesi zor kimlikler kullanmak da ek bir koruma katmanı sağlayabilir. UUID gibi tanımlayıcılar, kayıtların sırayla tahmin edilmesini zorlaştırabilir. Fakat bunlar yetkilendirme kontrolünün yerini tutmaz. Bir kayıt kimliğinin gizli kalacağı varsayımına dayanmak güvenli değildir.
Son olarak uygulama, nesne erişimlerini farklı kullanıcı rolleriyle test etmelidir. Bir kullanıcının kendi kaydına erişebilmesi, başka bir kullanıcının kaydına erişememesi ve yetkili bir rolün yalnızca izin verilen işlemleri yapabilmesi doğrulanmalıdır.
Güvenli bir laboratuvarda IDOR nasıl incelenir?
IDOR'u anlamanın en iyi yollarından biri, iki test hesabı bulunan bir laboratuvar oluşturmaktır. Birinci hesapla oluşturulan bir kaydın, ikinci hesap tarafından görüntülenip görüntülenemediği kontrol edilebilir.
Örneğin kendi test uygulamanda iki kullanıcı oluşturduğunu düşün. İlk kullanıcı bir belge yükler ve belgeye ait kayıt kimliğini alır. İkinci kullanıcı da uygulamaya giriş yapar ve aynı belgeyi görüntülemeyi dener.
Güvenli tasarlanmış uygulama, ikinci kullanıcının erişim yetkisi yoksa isteği reddetmelidir. Bunu yaparken 403 Forbidden veya bazı durumlarda kaydın varlığını açığa çıkarmamak için 404 Not Found döndürebilir. Hangi yanıtın seçileceği uygulamanın tasarımına bağlıdır; önemli olan yetkisiz erişimin engellenmesidir.
Test sırasında yalnızca yanıt kodunu değil, yanıt gövdesini ve uygulamanın yaptığı işlemleri de kontrol etmek gerekir. Örneğin sunucu 403 döndürse bile hassas bilgileri yanıtın başka bir bölümünde gönderiyorsa güvenlik problemi devam eder.
PortSwigger Web Security Academy, erişim kontrolü ve IDOR konularında uygulamalı laboratuvarlar sunar. Bu eğitimler, farklı kullanıcı rolleri arasında yetkilendirme sınırlarının nasıl test edileceğini öğrenmek için yararlıdır. Gerçek sistemlerde ise yalnızca açıkça izin verilmiş testler yapılmalıdır.
Sonuç: Giriş yapmış olmak, her şeye erişebilmek değildir
IDOR, web güvenliğinde sık karşılaşılan ama temelinde oldukça basit bir soruna dayanan zafiyetlerden biridir: Uygulama, kullanıcının istediği nesneye erişme hakkı olup olmadığını doğru kontrol etmez.
Bir URL'deki sayıyı değiştirmek bazen bu sorunu ortaya çıkarmaya yardımcı olabilir. Ancak asıl zafiyet sayının tahmin edilebilir olması değil, sunucunun yetkilendirme kararını doğru vermemesidir.
Bir hacker gibi düşünmek, yalnızca hangi kayıt kimliklerinin kullanılabileceğini araştırmak değildir. Uygulamanın her istekte kimin hangi veriye erişebileceğini nasıl belirlediğini anlamak ve bu sınırların gerçekten sunucu tarafında korunduğunu doğrulamaktır.