IDOR ve BOLA Test Planı: Çok Oturumlu Yetki Testi Nasıl Yapılır

Açıklama: Eresus Security'nin kurucusuyum. Bu yazı, IDOR/BOLA test metodolojisini anlatır; Eresus Guard'ın bu alandaki yaklaşımını da içerir. Ürün detayları için Eresus sayfasına bakın.

IDOR (Insecure Direct Object Reference) ve BOLA (Broken Object Level Authorization), API güvenlik testlerinde en sık bulunan ama otomatik tarayıcıların tek oturumla kaçırdığı açıklardır. OWASP API Security Top 10'da bir numaradır — ve sebebi basittir: yetki kontrolü, nesne düzeyinde değil istek düzeyinde yapılır.

Neden tek oturum yetmez?#

Klasik bir DAST tarayıcısı tek bir kullanıcı olarak giriş yapar, endpoint'leri tarar, yanıt kodlarına bakar. Ama IDOR'u yakalamak için aynı isteği iki farklı kullanıcının bağlamında karşılaştırmanız gerekir:

Kullanıcı A (hesap 1001):  GET /api/orders/9001  -> 200, A'nın siparişi
Kullanıcı B (hesap 1002):  GET /api/orders/9001  -> 200, A'nın siparişi   <-- açık
Kullanıcı B (hesap 1002):  GET /api/orders/9001  -> 403                   <-- beklenen

Tek oturumla bu karşılaştırmayı yapamazsınız. İki oturumu aynı anda tutup yanıtları kıyaslamanız gerekir.

Manuel test planı#

1. Hedef envanteri#

Önce API yüzeyini çıkarın:

# OpenAPI/Swagger dokümanı varsa indirin
curl -s https://hedef.example.com/api/openapi.json | jq '.paths | keys'
 
# Yoksa Burp Suite'te site haritası çıkarın, JS dosyalarındaki API çağrılarını toplayın
grep -rhoE '/api/[a-zA-Z0-9/_{}-]+' app.js | sort -u

ID parametresi alan her endpoint'i listeleyin: /api/users/{id}, /api/orders/{id}, /api/files/{id}, /api/invoices/{id}.

2. İki test kullanıcısı oluşturun#

A ve B kullanıcısı — aynı rolde, farklı verilerle. Her ikisinin de session token'ını alın:

# A kullanıcısı olarak giriş
curl -s -X POST https://hedef.example.com/api/auth/login \
  -H 'content-type: application/json' \
  -d '{"username":"test-a","password":"Test123!"}' -c cookies-a.txt
 
# B kullanıcısı olarak giriş
curl -s -X POST https://hedef.example.com/api/auth/login \
  -H 'content-type: application/json' \
  -d '{"username":"test-b","password":"Test123!"}' -c cookies-b.txt

3. Karşılaştırma matrisi#

Her ID'li endpoint için bu matrisi çalıştırın:

# A'nın siparişini B'nin oturumuyla iste
curl -s https://hedef.example.com/api/orders/9001 -b cookies-b.txt | jq .
# 200 + A'nın verisi dönerse: IDOR doğrulandı

4. ID tahmin edilebilirliği#

Sıralı integer ID'ler (/api/users/1001, /api/users/1002) enumeration'a açıktır. UUID'ler daha dayanıklıdır ama yetki kontrolü yoksa yine de açıktır — saldırgan ID'yi log'lardan, yanıtlardan veya başka endpoint'lerden öğrenebilir.

# Sıralı ID taraması (yetkili test kapsamında)
for id in $(seq 9001 9020); do
  echo "=== $id ==="
  curl -s -o /dev/null -w '%{http_code}\n' https://hedef.example.com/api/orders/$id -b cookies-b.txt
done

5. Toplu atama (mass assignment)#

IDOR'un kuzenidir: istek gövdesine ek alanlar enjekte edip sunucunun kabul edip etmediğine bakın:

curl -s -X PUT https://hedef.example.com/api/users/me \
  -H 'content-type: application/json' -b cookies-b.txt \
  -d '{"name":"Test","role":"admin","accountId":1001}' | jq .
# role: admin yansıdıysa: toplu atama açığı

6. Kanıt ve rapor#

Her bulgu için:

1. İstek ve yanıtın tamamı (iki oturumun karşılaştırmasıyla).
2. Etkilenen nesne ve veri hassasiyeti.
3. Düzeltme: sunucu tarafında nesne sahipliği kontrolü — if (order.userId !== req.user.id) return 403.

Otomasyonun rolü ve sınırı#

Bu matris tekrarlanabilir olduğu için otomatikleştirilebilir — ama iki oturumu aynı anda yönetmek, yanıtları anlamsal olarak karşılaştırmak ve yanlış pozitifleri elemek gerekir. Eresus Guard'ı bu yüzden çok oturumlu kimlik doğrulamalı test yapacak şekilde tasarladık: farklı kullanıcıların nelere eriştiğini karşılaştırarak IDOR ve yetki aşımını tespit eder.

Ama dürüst sınır: otomasyon insan değerlendirmesinin yerini almaz. İş mantığına özgü yetki kurallarını (örneğin "müdür kendi ekibinin verisini görebilir") ancak kapsamı bilen bir test uzmanı doğrulayabilir. Tarayıcı adayı gösterir, kararı insan verir.

İlgili yazılar#

• Eresus Guard'ı Neden Geliştirdik: ürünün çözdüğü üç problem.
• XSS Lab Rehberi: bağlama göre manuel test metodolojisi.
• NoSQL Injection Bölüm 1: operatör enjeksiyonu ve kör veri çıkarma.