🐹 Mustafa ile Öğreniyorum #25 — "URL'deki ID'yi Değiştirdim, Başkasının Hesabına Girdim!": BOLA / IDOR Zafiyeti Herkese Selamlar, Hepinize hayırlı cumalar dilerim! Bugünkü başlığımız web ve mobil uygulamaların en yaygın, en tehlikeli ama mantığını anlaması bir o kadar kolay zafiyeti: BOLA (Broken Object Level Authorization) ve yakından ilişkili IDOR (Insecure Direct Object Reference) zafiyetleri. Yapay zekâlar, karmaşık şifreleme algoritmaları, devasa güvenlik duvarları... Bazen hepsini boşa çıkaran şey, geliştiricinin arka planda yapmayı unuttuğu tek bir yetki kontrolüdür. Peki, sadece bir rakamı değiştirerek başkasının verilerine erişmek nasıl mümkün oluyor? Gelin adım adım inceleyelim: Kuru Temizlemeci Mantığı (Benzetme): Bir kuru temizlemeciye gidip montunuzu teslim ettiğinizi ve size 105 numaralı fişin verildiğini düşünün. Montunuzu almaya gittiğinizde çalışana "Ben 106 numarayı istiyorum Nasıl Çalışır?** Bir e-ticaret veya bankacılık uygulamasında faturanızı görüntülemek istediğinizde, tarayıcınız arka plandaki API'ye şöyle bir istek atar: GET /api/v1/fatura?id=105 Kırılma Noktası: Saldırgan tarayıcının adres çubuğundaki veya isteğin içindeki id=105 değerini id=106 yapar. Backend'in Unuttuğu Soru: Sunucu kullanıcıya bakar: "Bu adam sisteme giriş yapmış mı? Evet, oturumu açık (Authenticated)." Ancak sunucu şu hayati soruyu sormayı unutur: "Peki bu giriş yapmış kullanıcı, gerçekten 106 numaralı faturanın sahibi mi? (Authorized)". Yanıt aranmadığı için sunucu 106 numaralı faturadaki tüm özel kişisel verileri şak diye ekrana basar! Veri Sızıntısı Tsunami'si: Saldırganlar bu işlemi otomatikleştirip bir script yazarak id=1den id=1000000a kadar tüm sayaçları tarar (Enumeration). Saldırgan, yeterli erişim ve uygun koşullar varsa çok sayıda müşterinin verisini otomatik olarak toplayabilir. 📌 Siber Güvenlik Dersi: BOLA/IDOR bir kod hatası değil, bir mimari mantık hatasıdır. Kimlik doğrulama (Authentication) ile yetkilendirme (Authorization) arasındaki farkı anlamak hayat kurtarır. Nasıl Engellenir? Arka planda her veri isteğinde mutlaka "İstek atan kullanıcı = Verinin sahibi" kontrolü yapılmalıdır (WHERE fatura_id = 106 AND kullanici_id = mevcut_kullanici). Tahmin edilmesi zor UUID'ler ek bir güvenlik katmanı sağlayabilir; ancak her veri isteğinde sunucu tarafında yetkilendirme kontrolü yapılması zorunludur. "Sisteme kimliğini kanıtlamış olmak, içerideki her kapıyı açabileceğin anlamına gelmez." 💬 Mustafa soruyor: Bir web sitesinde gezinirken URL'deki bir ID'yi değiştirip yanlışlıkla başkasının verisini gördüğünüz (IDOR ile karşılaştığınız) bir an oldu mu? Yorumlarda buluşalım! 👇