AI'ın 11 Günde Yazdığı RBAC'ı Sızma Testi Mantığıyla Doğruladım

Eşim özel eğitim öğretmeni. Öğrencilerinin gelişim hedeflerini, davranış gözlemlerini ve çalışma kayıtlarını takip ettiği bir uygulama fikri vardı — kod yazmayı bilmiyor, o yüzden ilk versiyonu tek bir AI-üretimi HTML dosyası olarak başladı. On bir gün sonra elimizde Cloudflare Workers + D1 üzerinde çalışan, üç farklı rolü olan gerçek bir uygulama vardı. Ben bu süreçte üstlendiğim işi anlatacağım: özelliği değil, rol sınırlarının gerçekten tutup tutmadığını nasıl doğruladığımı.

Kurulum #

Uygulama şu an öğretmen, uzman öğretmen ve yönetici olmak üzere üç rol çalıştırıyor. Öğretmen sadece kendisine atanmış çocuk profillerini görebiliyor, uzman öğretmen sınırsız erişimle blog yönetimini de üstleniyor, yönetici üstüne kullanıcı yönetimini ekliyor. Backend bir Cloudflare Worker, JWT tabanlı auth, D1 veritabanı — AI bu mimariyi ilk turda doğru kurdu. Route’lar vardı, rol kontrolleri kod içinde vardı, her şey “çalışıyor” gibi görünüyordu.

Sorun şu: RBAC’ta “çalışıyor gibi görünüyor” ile “her rol sınırı her zaman tutuyor” arasındaki fark, tam olarak sızma testinde para kazandığım fark. Bir öğretmen ekranında sadece kendi öğrencilerini görüyor olması, API’ye doğrudan istek attığında başka bir öğretmenin öğrenci ID’sini alamayacağının kanıtı değil.

Neden manuel QA yetmez #

Uygulamada dokuz ayrı kaynak var: çocuk profilleri, hedefler, davranış gözlemleri, çalışma kayıtları, materyaller, hedef kütüphanesi, blog içeriği, takvim, kullanıcı yönetimi. Üç rol var. Kabaca yirmi beş civarı endpoint. Her kaynak için “bu role izin var mı” sorusunun cevabı en az üç farklı şekilde yanlış olabilir:

• Dikey yükseltme — öğretmen, yönetici endpoint’ine istek atıp cevap alabiliyor mu.
• Yatay IDOR — bir öğretmen, kendine ait olmayan bir çocuk profilinin ID’sini URL’e yazıp veriye ulaşabiliyor mu.
• Eksik obje sahiplik kontrolü — endpoint “giriş yapmış mısın” diye bakıyor ama “bu obje senin mi” diye bakmıyor.

Bunu elle, ekrandan tıklayarak test etmeye kalkarsanız üç rol × dokuz kaynak × üç hata sınıfı — seksen kombinasyonun üzerinde bir matris çıkar. Bir kere test edip geçtiğinizi görmek hiçbir şey kanıtlamaz, çünkü bir sonraki refactor’de biri bir route’a rol kontrolü eklemeyi unutursa bunu ancak tekrar aynı seksen kombinasyonu elle gezerek yakalarsınız. Yakalamazsınız.

Ne yaptım #

Go ile bir entegrasyon test paketi yazdım — auth, admin, çocuklar, hedefler, davranışlar, materyaller, kütüphane, çalışma kayıtları, state endpoint’i için ayrı test dosyaları. Her dosyanın çekirdeği aynı desen:

1. Üç rolden birer test kullanıcısı ve her role ait test verisi seed’le.
2. Her endpoint için üç rolün de token’ıyla istek at.
3. Beklenen matrisle (bu rol bu kaynağa yazabilir mi, okuyabilir mi, başkasının kaydına erişebilir mi) karşılaştır.
4. Beklenmeyen her 200, kırmızı.

Bunun sızma testinden farkı yok aslında — tek fark, bunu elle bir kerelik yapmak yerine kod olarak yazıp CI’da her commit’te otomatik koşturmak. Bir öğretmen rolünün başka bir öğretmenin childId‘siyle /goals endpoint’ine istek atıp veri alıp almadığını test eden satır, bir pentest raporundaki “IDOR bulgusu” ile birebir aynı sorunun cevabı — sadece bir kere değil, her deploy’da soruluyor.

AI kod yazınca test yazmaya gerek kalmadığı fikri yaygınlaşıyor; böyle bir paketin hâlâ bu kadar işe yaraması iyi bir hatırlatma oldu.

Gerçekte ne yakaladı #

En değerli olan bulgu değil, bulgunun ne zaman geldiği oldu: hızlı iterasyon sırasında yeni bir endpoint eklendiğinde (materyal yükleme, R2 entegrasyonu ile geldi) rol kontrolü ilk taslakta eksikti. Test paketi bunu deploy’dan önce, PR aşamasında yakaladı — üretimde bir öğretmenin başka bir öğretmenin yüklediği dosyaya erişip erişemediğini merak etmek yerine.

AI’ın ürettiği kod mantıksal olarak makuldü, syntax doğruydu, happy path’te sorunsuz çalışıyordu. Eksik olan, kimsenin sormadığı “olumsuz” senaryolardı — ki bu tam olarak sızma testinin işi. RBAC’ı gözle inceleyerek güvene almıyorsunuz; her rol sınırını aktif olarak kırmaya çalışan bir test yazıp geçemediğini görerek güvene alıyorsunuz.

Kısacası #

• RBAC’ta üç hata sınıfı var: dikey yükseltme, yatay IDOR, eksik obje sahiplik kontrolü — kod incelemesi ikisini kolayca kaçırır.
• Rol × kaynak × hata sınıfı matrisi hızla büyür; elle test etmek bir noktadan sonra imkansızlaşır, otomatik entegrasyon testi zorunlu hale gelir.
• AI’ın ürettiği kod mimari olarak sağlam olabilir ve yine de erişim kontrolü boşlukları taşıyabilir — ikisi bağımsız eksenler, biri diğerini garanti etmez.

Yan iş olarak web uygulaması sızma testleri yapıyorum — erişim kontrolü, RBAC, IDOR ve OWASP top 10’un geri kalanı dahil. Birden fazla rolü olan bir uygulama deploy ediyorsanız ve rol sınırlarının gerçekten tuttuğundan emin olmak istiyorsanız: [email protected].