Neler yeni
Bughane Academy

Bughane Academy, bug bounty, web güvenliği ve sızma testi alanında kendini geliştirmek isteyenler için kurulmuş Türkçe odaklı bir topluluktur.

Burada; gerçek güvenlik açıkları, recon ve exploit teknikleri, payload & bypass yöntemleri, araçlar, scriptler ve write-up’lar topluluk tarafından paylaşılır ve tartışılır.

Birlikte öğren, birlikte üret, birlikte güçlen.

Kritik bir zafiyet: Insecure Design Nedir?

Zeki Kayaalp

Administrator
Moderator
Avcı
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.

1*aGp39gGiZPApIucigW06aQ.jpeg

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?
1*PPe6bG18X3ucTM2FrmXHBA.png

Örnekte bahsedilen konser

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?
Sunucular elbette çöker. İşte bu tür mimari hatalar Insecure Desgin olarak geçer.

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:


  1. Ürünü seç
  2. Ödemeyi yap
  3. Siparişi tamamla
Hacker 2. adımı atlatıp siparişi tamamlayabiliyorsa işte bu iş mantık manipülasyonudur. Hacker genelde bunu parametreleri manuel olarak değiştirerek yapar.

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.


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.
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.
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:

Request 1 → bakiye kontrol → 100 TL
Request 2 → bakiye kontrol → 100 TL
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şanabilir

şu örnek de yerinde olur:


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.
Bu örnekler Insecure design sonucu ortaya çıkan business logic+Race Condition’dur, çok kritiktir.

(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
 
Geri
Üst