IDOR (Insecure Direct Object Reference) Nedir?
Siber Güvenlik

IDOR (Insecure Direct Object Reference) Nedir?

AUTH: Esad Özkan
DATE: 27 Ağustos 2025
Paylaş

1. Giriş

IDOR nedir?

Türkçe de “Güvensiz Doğrudan Nesne Referansı” olan web uygulamalarında görülen bir yetki kontrol zafiyetidir. Bu zafiyet, uygulamanın bir nesneye (örneğin bir kullanıcı kaydı, dosya veya veri satırı) ilişkin referansı doğrudan kullanıcı girişine dayalı olarak işlemesi, sonucunda ortaya çıkar. Bu durumun temel nedeni, uygulamanın ilgili nesneye erişmeden önce uygun yetki doğrulaması yapmamasıdır

 

Neden tehlikelidir?

 IDOR son derece tehlikeli bir zafiyettir çünkü çok basit değişikliklerle kritik verilere yetkisiz erişim sağlanmasına yol açabilir. Örneğin, bir kullanıcının profilini gösteren URL’de user=123 gibi bir parametre varsa, bu değeri 124 ile değiştirmek başka bir kullanıcının profiline erişilmesine neden oluyorsa uygulama IDOR zafiyetine sahiptir. Sonuçta, saldırganlar başkasına ait kişisel bilgilere, finansal verilere veya hassas belgelere izinsiz şekilde ulaşabilir. Hatta bazı durumlarda IDOR, hesap ele geçirme veya yetkisiz işlemler yapma (ör. başka bir kullanıcının adına işlem gerçekleştirme) gibi ciddi sonuçlar doğurabilir. Bu tip açıklar genellikle veri ihlallerine, gizlilik ihlallerine ve kurumsal itibar kaybına yol açabilecek kadar ciddidir.

OWASP Top 10’daki Yeri ve Önemi

IDOR, yıllardır OWASP Top 10 listelerinde önemli bir yer tutmaktadır. 2013 listesinde “Insecure Direct Object References” başlığıyla yer almış ve geliştiricilerin dikkatini çekmiştir. Güncel OWASP Top 10 listelerinde ise IDOR, daha geniş bir kategori olan Broken Access Control (Kırık Erişim Kontrolü) kapsamında değerlendirilmektedir. Broken Access Control, 2021 OWASP Top 10'da birinci sırada yer almış ve en kritik web güvenlik risk kategorisi olarak tanımlanmıştır.  Verilere göre, Broken Access Control ile ilişkili zafiyetler (IDOR da dahil) incelenen uygulamaların %3,81’inde tespit edilmiş ve bu kategoride diğer tüm kategorilerden daha fazla güvenlik açığı oluşumuna rastlanmıştır. Bu da IDOR’un ne kadar yaygın ve ciddi bir sorun olduğunun altını çizmektedir. Özetle, IDOR geçmişten günümüze web uygulama güvenliğinde üst sıralarda yer alan, göz ardı edilmemesi gereken bir zafiyettir.

2. Temel Kavramlar

Yetkilendirme ve Kimlik Doğrulama

IDOR ve benzeri zafiyetleri anlamak için öncelikle kimlik doğrulama ve yetkilendirme kavramlarının farkını bilmek gerekiyor. Kimlik doğrulama (authentication), bir kullanıcının veya sistem bileşeninin iddia ettiği kişi olduğunu kanıtlama işlemidir – örneğin kullanıcı adı ve şifre girerek sisteme giriş yapmak bir kimlik doğrulama adımıdır. Yetkilendirme (authorization) ise kimliği doğrulanmış bir kullanıcının hangi kaynaklara veya işlevlere erişme izni olduğunun kontrol edilmesidir. Başka bir söylemle, kimlik doğrulama "Kimsin?" sorusunu cevaplarken, yetkilendirme "Ne yapmana izin var?" sorusunu cevaplar. Örneğin, bir web sitesine giriş yaptığınızda kimlik doğrulama gerçekleşir; başarılı girişten sonra sitenin sizin hangi sayfaları görebileceğinizi veya hangi işlemleri yapabileceğinizi kontrol etmesi ise yetkilendirmedir. IDOR, işte bu yetkilendirme adımındaki eksiklikten faydalanır: Uygulama kimlik doğrulaması yapılmış bir kullanıcının talep ettiği nesneye gerçekten yetkisi olup olmadığını kontrol etmezse, saldırganlar sadece kimlik doğrulamasını geçmiş olmanın verdiği yetkiyle aslında erişmemeleri gereken verilere ulaşabilirler. Bu nedenle, kimlik doğrulama güvenli olsa bile yetkilendirme kontrollerinin zayıf olması IDOR gibi açıkların ortaya çıkmasına neden olur.

