Conrado Sol
- 29 Nis 2026
- 120 Mesaj
Selamlar millet,
Siber güvenlikte veya bug bounty işlerinde takılan arkadaşların çoğu genelde hep aynı döngüye giriyor: Nerede bir site görsek hemen otomatik araçları basıyoruz, Acunetix açıyoruz, Burp Suite'in otomatik tarayıcılarını arkada koşturuyoruz. Ya da ezberlenmiş iki üç SQL injection, XSS payload'ı atıp "Ulan acaba zafiyet düşer mi?" diye bekliyoruz.
Sonra ne oluyor? Günümüz framework'leri, WAF sistemleri veya sağlam ORM yapıları yüzünden elimiz genelde boş dönüyor. Birçok kişi de bu noktada "Artık açık çıkmıyor ya, her yeri kapatmışlar" deyip salıyor.
Ama işin aslı hiç öyle değil.
Geçenlerde yine bir sistem incelerken kendi kendime düşündüm; kod tarafında ne kadar güvenlik önlemi alırsan al, yazılımcının kafasında kurduğu o mantık dünyasını kodla %100 sınırlayamazsın. İşte bugün tam olarak bu konuyu, yani otomatik araçların kör noktası olan Business Logic Flaws (İş Mantığı Hataları) konusunu enine boyuna konuşalım istiyorum.
Bir yazılımcı bir web uygulaması kodlarken kafasında senaryolar kurar. "Kullanıcı sepete ürünü ekler, sonra adresini girer, sonra ödemesini yapar ve ürün kargolanır." Yazılımcı bu akışın her zaman bu sırayla işleyeceğini varsayar. Ya da "Adam neden sepetindeki ürün adedine eksi sayı yazsın ki?" der ve oraya bir kontrol koymayı unutur.
İşte zafiyet tam olarak burada doğuyor.
Acunetix veya diğer ttarama araçları nedir? Birer koddur. Kod, önceden tanımlanmış syntax hatalarını arar. Bir URL'e girdiğinde tırnak işareti atar, SQL hatası var mı bakar. <script> basar, XSS var mı bakar. Ama o tarayıcı, senin incelediğin sitenin ne iş yaptığını bilemez. Sitenin mantığını, işleyişini, adımların sırasını analiz edemez.
O yüzden bu zafiyetleri bulacak tek bir araç var: Senin kendi kafan ve bakış açın.
Mantık şu: Sistem 1. adımdan 2. adıma, oradan 3. adıma geçmeni bekliyor. Sen Burp Suite ile araya girip 1. adımı tamamladıktan sonra doğrudan 3. adımın URL'ine veya API endpoint'ine istek atıyorsun. Eğer arka tarafta yazılımcı "Bu adam 2. adımı gerçekten tamamladı mı?" diye session (oturum) kontrolü yapmadıysa, pat! Sırayı bozup sistemi kandırmış oluyorsun. Ödeme yapmadan sipariş onaylama ekranına geçmek gibi düşünebilirsin.
Örneğin bir transfer ekranındasın veya sepettesin. Miktar kısmına 1 yazıp istek atıyorsun, sistem normal çalışıyor. Peki ya araya girip o miktarı -1 yaparsan ne olur?
Çoğu zayıf sistemde fiyat ile miktar çarpıldığı için negatif bakiye elde ediliyor.
Eğer sepette 100 TL'lik bir ürün varsa ve sen yanına -80 TL'lik hayali bir eksi adet eklersen, sepet tutarın bir anda 20 TL'ye düşebiliyor.
Hatta daha vahimi, bakiyenden düşmesi gereken para senin bakiyene eklenmeye başlıyor!
Çünkü yazılımcı pozitif sayı kontrolü (örn: if amount > 0) koymayı akıl edememiş.
Mesela sistemde iki farklı rol var: "Öğrenci" ve "Eğitmen". Eğitmen panelinde bir butona bastığında arka planda POST isteğiyle bir kurs oluşturuluyor (/api/v1/create-course). Sen öğrenci hesabınla aynı isteği elle oluşturup sunucuya atarsan ne olur? Sunucu "Bu istek öğrenci token'ı ile geldi, dur bakalım bu adam eğitmen mi?" kontrolü yapıyor mu, yoksa sadece endpoint'in varlığına güvenip işlemi onaylıyor mu?
İşte bu kontrolün unutulduğu her yer bizim için devasa bir zafiyet kapısıdır.
Sistemde tek kullanımlık bir hediye kuponu var diyelim. Normalde kuponu girdiğinde sistem veritabanına bakar: "Kupon kullanıldı mı? Hayır. Tamam, bakiyeyi ekle ve kuponu 'kullanıldı' olarak işaretle."
İşte o arada milisaniyelik bir gecikme var. Sen Burp Suite'in Turbo Intruder tarzı araçlarıyla aynı milisaniyede sunucuya 20 tane aynı kupon kullanma isteği atarsan ne olur? Veritabanı ilk isteği işleyip "kullanıldı" bayrağını çekene kadar, kalan 15 istek çoktan içeri girmiş oluyor. Sonuç? Tek kuponla 15 kere bakiye yüklüyorsun.
Özetle...knk
Bana kalırsa siber güvenlikte bizi öne geçirecek şey araçları iyi kullanmak değil; sistemlerin arkasındaki insan aklını ve hatalarını okuyabilmektir.
SQLi, XSS gibi şeyler artık otomasyonların eline düştü. Ama bu bahsettiğim Mantık Hataları (Business Logic Flaws) her zaman var olacak. Çünkü kodları yazılımcılar yazdığı sürece, onların insan olarak gözden kaçırdığı mantık hataları da var olmaya devam edecek.
Konu hakkında sorularınız, kendi karşılaştığınız ilginç mantık hataları veya eklemek istediğiniz noktalar varsa aşağıda tartışalım.
Siber güvenlikte veya bug bounty işlerinde takılan arkadaşların çoğu genelde hep aynı döngüye giriyor: Nerede bir site görsek hemen otomatik araçları basıyoruz, Acunetix açıyoruz, Burp Suite'in otomatik tarayıcılarını arkada koşturuyoruz. Ya da ezberlenmiş iki üç SQL injection, XSS payload'ı atıp "Ulan acaba zafiyet düşer mi?" diye bekliyoruz.
Sonra ne oluyor? Günümüz framework'leri, WAF sistemleri veya sağlam ORM yapıları yüzünden elimiz genelde boş dönüyor. Birçok kişi de bu noktada "Artık açık çıkmıyor ya, her yeri kapatmışlar" deyip salıyor.
Ama işin aslı hiç öyle değil.
Geçenlerde yine bir sistem incelerken kendi kendime düşündüm; kod tarafında ne kadar güvenlik önlemi alırsan al, yazılımcının kafasında kurduğu o mantık dünyasını kodla %100 sınırlayamazsın. İşte bugün tam olarak bu konuyu, yani otomatik araçların kör noktası olan Business Logic Flaws (İş Mantığı Hataları) konusunu enine boyuna konuşalım istiyorum.
Bu İşin Mantığı Ne? Neden Araçlar Göremiyor?
Şimdi aranızdan "Kanka nedir bu Business Logic dediğin olay?" diyenler olacaktır. En basit haliyle şöyle özetleyeyim:Bir yazılımcı bir web uygulaması kodlarken kafasında senaryolar kurar. "Kullanıcı sepete ürünü ekler, sonra adresini girer, sonra ödemesini yapar ve ürün kargolanır." Yazılımcı bu akışın her zaman bu sırayla işleyeceğini varsayar. Ya da "Adam neden sepetindeki ürün adedine eksi sayı yazsın ki?" der ve oraya bir kontrol koymayı unutur.
İşte zafiyet tam olarak burada doğuyor.
Acunetix veya diğer ttarama araçları nedir? Birer koddur. Kod, önceden tanımlanmış syntax hatalarını arar. Bir URL'e girdiğinde tırnak işareti atar, SQL hatası var mı bakar. <script> basar, XSS var mı bakar. Ama o tarayıcı, senin incelediğin sitenin ne iş yaptığını bilemez. Sitenin mantığını, işleyişini, adımların sırasını analiz edemez.
O yüzden bu zafiyetleri bulacak tek bir araç var: Senin kendi kafan ve bakış açın.
Gerçek Hayattan Senaryolar (Nereye, Nasıl Bakacağız?)
Lafı çok teoride bırakmayı sevmem, o yüzden gelin birkaç farklı senaryo üzerinden gidelim. Siz de hedef bir sisteme bakarken zihninizi bu yönde çalıştırın.1. İş Akışını/Adımları Atlatma (Workflow Bypass)
Özellikle çok adımlı formlarda, kayıt süreçlerinde veya e-ticaret sitelerinde çok sık karşılaşıyoruz.Mantık şu: Sistem 1. adımdan 2. adıma, oradan 3. adıma geçmeni bekliyor. Sen Burp Suite ile araya girip 1. adımı tamamladıktan sonra doğrudan 3. adımın URL'ine veya API endpoint'ine istek atıyorsun. Eğer arka tarafta yazılımcı "Bu adam 2. adımı gerçekten tamamladı mı?" diye session (oturum) kontrolü yapmadıysa, pat! Sırayı bozup sistemi kandırmış oluyorsun. Ödeme yapmadan sipariş onaylama ekranına geçmek gibi düşünebilirsin.
2. Sınır Değerler ve Negatif Sayı Manipülasyonu
Yazılımcıların en çok yaptığı hatalardan biri: Kullanıcının gireceği verinin türüne güvenmek.Örneğin bir transfer ekranındasın veya sepettesin. Miktar kısmına 1 yazıp istek atıyorsun, sistem normal çalışıyor. Peki ya araya girip o miktarı -1 yaparsan ne olur?
Çoğu zayıf sistemde fiyat ile miktar çarpıldığı için negatif bakiye elde ediliyor.
Eğer sepette 100 TL'lik bir ürün varsa ve sen yanına -80 TL'lik hayali bir eksi adet eklersen, sepet tutarın bir anda 20 TL'ye düşebiliyor.
Hatta daha vahimi, bakiyenden düşmesi gereken para senin bakiyene eklenmeye başlıyor!
Çünkü yazılımcı pozitif sayı kontrolü (örn: if amount > 0) koymayı akıl edememiş.
3. Yetki Sınırlarını Zorlama (IDOR ile Mantık Birleşimi)
Bunu sadece klasik "ID değiştirip başkasının verisini görme" olarak düşünmeyin. Mantıksal yetki aşımından bahsediyorum.Mesela sistemde iki farklı rol var: "Öğrenci" ve "Eğitmen". Eğitmen panelinde bir butona bastığında arka planda POST isteğiyle bir kurs oluşturuluyor (/api/v1/create-course). Sen öğrenci hesabınla aynı isteği elle oluşturup sunucuya atarsan ne olur? Sunucu "Bu istek öğrenci token'ı ile geldi, dur bakalım bu adam eğitmen mi?" kontrolü yapıyor mu, yoksa sadece endpoint'in varlığına güvenip işlemi onaylıyor mu?
İşte bu kontrolün unutulduğu her yer bizim için devasa bir zafiyet kapısıdır.
4. Zamanlama ve Yarış Durumları (Race Condition)
İşin biraz daha eğlenceli ve teknik boyutu burası.Sistemde tek kullanımlık bir hediye kuponu var diyelim. Normalde kuponu girdiğinde sistem veritabanına bakar: "Kupon kullanıldı mı? Hayır. Tamam, bakiyeyi ekle ve kuponu 'kullanıldı' olarak işaretle."
İşte o arada milisaniyelik bir gecikme var. Sen Burp Suite'in Turbo Intruder tarzı araçlarıyla aynı milisaniyede sunucuya 20 tane aynı kupon kullanma isteği atarsan ne olur? Veritabanı ilk isteği işleyip "kullanıldı" bayrağını çekene kadar, kalan 15 istek çoktan içeri girmiş oluyor. Sonuç? Tek kuponla 15 kere bakiye yüklüyorsun.
Sızma Testinde veya Keşifte Nasıl Bir Yol İzlemeliyiz?
Kendi çalışma metodolojimden birkaç ipucu vereyim, bakarken işinize yarar:- Uygulamayı Önce Normal Bir Kullanıcı Gibi Gezin: Hiç Burp'e bakmadan, sitenin ne iş yaptığını, mantığının nasıl çalıştığını bir çözün. Sistem ne satıyor? Veri nereye gidiyor? Hangi adımlar var?
- "Yazılımcı Burada Ne Düşünmüştür?" Sorusunu Sorun: "Galiba yazılımcı buraya sadece sayı girileceğini sanmış", "Herhalde bu butona iki kere basılmayacağını düşündü" dediğiniz her yeri not alın.
- Parametrelerle Oynayın: Giden JSON veya POST verilerindeki alanları silin, değiştirin, negatif yapın, çok uzun metinler koyun, yetkisiz rollere ait parametreler ("is_admin": true) eklemeyi deneyin.
- Adımların Yerini Değiştirin: İsteklerin sırasını bozun, eski session'larla yeni adımları tetiklemeye çalışın.
Özetle...knk
Bana kalırsa siber güvenlikte bizi öne geçirecek şey araçları iyi kullanmak değil; sistemlerin arkasındaki insan aklını ve hatalarını okuyabilmektir.
SQLi, XSS gibi şeyler artık otomasyonların eline düştü. Ama bu bahsettiğim Mantık Hataları (Business Logic Flaws) her zaman var olacak. Çünkü kodları yazılımcılar yazdığı sürece, onların insan olarak gözden kaçırdığı mantık hataları da var olmaya devam edecek.
Konu hakkında sorularınız, kendi karşılaştığınız ilginç mantık hataları veya eklemek istediğiniz noktalar varsa aşağıda tartışalım.
