Bir kullanıcının oturum açmış olması, URL veya istek gövdesinde gönderilen her nesneye erişebileceği anlamına gelmez. Nesne kimliği istemciden alınıyor ve yalnızca mevcut olup olmadığı kontrol ediliyorsa, saldırgan başka bir kullanıcının kaydını tahmin edilebilir bir ID ile okuyabilir ya da değiştirebilir. Bu durum genellikle IDOR veya BOLA olarak adlandırılır.
Aşağıdaki örnekte kullanıcı giriş yapmış olsa da güncellenecek siparişin gerçekten ona ait olup olmadığı denetlenmiyor:
[code lang="php"]
public function updateOrder(PDO $db, int $orderId, int $userId, string $address): void
{
$stmt = $db->prepare(
'UPDATE orders SET shipping_address = :address WHERE id = :id'
);
$stmt->execute([
'address' => $address,
'id' => $orderId,
]);
}
[/code]
PDO kullanımı burada SQL enjeksiyonunu önlemeye yardımcı olur; ancak yetkilendirme açığını çözmez. Kullanıcı, kendi siparişine ait olmayan bir [icode]orderId[/icode] gönderdiğinde sorgu yine çalışabilir. Etkilenen kaydın bulunmaması da hata olarak ele alınmadığı için uygulama başarısız bir işlem ile yetkisiz erişimi birbirinden ayıramaz.
Düzeltme: sahiplik koşulunu işlemin parçası yapmak
Sahiplik kontrolü, kaydı önce çekip sonra uygulama kodunda denetlemek yerine mümkün olduğunca veri değiştiren sorgunun koşullarına dahil edilmelidir. Böylece kontrol ile güncelleme arasında başka bir isteğin araya girmesi riski azalır:
[code lang="php"]
public function updateOrder(PDO $db, int $orderId, int $userId, string $address): void
{
$stmt = $db->prepare(
'UPDATE orders
SET shipping_address = :address
WHERE id = :id AND user_id = :user_id'
);
$stmt->execute([
'address' => $address,
'id' => $orderId,
'user_id' => $userId,
]);
if ($stmt->rowCount() !== 1) {
throw new RuntimeException('Sipariş bulunamadı veya erişim yetkisi yok.');
}
}
[/code]
Okuma işlemlerinde de aynı ilke uygulanmalıdır. Örneğin [icode]SELECT ... WHERE id = :id AND user_id = :user_id[/icode] koşulu kullanılmalı; yalnızca [icode]id[/icode] ile kayıt çekilip sonradan sahiplik kontrolü yapılmamalıdır. Yönetici rolü bu akışı atlayabiliyorsa, istisna açıkça tanımlanmalı ve yalnızca güvenilir bir sunucu tarafı rol kontrolünden sonra uygulanmalıdır. İstemcinin gönderdiği [icode]is_admin[/icode] gibi alanlara güvenilmemelidir.
AI destekli inceleme ve belirsizlik noktaları
AI’ye yalnızca ilgili metodu değil, kimlik doğrulama akışını, rol tanımlarını ve nesne ilişkisini de vererek şu tür bir inceleme isteği yöneltilebilir:
AI, [icode]user_id[/icode] koşulunu görmediğinde açığı doğru biçimde işaretleyebilir; fakat yalnızca kısa bir metod paylaşıldığında üst katmandaki bir politika kontrolünü gözden kaçırabilir veya mevcut bir erişim kuralını gereksiz yere açık sanabilir. Bu nedenle öneri kesin kanıt değil, incelenecek bir hipotez olarak ele alınmalıdır. Özellikle ORM’nin global kapsamları, yönetici istisnaları ve soft-delete davranışı ayrıca doğrulanmalıdır.Bu PHP metodunda kullanılan nesne kimliğinin mevcut kullanıcıya ait olup olmadığını incele. Okuma, güncelleme ve silme yollarını ayrı değerlendir. Yetki kontrolünün sorguda mı, servis katmanında mı yapıldığını belirt; görünmeyen middleware veya repository kuralları hakkında varsayım yapma.
Doğrulama adımları
- İki farklı kullanıcı ve her birine ait ayrı sipariş oluşturun.
- Birinci kullanıcı oturumuyla ikinci kullanıcının sipariş ID’sini kullanarak okuma, güncelleme ve silme isteklerini deneyin.
- İsteklerin 403 veya uygulamanın belirlediği güvenli bir 404 yanıtı verdiğini ve verinin değişmediğini doğrulayın.
- Birinci kullanıcı kendi nesnesini güncellediğinde tam olarak bir satırın etkilendiğini test edin.
- Yönetici rolü için izin verilen davranışı ayrı bir testte doğrulayın; normal kullanıcı rolünün bu istisnayı kullanamadığından emin olun.
- Eşzamanlı isteklerde ve bulunmayan ID’lerde hata günlüklerine hassas veri yazılmadığını kontrol edin.