Doğrudan nesne referansı nedir? Doğrudan nesne referansı, bir uygulamanın dahili bir nesneyi (veritabanındaki bir kayıt, dosya yolu, kullanıcı ID’si vb.) temsil eden tanımlayıcıyı (ID veya başka bir referans değeri) doğrudan kullanıcıya sunması veya kullanıcıdan alması durumudur. Örneğin, bir banka web uygulamasında hesap görüntüleme isteği GET /account?acc_id=63 şeklinde bir hesap numarası içeriyorsa, bu numara uygulamanın dahili olarak hesap kaydını bulmak için kullandığı doğrudan bir referanstır. Doğrudan nesne referansı tek başına bir güvenlik açığı değildir; ancak sorun, bu referansın kullanımı sırasında uygun erişim kontrolü olmamasından kaynaklanır. Uygulama, acc_id=18 isteyen kullanıcının gerçekten o hesap üzerindeki verilere erişim izni var mı diye kontrol etmeden yanıt dönerse, bu referans "güvensiz" hale gelir. Saldırgan, URL veya istek içindeki böyle bir referansı fark edip değiştirdiğinde, uygulama yine de isteği işliyor ve farklı bir nesnenin verisini döndürüyorsa IDOR zafiyeti oluşmuş demektir. Kısaca, doğrudan nesne referansı var olan bir iç nesneye kullanıcı tarafından bilinebilen bir yolla atıfta bulunulması demektir; IDOR ise bu referansın arkasında bir yetki doğrulaması olmamasıdır.

IDOR Nasıl Ortaya Çıkıyor

 IDOR’un ortaya çıkış sebebi, eksik veya hatalı erişim kontrolüdür. Bir uygulama, kullanıcının isteğindeki bir kimliği alıp doğrudan nesneye erişmek için kullandığında her seferinde “Bu kullanıcı bu nesneyi görmeye yetkili mi?” diye sormuyorsa, IDOR riski baş gösterir. Örneğin, bir e-ticaret uygulamasında GET /orders/1001 isteği, 1001 numaralı siparişin detaylarını dönüyorsa, uygulamanın bu isteği yapan kullanıcının gerçekten 1001 numaralı siparişin sahibi olup olmadığını kontrol etmesi gerekir. Kontrol edilmediği durumda saldırgan kendi sipariş numarası yerine rasgele bir sayı (ör. 1002, 1003 ...) deneyerek başkalarının sipariş bilgilerini görüntüleyebilir. Uygulamanın bu şekilde kullanıcı tarafından sağlanan bir nesne referansını doğrudan kullanıp, nesne sahibini doğrulamaması IDOR açığının özüdür.

Özetle, IDOR oluşumu şu şekildedir;

        ·        Uygulama, bir nesneye ait ID gibi referansı istemciden alır veya istemciye gösterir

        ·        Kullanıcı bu referansı manipüle eder (değiştirir),

        ·        Uygulama referansı kullanarak nesneye erişir fakat kimin eriştiğini kontrol etmez. Bu sayede saldırgan, kendi yetkisi dışındaki nesnelere doğrudan erişim sağlamış olur.

3. IDOR Türleri

IDOR zafiyetleri, uygulamanın veri iletim yöntemine ve mimarisine bağlı olarak farklı şekillerde karşımıza çıkabilir. Temelde hepsi aynı problemi (yetki kontrol eksikliğini) paylaşsa da, görünümleri farklı türlerde olabilir. Aşağıda yaygın IDOR türlerini göreceğiz:

  • URL Tabanlı IDOR: Uygulama nesne referanslarını URL yolunda taşıyorsa oluşur. Örneğin, bir sosyal medya sitesinde profil sayfası URL’si /user/42 şeklindeyse, burada 42 doğrudan veri tabanında kullanıcı ID’sini temsil ediyor olabilir. Eğer uygulama, URL’deki sayıyı değiştirip /user/43 yapıldığında kontrolsüz biçimde ID=43 kullanıcısının profilini gösteriyorsa IDOR mevcuttur. Gerçekte kullanıcı 43 numaralı profile yetkili olmayabilir fakat uygulama bu değişikliği fark etmez. OWASP’ ın bir örneğinde, https://example.org/users/123 URL’ine sahip bir profil sayfasında 123 kendi kullanıcı ID’sini gösterirken, saldırganın bunu 124 yaparak başka bir kullanıcının bilgilerini görüntüleyebilmesi tam da bu durumu anlatmaktadır. URL tabanlı IDOR’lar, GET isteğiyle doğrudan gözlemlenebildikleri için oldukça sık rastlanır ve saldırganlar açısından keşfedilmeleri kolaydır. Özellikle ardışık sayısal ID kullanan API veya sayfa yolları, saldırganların basit tahminlerle veya script denemeleriyle başkalarının verilerine ulaşmasına imkan verebilir. Bu nedenle, URL içinde yer alan her türlü kimlik değerinin arka planda sağlam bir yetki doğrulamasından geçmesi kritiktir.
  • Form Verisi Tabanlı IDOR: Uygulamalar bazen kullanıcıyla ilgili ID gibi değerleri URL yerine form içinde gizli alanlarla (hidden field) gönderir. Bu durumda da benzer riskler vardır. Örneğin, bir profil güncelleme formunda şöyle bir gizli alan olduğunu düşünelim: <input type="hidden" name="user_id" value="12345">. Bu form normalde kullanıcı 12345’e ait profil bilgisini güncellemek içindir. Ancak saldırgan tarayıcı konsolundan veya bir proxy aracılığıyla bu değeri 12346 yapıp formu gönderdiğinde, sunucu tarafında herhangi bir kontrol yoksa başka bir kullanıcının profilini değiştirebilir. Bu bir form tabanlı IDOR örneğidir. Genellikle POST istekleri içinde gönderilen ID değerlerinin manipüle edilmesi şeklinde karşımıza çıkar. Saldırgan, kendi hesabına ait bir işlemi gerçekleştiren formu yakalayıp ilgili ID’yi değiştirerek isteği tekrar gönderir. Eğer uygulama sunucusu bu POST verisindeki ID’nin gerçekten oturumdaki kullanıcıya ait olup olmadığını kontrol etmiyorsa, yetkisiz değişikliklere kapı aralanır. Bu tür IDOR’lar URL tabanlı olanlar kadar görünür olmayabilir (çünkü ID değeri kullanıcıya doğrudan gösterilmez, isteğin gövdesindedir), ancak web uygulama proxy araçları (Burp Suite gibi) kullanılarak kolayca tespit edilebilir.
  • API Endpoint’lerinde IDOR: Modern web uygulamalarının büyük kısmı RESTful veya GraphQL gibi API çağrıları kullanır. API’lerde de IDOR zafiyeti aynı prensiple oluşur: İstemci tarafında gönderilen bir nesne ID’sinin, sunucu tarafında erişim kontrolü olmadan kullanılmasıdır. Örneğin bir REST API çağrısı düşünelim: GET /api/orders?order_id=500. Bu çağrı kullanıcıya ait 500 numaralı siparişin detaylarını döndürüyor olsun. Eğer saldırgan sorgu parametresini order_id=501 yapıp başka birinin siparişini alabiliyorsa IDOR vardır. API’lerde bu duruma özel bir ad da verilir: BOLA (Broken Object Level Authorization), yani Nesne Seviyesi Yetkilendirme Açığı olarak geçer. OWASP API Security Top 10’da da 1. sırada yer alan bu kategori, temelde IDOR ile aynıdır. API’lerde sık görülmesinin nedeni, sunucuların çoğunlukla istemciden gelen ID değerlerine güvenip, kullanıcının oturum bilgisini o nesneyle eşleştirme kontrolünü atlamalarıdır. İstek gövdelerinde JSON olarak gönderilen veriler de benzer risk taşır.

 Örneğin bir JSON API örneğinde:

