- Katılım
- 2 Ocak 2026
- Mesajlar
- 66
- Tepkime puanı
- 76
- Puan
- 18
Insecure Design Nedir?
Hack sadece kod üzerinden mi olur, peki ya mimari hatalar? Gelin sizinle bugün herhangi bir koda moda bir şeyler enjekte etmeden sadece yapılan mimari hataları ele alalım. Mimari hata diyip geçmeyin çok kritik zafiyetler barındırır.
Modern saldırıların bir çoğu artık İnj değil Mimari tasarım hatasından kaynaklandığını OWASP TOP10 çok net bir şekilde ifade ediyor bizlere. Insecure design bir sistemin işleyiş mantığının yanlış yapılandırılmasıdır.
Şöyle bir örnek Insecure Design çok iyi anlatır. Bir konser organizasyonu için web sitenizin olduğunu düşünün. İleri bir tarhite gerçekleşecek konser için bilet satışı başlattınız ama herhangi bir kapora sistemi olmadan sepete ekleniyor . Bir saldırgan bir kaç istekle çok fazla bileti ayna anda alıp şirketinizi çok fazla maddi kayba uğratabilir. Neden herhangi bir sınırlama ya da ön ödeme bulunmuyor?
Örnekte bahsedilen konser
Sunucular elbette çöker. İşte bu tür mimari hatalar Insecure Desgin olarak geçer.Daha önce NO RATE LİMİTİNG zafiyetiyle hall of fame listesine girdim. Sisteme kaydolduktan sonra şifremi unuttum kısmına tıklayınca kayıtlı meil’e sıfırlama isteği düşüyor. Lakin herhangi bir sınırlama yok. 50 İstek atılabiliyor. Peki aynı anda milyonlarca istek atsak?
Mimari hataların başında iş akış mantık hataları gelir( bussines logic flaws)
Workflow Manipulation İş Akışı Manipülasyonlarında şöyle bir mantık işler:
- Ürünü seç
- Ödemeyi yap
- Siparişi tamamla
Burpsuit ile istekleri takip edin. Eğer ödeme aşamasında
price=1000 gibi bir veri dönerse intruder’a atıp
price=0 deneyin. business logic flaw var ise bu bir iş mantık hatasıdır ve 3. aşamaya geçebilirsiniz.
Racon aşamasında ilk önce yapacağınız şey sub taraması olmasın. İş mantık hatası var mı yok mu ona odaklanmaya gayret gösterin. Backend Frontende çok fazla iş bırakmış olabilir, Müşterisine çok fazla güvenmiş olabilir, kim beni niye hacklesin kafasında da olabilir. Kim bilir belki bir köşede unutulmuş bir iş mantık hatası vardır.
Race Condition Zafiyeti son derece dikkat edilmesi gereken bir zafiyettir. Özellikle Ticari iş yapan firmalarda yaşanan bu zafiyet bazen milyonlarca veri kaybı yaşatabilir.Bir siteye bakarken ilk attığım adımlardan biri de login sayfasının varlığıdır. Eğer kaydolabiliyorsanız siteye kaydolup Forget pass deneyin. Sınırlama yok ise raporlama yapabilirsiniz.
Banka sistemlerinin üzerinde sıklıkla çalıştığı ve hemen hemen sıfır taviz verdiği bu açığın iş mantığı şöyledir:
Bakiye=100
harcama=100
kalan bakiye=0
Normal çalışma mantığının böyle olması lazım ama Insecure Design+ Race conditon var ise saldırgan şunu dener:
sistem üst üste istek yapıldığı için deyim yerindeyse kafa karışıklığı yaşar ve bakiye 100 tl iken 200 tl’lik bir harcama yaşanır. havale limit noktasında da bu durum denenebilir. 10bin sınır var iken aynı anda çok fazla istek gönderilirse Race condition yaşanabilirRequest 1 → bakiye kontrol → 100 TL
Request 2 → bakiye kontrol → 100 TL
şu örnek de yerinde olur:
Bu örnekler Insecure design sonucu ortaya çıkan business logic+Race Condition’dur, çok kritiktir.Stokta sadece bir ürün olsun.
Saldırgan aynı anda 100 satın alma isteği gönderir
Sistem stok kontrolünü eşzamanlı yapamaz duruma gelir ve 100 sipariş oluşur.
(Rce condition zafiyetini detaylı bir şekilde ele alacağımız bir yazı ele alacağız)
Son olarak
Insecure Design Nasıl Önlenir?
- Threat Modeling yapılmalı
- Business logic testleri yapılmalı
- Rate limiting uygulanmalı ( Kesinlikle)
- Server-side validation zorunlu olmalı
- Zero Trust yaklaşımı benimsenmeli