POST /api/v2/user-data

{

  "user_id": 42,

  "email": "yeniadres@example.com"

}

Bu isteğin, ID’si 42 olan kullanıcının e-posta adresini güncellediğini varsayalım. Saldırgan user_id değerini farklı bir kullanıcıya ait ID ile değiştirip gönderirse ve uygulama bu güncellemeye izin verirse API seviyesinde bir IDOR gerçekleşmiş olur. Özetle, web servisleri ve API uç noktaları, ID değerlerini hem URL yolunda hem de query parametresi veya JSON/XML gövdesinde taşıyabildiklerinden, kapsamlı yetki kontrolleri olmadıkça IDOR’a karşı savunmasız olabilirler.

  • Mobil Uygulamalardaki IDOR Örnekleri: Mobil uygulamalar genellikle arka planda API’leri kullanarak sunucu ile haberleşir. Bu yüzden mobil uygulamalarda da IDOR zafiyetleri ortaya çıkabilir. Hatta bazen mobil uygulama istemcileri güvenlik kontrolünü istemci tarafında yaptıklarını varsayarak sunucu tarafında eksik bırakabilir, bu da saldırganların mobil uygulamanın ağ trafiğini değiştirerek IDOR’u istismar etmesine olanak tanır. Gerçek dünyadan bir örnek olarak, Avustralya’da bir GPS çocuk takip saati uygulamasında ortaya çıkan ciddi bir IDOR açığı verilebilir. Bu vakada saldırgan herhangi bir hesapla API’lere istek atıp, isteklerdeki device_id parametresini farklı değerlerle değiştirerek diğer tüm kullanıcıların cihaz verilerine erişebilmiştir. Uygulama, bu ID’nin o kullanıcıya ait olup olmadığını kontrol etmediği için saldırgan, diğer çocukların konum bilgilerini, hesap detaylarını görmüş; hatta cihazın özelliklerini (konum tespiti, arama yapma gibi) kötüye kullanabilmiştir. Benzer şekilde, popüler bir sosyal medya uygulamasının (TikTok) mobil versiyonunda keşfedilen bir IDOR, kullanıcının kendi paylaşımları için gizlilik ayarlarını değiştirdiği bir API çağrısında, ID değeri değiştirilerek başkasının paylaşımlarının gizlilik ayarlarının değiştirilebilmesine yol açmıştır (HackerOne raporları bu tür örneklerle doludur, merak ederseniz göz atabilirsiniz.). Bu örnekler, mobil uygulamaların da web API’leri aracılığıyla aynı risklere sahip olduğunu gösteriyor. Sonuç olarak, bir mobil uygulamada eğer arka plandaki API çağrıları nesne ID’lerine göre çalışıyor ve sunucu tarafında kullanıcı doğrulaması yapılmıyorsa, uygulama platformdan bağımsız şekilde IDOR açıklarına karşı savunmasızdır.
  • Gelişmiş IDOR Yöntemleri (UUID, GraphQL, Encode Edilmiş Referanslar): Bazı uygulamalar, basit ardışık sayıları ID olarak kullanmak yerine daha karmaşık kimlikler kullanarak IDOR riskini düşürmeye çalışır. Örneğin UUID gibi uzun ve rastgele görünen kimlikler kullanmak, saldırganın tahmin etmesini zorlaştırır. Ancak unutmamak gerekir ki kimlik ne kadar karmaşık olursa olsun, sunucuda yetki kontrolü yoksa IDOR yine de oluşabilir. Nitekim bazı uygulamalar UUID kullansa bile bu değerleri başka yerlerde sızdırabilir veya saldırgan bir şekilde geçerli bir UUID ele geçirebilirse yine yetkisiz erişim sağlayabilir. Benzer şekilde, Base64, hash gibi yöntemlerle ID’leri kodlamak da yaygın bir yaklaşımdır. Örneğin bir uygulama document_id=45 yerine document_id=MTIzNDU= (Base64 kodlu değer) kullanabilir. Bu sadece gizleme (obsfüskasyon) yöntemidir, gerçek bir güvenlik sağlamaz. Saldırgan bu tür kodlamaları kolaylıkla çözebilir veya rastgele türeterek deneyebilir. Bu nedenle, ID değerini Base64 ile encode etmek ya da MD5/SHA hash’ine çevirmek tek başına IDOR’u önlemez; arka planda yine kontrol yapılması şarttır.

🌟BONUS

Bir diğer gelişen alan GraphQL API’leridir. GraphQL, istemcinin dilediği verileri sorgulamasına olanak sağlayan esnek bir API yapısıdır. Ancak esnekliği nedeniyle, GraphQL’de her alan ve nesne için ayrı ayrı yetki kontrolü yapılması gerekir; aksi halde IDOR benzeri açıklar oluşabilir. Örneğin, Facebook’un 2020’de düzelttiği bir GraphQL API açığı, bir kullanıcının yönetici olmadığı bir Facebook sayfasının kullanıcı adını (URL’ini) değiştirmesine imkan tanıdı. Saldırgan, GraphQL mutasyon çağrısında page_id alanını hedeflediği sayfanın ID’siyle değiştirerek, o sayfanın adresini ele geçirebilmiştir. Bu, GraphQL’de obje seviyesinde yetki kontrolü eksikliğinin bir örneğidir. Yine başka bir senaryoda, bir doküman depolama servisinin GraphQL API’inde, bir dosyayı silme mutasyonunun sadece dosya ID’sine dayalı olarak çalıştığı ve kullanıcının o dosyanın sahibi olup olmadığını kontrol etmediği görülmüştür. Bu zaafiyet nedeniyle bir kullanıcı, GraphQL sorgusunda document_id alanını başka bir kullanıcıya ait dosyanın ID’si ile doldurarak o dosyayı silebilmiştir. Sonuç olarak, UUID kullanımı, GraphQL gibi yeni teknolojiler veya ID’lerin encode edilmesi gibi yöntemler geliştiriciler tarafından IDOR’u önlemek için tercih ediliyor olsa da, asıl kritik nokta her istekte sağlam bir yetki kontrol mekanizması uygulamaktır. Bu yöntemler saldırganın işini zorlaştırabilir fakat yetki kontrolü yoksa yine de IDOR açığı meydana gelebilir.

4. Gerçek Dünyadan Örnekler

IDOR, bug bounty platformlarında ve güvenlik araştırmalarında sıkça karşımıza çıkan bir açık türüdür. Aşağıda, çeşitli platformlarda raporlanmış ve yüksek önem derecesi taşıyan gerçek IDOR vakalarından bazılarını sizlere derledim:

  • HackerOne ve Bugcrowd Vakaları: HackerOne’ın 7. yıllık güvenlik raporuna göre, 2022 yılı itibariyle tüm raporlanan zafiyetlerin yaklaşık %7’sini IDOR oluşturmaktadır ve özellikle devlet kurumları (%15) ile otomotiv sektörü (%11) raporlarında IDOR çok sık görülmüştür. Bu istatistik bile tek başına IDOR’un ne kadar yaygın raporlandığını göstermektedir.
  • PayPal İş Hesabı İkincil Kullanıcı IDOR’u: 2020’lerin başında PayPal üzerinde keşfedilen kritik bir IDOR açığı, iş hesabı sahiplerinin hatalı yetki kontrolü nedeniyle kendi hesaplarına başka kullanıcıları ikincil kullanıcı olarak ekleyebilmesine olanak tanıdı. Saldırgan bu açığı kullanarak aslında kendine ait olmayan bir hesabın kullanıcı kimliğini sisteme sokup o hesapla ilişkilendirebiliyordu. Sonuç olarak, eklenen bu yetkisiz kullanıcı hesabın arayüzüne giriş yapıp diğer kullanıcının tüm işlemlerini görüp yapabilir hale geliyordu. Bu açık, başka bir kullanıcının hesap yetkilerini ele geçirmek anlamına geldiği için son derece ciddiydi.
  • Vimeo Parola Sıfırlama IDOR’u: Benzer şekilde, Vimeo platformunda raporlanan bir IDOR zafiyeti, saldırganın herhangi bir kullanıcının şifresini sıfırlayarak o hesabı tamamen ele geçirmesine olanak sağladı. Normalde şifre sıfırlama işlemleri token veya e-posta doğrulamasıyla kısıtlanmalıdır; ancak ilgili API çağrısında kullanıcı hesabını belirten bir kimlik değeri düzgün denetlenmediği için, saldırgan hedef kullanıcının ID’sini göndererek şifre yenileme sürecini başlatabildi. Böylece saldırgan, o kullanıcı adına yeni bir şifre belirleyip hesabına tam erişim kazanmıştır. Bu tür bir zaafiyet doğrudan hesap ele geçirilmesiyle sonuçlandığından hem şirket hem kullanıcılar için son derece büyük bir risk teşkil eder.
  • WordPress Eklentisinde 2023 IDOR Açığı (CVE-2023-4836): Sadece büyük platformlar değil, yaygın yazılım eklentileri de IDOR barındırabiliyor. 2023 yılında WordPress "User Private Files" eklentisinde keşfedilen CVE-2023-4836, düşük yetkili bir kullanıcıya bile başkalarının dosyalarına erişip indirebilme imkanı veren bir IDOR açığıydı. Eklenti, kullanıcıların özel dosyalarını ID’lerle ayırıyordu ancak bir kullanıcı, kendi yetkisi olmasa da özel bir dosya ID’si belirterek o dosyayı indirebiliyordu. Saldırgan minimal yetkilerle sisteme giriş yapıp bu açığı kötüye kullanarak diğer kullanıcıların gizli dosyalarına erişebildi. Bu açık ifşa edildikten sonra hızla kapatıldı, ancak gösterdi ki yaygın içerik yönetim sistemleri eklentilerinde bile IDOR benzeri kontroller atlanabiliyor ve bu durum tüm sistemin gizliliğini riske atabiliyor.
  • IoT Cihazlarında IDOR – Tic Toc Track Örneği: Bir önceki bölümde bahsedilen Avustralya menşeli çocuk takip saati vakası (TicTocTrack) de gerçek hayatta karşılaşılan çarpıcı IDOR örneklerindendir. Bu cihazın bulut API’lerinde, herhangi bir oturum sahibi kullanıcının başka bir kullanıcı ID’si ile istekte bulunması halinde sistemin verileri döndürdüğü keşfedildi. Saldırgan, kendi hesabıyla giriş yapıp API isteğinde userId parametresini sırayla değiştirerek platformdaki tüm kullanıcıların konum bilgisi, profil adı, telefon numarası gibi hassas verilerine ulaşmayı başardı. Üstelik bu açık sayesinde saldırgan cihazlara sahte konum göndermek, cihazı uzaktan aramak gibi işlevleri de kötüye kullanabildi. Bu vaka, IoT dünyasında API güvenliğinin önemini vurgulayan bir ders niteliğindedir. İnternet’e bağlı cihazların bulut servisleri de basit bir ID parametresinin korunmaması yüzünden ciddi mahremiyet ihlallerine yol açabilir.
  • 2023-2024 Dönemindeki Kritik Vakalar: Son bir iki yıl içinde de birçok IDOR açığı haber olmuştur. Örneğin, bir otomotiv firmasının araçlarında uzaktan kumanda özelliği sunan mobil API’inde, aracın şasi numarasını (VIN) gönderen kullanıcının o araca sahip olup olmadığını kontrol etmeyen bir BOLA açığı keşfedildi. Bu zafiyet, saldırganın kendi aracının mobil uygulama isteğinde VIN değerini değiştirerek başka bir aracı uzaktan kilitleyip çalıştırabilmesine olanak verdi ve düşündüğümüzde fiziksel güvenliğe dahi etki edebilen bir senaryo. Yine 2024'te, popüler bir yazılım geliştirme platformu olan GitLab’ın GraphQL API’sinde CVE-2023-4002 olarak izlenen bir IDOR açığı ortaya çıktı; bu açık sayesinde yetkisiz bir kullanıcının belirli bir GraphQL mutasyonu üzerinden hassas projelere erişebildiği raporlandı. Bu ve benzeri vakalar, IDOR’un farklı ortamlarda ve yıllar geçse de önemini koruduğunu gösteriyor. Uygulamalar karmaşıklaştıkça ve yeni teknolojiler benimsendikçe, IDOR da bazen farklı kılıklarda (ör. BOLA, nesne seviyesi yetki açığı) karşımıza çıkmaya devam ediyor.

5. IDOR Tespiti ve Test Yöntemleri

Bir uygulamada IDOR açıklarını tespit etmek, hem manuel yöntemlerle hem de otomatik araçlarla mümkün ve gereklidir. Deneyimli pentester’lar ve bug bounty avcıları, IDOR bulmak için sistematik yaklaşımlar uygularlar. İşte IDOR tespiti için başlıca yöntemler:

Manuel Test Teknikleri

En temel ve vazgeçilmez yöntem, uygulamayı farklı kullanıcı rolleriyle kullanarak karşılaştırmalı test yapmaktır. Örneğin, bir web uygulamasında IDOR testi yapmak için genellikle en az iki hesap oluşturulur (biri kurban rolünde, diğeri saldırgan rolünde). Test uzmanı öncelikle birinci hesapla belirli bir kaynağa (ör. kendi profil sayfası, kendi siparişleri) erişim isteği gönderir ve isteği kaydeder. Ardından aynı isteği ikinci hesapla (yetkisiz hesap) gönderirken, istekteki kullanıcı ID veya nesne ID değerlerini birinci hesaba ait olanlarla değiştirir. Eğer ikinci hesap, birinci hesabın verilerine erişebiliyorsa IDOR açığı vardır. Bu yöntem yatay yetki kontrolü (horizontal privilege escalation) testinin temelidir. Özellikle Burp Suite gibi web proxy araçları manuel testte çok işe yarar: Burp’ın Repeater özelliği kullanılarak bir isteği tekrar yakalayıp içerisindeki ID parametreleri kolayca değiştirilebilir ve sunucunun yanıtı gözlemlenebilir. Bu noktada "diffing" denilen teknik, yani orijinal isteğin yanıtı ile değiştirilmiş isteğin yanıtını karşılaştırmak faydalı olur ve eğer farklar diğer kullanıcının verilerini gösteriyorsa bingo, alarm zilidir. Manuel testte dikkat edilecek noktalar: Her farklı işlev (profil görüntüleme, veri silme, güncelleme vb.) için bu denemelerin yapılması, URL’lerin yanı sıra POST gövdelerinin ve hatta çerez/header gibi alanların da incelenmesidir. Örneğin bazen kullanıcı oturum kimliği (session ID) veya yetki seviyesini belirten bir bayrak çerez içinde taşınabilir ve tahmin edilebilir şekilde olursa, bu da IDOR tarzı bir açıkla sonuçlanabilir (örneğin çok basit oturum ID’lerini tahmin ederek başka oturumlara erişim). Özetle manuel test, uygulamayı farklı kullanıcı haklarıyla gezip her istekte parametre manipülasyonu yaparak beklenmedik veri erişimi olup olmadığına bakmaktır.

Otomatik ve Yarı Otomatik Araçlar: IDOR arayışını hızlandırmak ve sistematikleştirmek için çeşitli araçlar mevcut. Özellikle pentest süreçlerinde aşağıdaki araçlar ve teknikler kullanılır:

  • Burp Suite – Autorize Eklentisi: Autorize, Burp Suite içinden çalışan ve yetkilendirme açıklarını otomatik tespit etmeye yardımcı olan bir eklentidir. Mantığı, sizin iki oturum bilgisini (biri yetkili kullanıcıya, diğeri düşük yetkili/saldırgan kullanıcıya ait) tanımlamanız ve uygulamayı yüksek yetkili kullanıcıyla gezinirken tüm istekleri otomatik olarak düşük yetkili kullanıcı token’ıyla tekrar ettirmesi üzerine kuruludur. Örneğin, bir admin hesabıyla siteyi gezerken Autorize eklentisi her isteği aynı anda normal kullanıcı token’ıyla da gönderir ve gelen cevapları karşılaştırır. Eğer normal kullanıcının da admin verilerine erişebildiğini görürse sizi uyarır. Bu yöntemle, elle tek tek denemeye kıyasla çok daha geniş kapsamda ve hızlı bir şekilde IDOR yakalanabilir. Autorize, log tutarak hangi URL’lerin yetkisiz erişime izin verdiğini raporlar. Özellikle büyük uygulamalarda her endpoint’i manuel kontrol etmek zor olacağından, bu eklenti kritik bir yardımcıdır.
  • Fuzzing ve Brute-Force Araçları (Turbo Intruder, ffuf): Saldırgan gözüyle bakıldığında, IDOR bulmanın bir yolu da bir parametreye olabildiğince çok farklı değer deneyip hangilerinin geçerli olduğuna bakmaktır. Örneğin bir ?document=1000 parametresi gördünüz; Turbo Intruder (Burp eklentisi) kullanarak bu parametreyi 1’den 5000’e kadar tarayabilir ve her değer için dönen HTTP statülerini veya yanıt boyutlarını karşılaştırabilirsiniz. Eğer başka ID’lerde anlamlı yanıtlar alınıyorsa bunlar potansiyel yetkisiz erişimlerdir. Bu yaklaşım için Turbo Intruder yüksek hızda istekte bulunabildiği için idealdir. Benzer şekilde bağımsız bir komut satırı aracı olan ffuf (Fuzz Faster U Fool) da belirli bir endpoint’i veya parametreyi farklı değerlerle hızlıca deneyerek açık aramaya yarar. Ancak bu tür brute-force denemelerinde dikkat edilmesi gereken, uygulamanın rate limiting (istek sınırlama) yapıp yapmadığıdır. Eğer uygulama ardı ardına çok sayıda isteği engellemiyorsa, otomatik araçlarla ardışık ID denemek verimli sonuç verebilir.
  • Parametre Keşif Araçları (Arjun, ParamSpider): IDOR testinin bir adımı da “nerelerde potansiyel ID parametreleri var?” sorusuna yanıt bulmaktır. Bazen geliştiriciler ID’yi farklı isimlerle (user_id, uid, record, item, uuid vs.) kullanabilirler veya bazı API endpoint’leri dokümantasyonda gizli olabilir. Arjun, belli bir domain üzerindeki parametre adlarını fuzz eden bir araçtır. Uç noktalara çeşitli yaygın parametre isimleri göndererek hangilerinin yanıt verdiğini bulabilir. Bu sayede, gözden kaçmış gizli bir parametre (örn. &admin=true gibi) ortaya çıkarılabilir. ParamSpider ise uygulamanın ön yüzünü tarayarak parametre isimlerini ve URL’leri toplar, böylece test edilecek olası ID taşıyan parametrelerin listesini çıkarır. Bu araçlar, “gizli kalmış bir ID girişi var mı?” sorusuna cevap ararken pentester’ın işini kolaylaştırır. Örneğin, bir e-ticaret sitesinde normalde URL’lerde ürün ID’si görünmüyorsa fakat ParamSpider site içi bir endpoint’te product_id parametresi olduğunu keşfederse, test uzmanı bu parametreye odaklanıp IDOR denemesi yapabilir.
  • Kullanıcı Yetki Seviyesi Değişim Testleri: Bazı araçlar ve teknikler, uygulamanın rozetine bakarak yakalanamayan daha incelikli IDOR’ları ortaya çıkarabilir. Örneğin JSON Web Token (JWT) tabanlı bir uygulamada, token içinde kullanıcı rolü kodlanmıştır ama sunucu bunu doğrulamıyorsa bu bir IDOR varyantı olarak değerlendirilebilir. Yine HTTP Header manipulation (özellikle X-User-ID gibi custom header kullanan API’lerde) veya cookie değerlerinin tahmini de IDOR testinin parçasıdır. Bazen uygulamalar sunucu tarafında bile tutarlı kontrol yapmayıp, istemciden gelen bir role=admin parametresine inanarak yetki verirler (güvenlikte “client-side authoritative parameter” hatası). Bu tarz durumları da yakalamak için, bir pentester isteklerde gördüğü rollere veya kimliklere dair değerleri değiştirmeyi denemelidir. Örneğin bir istek parametresi ?role=user ise bunu admin yapıp denemek veya bir cookie’de isAdmin=false varsa true yapmak klasik bir test adımıdır. Bu, doğrudan bir IDOR olmasa da vertical privilege escalation (dikey yetki yükseltme) testiyle ilişkilidir ve genelde IDOR’la aynı kategoride (Broken Access Control) değerlendirilir.
  • Access Control Checklist’leri: Toplulukta pek çok araştırmacı, IDOR ve genel erişim kontrolü testleri için adım listeleri yayınlamıştır. Bu kontrol listeleri, sistematik bir yaklaşım sağlar. Örneğin bir checklist’te şu adımlar olabilir:
  • Mümkünse iki ayrı hesap oluştur veya en azından farklı kullanıcı kimliklerini keşfet.
  • Test edilen endpoint’in kimlik doğrulama gerektirip gerektirmediğini ve bir ID parametresi içerip içermediğini belirle.
  • İsteklerdeki ID parametresini başka bir kullanıcıya ait olabilecek bir değerle değiştir ve etkisini gözlemle.
  •  Eğer uygulama yanıt veriyor ve diğer kullanıcının verilerini gösteriyorsa IDOR var demektir.

Özetle, IDOR testi geniş bir yelpazede yaratıcı denemeler yapmayı gerektirir. Manuel test insan zekâsını ve sezgisini kullanarak beklenmedik açıkları bulmada önemliyken, otomasyon araçları da hızlı tarama ve kapsam atlamama açısından kritiktir. İyi bir pentester her ikisini birleştirerek hareket eder. Ayrıca, log incelemesi de faydalı olabilir: Test sırasında uygulamanın dönen hata mesajları veya HTTP statü kodları incelenerek “Yetkisiz” anlamına gelen durumlar (401/403) ile “Başarılı” durumlar (200/302 vs.) kıyaslanabilir. Eğer bir istek normalde 403 dönerken parametre değişince 200 dönüyorsa bu bir bulgudur. Unutmamak gerekir ki IDOR bulmak sabır ve dikkat işidir; uygulamanın tüm etkileşim noktalarını (profil sayfaları, mesajlar, dosyalar, admin panelleri, API uçları vb.) birer birer ele almayı gerektirir.

6. Geliştiriciler İçin Korunma Yöntemleri

IDOR açıklarını önlemek için tutarlı ve merkezi bir erişim kontrol mimarisi şarttır. Temel prensipler:

  • Kimlik Doğrulama & Yetkilendirme: Her istekte kullanıcının ilgili kaynağa erişim izni olup olmadığını kontrol edilmeli. Örn. /accounts/45 isteğinde, hesabın gerçekten o kullanıcıya ait olduğunu doğrulanmalıdır.
  • Merkezi Kontrol: Erişim denetimini tek bir ara katman/middleware üzerinden yapılmalıdır. Böylece tüm API istekleri aynı politikadan geçer, hata riski azalır.
  • En Az Yetki & Rol Tabanlı Erişim: Kullanıcıya yalnızca ihtiyacı olan izinleri verin. Hassas işlemler için ek doğrulama (şifre, 2FA) uygulanmalı.
  • Tahmin Edilemez ID’ler: Artan sayılar yerine UUID gibi rastgele kimlikler kullanmak gerekir. Dahili ID’leri dışarıya doğrudan göstermeyin; oturuma özel token’larla eşleştirin.
  • Framework/Library Desteği: Spring Security, Django permissions, ASP.NET Policy gibi hazır çözümleri veya kendi permission check fonksiyonlarınızı kullanın. Varsayılanı reddet (“default deny”) prensibini benimseyin.
  • Eğitim & Farkındalık: Ekip, IDOR’un risklerini ve önleme yollarını bilmeli. Kod incelemelerinde erişim kontrolleri checklist’e dahil edilmeli, testlerde yetkisiz erişim senaryoları otomatik olarak doğrulanmalıdır.

Yukarıdaki yöntemlerin hepsi, nihayetinde tek bir amaca hizmet ediyor: Erişim kontrolünün sürekliliğini ve bütünlüğünü sağlamak…

 

7. Sonuç ve Tavsiyeler

IDOR (Güvensiz Doğrudan Nesne Referansı), basit bir parametre manipülasyonu gibi görünse de sonuçları itibariyle son derece ciddi bir güvenlik açığıdır. Tarihsel olarak kimi zaman önem sıralamalarında XSS, SQL Injection gibi açıkların gölgesinde kalmış gibi düşünülse de, gerçek dünyadaki vakalar IDOR’un hafife alınmaması gerektiğini defalarca kanıtlamıştır. OWASP Top 10 listesinde Broken Access Control kategorisi altında zirvede yer alması da bunun bir göstergesidir. Bir IDOR açığı, en iyi ihtimalle yalnızca birkaç kullanıcının bilgisini ortaya çıkarır, en kötü senaryoda ise sistemdeki tüm verilerin sızmasına veya tam hesap ele geçirmelere yol açabilir. Bu yüzden ne uygulama geliştiricileri ne de güvenlik test uzmanları IDOR konusunu ikinci plana atmamalıdır.

Geliştiricilere Tavsiyeler

Erişim kontrolü, kod bittikten sonra “üzerine eklenen” bir şey değil; baştan kurgulanması gereken bir yapı. Mimariyi çizerken “her istek önce bir kontrol noktasından geçecek” diye başlamak işi çok kolaylaştırıyor. Kod yazarken de ID’lerle uğraştığın her yerde “bu kullanıcı bu veriyi görmeli mi?” sorusunu sormak büyük fark yaratıyor.

Framework’lerin yetkilendirme araçlarını öğrenip kullanmak (Laravel Policy, Django permissions, Spring @PreAuthorize gibi) büyük kolaylık sağlıyor. Testlerde farklı kullanıcı senaryolarıyla erişim denemeleri yapmak da ileride çıkabilecek hataları önceden yakalatıyor.

Bazen olay sadece teknik değil; ekipteki herkesin bu tip açıkların ne olduğunu bilmesi de önemli. OWASP’ın hazırladığı rehberler, otomatik güvenlik taramaları ve gerektiğinde yapılacak pentest’ler bu farkındalığı destekler. Sonuçta amaç basit: Uygulamada her veri erişimi, gerçekten o veriyi görmeye hakkı olan biri tarafından yapılmalı.

Güvenlik Uzmanlarına Notlar

IDOR, pentest ve bug bounty’de sık rastlanan ama etkisi büyük bir açık türü. Testlerde mutlaka erişim matrisi çıkarıp “kim neye erişebilir?” sorusuna cevap aramak işinizi kolaylaştırır. Basit bir fileId parametresi bile ciddi sonuçlar doğurabilir.

Zaman sınırlıysa kullanıcı profilleri, finansal işlemler, kişisel veri içeren alanlar ve admin panelleri öncelikli hedef olsun. Burp, Zap gibi araçlarda yetkisiz istek testleri yapacak şekilde ayar yapın, Autorize eklentisi de burada çok işe yarar.

Ve bulduğunuz açığı raporlarken mutlaka etkisini gösterecek net bir senaryo ekleyin; bu, konunun ciddiyetini karşı tarafa hemen anlatır.

Ve Son Söz

IDOR genelde sessizdir; ekranda hata da vermez, alarm da çalmaz. Sizi “normal” görünen ama aslında size ait olmayan bir veriye ulaştırır. İşte tehlike burada başlar.

Güvenlik ekibiyle geliştirme ekibi el ele verip, her veri için “kim görebilir?” sorusunu netleştirmeli ve her isteği buna göre filtrelemeli. Zero Trust mantığı burada da geçerli: Güvenme, doğrula. Bu yaklaşımı koddan teste her adımda uyguladığımızda, IDOR sadece teoride kalır.

 

“Erişim kontrolü, tüm siber güvenliğin temelidir”

Kaynaklar:
Bu yazı hazırlanırken HackerOne, PortSwigger ve OWASP dokümanları başta olmak üzere güvenlik topluluğundaki güncel makalelerden yararlanıldı. İçeriğin bazı bölümlerinde, bilgilerin toparlanması ve düzenlenmesi için makul düzeyde yapay zeka desteği kullanıldı.

Bilgi, doğru elde kalkan; yanlış elde silahtır.