İş Mantığı (Business Logic) Güvenlik Açıkları: Fiyat Manipülasyonu ve Kupon İstismarı

İş Mantığı Güvenlik Açıkları Nedir?

Bir web uygulaması teknik açıdan tüm güvenlik kontrollerini başarıyla geçmiş olabilir — SQL Injection bulunmayabilir, XSS açıkları giderilmiş olabilir, kimlik doğrulama güvenli yapılandırılmış olabilir. Ancak buna rağmen uygulama, iş süreçlerinin yanlış tasarlanması veya eksik kontrol edilmesi nedeniyle saldırılara açık olabilir.

İş mantığı güvenlik açıkları (Business Logic Vulnerabilities), uygulamanın çalışma kurallarındaki eksikliklerden kaynaklanan ve saldırganların sistemi geliştiricinin öngörmediği şekillerde kullanmasına olanak tanıyan zafiyetlerdir. Sorun kullanılan teknolojide değil; uygulamanın "nasıl çalışması gerektiği" ile "gerçekte nasıl çalıştığı" arasındaki farktan doğar.

Neden Otomatik Güvenlik Araçları Bu Açıkları Kaçırır?

Otomatik araçlar SQL Injection veya XSS gibi önceden tanımlanmış teknik zafiyetleri kısa sürede tarayabilir. Ancak şu soruların cevabını otomatik bir araç veremez: Bir kullanıcı aynı indirim kuponunu kaç kez kullanabilir? Ödeme başarısız olmasına rağmen sipariş onaylanıyor mu? Aynı kampanya farklı hesaplarla kötüye kullanılabilir mi? Bu soruların cevabı yalnızca uygulamanın işleyişini anlayan deneyimli sızma testi uzmanlarının manuel analizleriyle bulunabilir.

En Yaygın Business Logic Açıkları

1. Fiyat Manipülasyonu

Bazı uygulamalar ürün fiyatını istemci tarafından gönderilen veriye göre hesaplar. Sunucu tarafında doğrulama yapılmıyorsa saldırgan isteği değiştirerek ürünü gerçek değerinin çok altında satın alabilir — örneğin {"productId": 2501, "price": 1500} isteğini {"productId": 2501, "price": 15} olarak manipüle etmek.

2. Kampanya ve Kupon Kötüye Kullanımı

Aynı kuponun farklı oturumlarda kullanılabilmesi, yarış koşullarının değiştirilebilmesi veya süresi dolmuş kuponların tekrar aktif olabilmesi doğrudan gelir kaybına neden olur.

3. İşlem Sırasının Atlatılması

Sepet → Adres → Ödeme → Sipariş Onayı gibi sıralı işlemlerde, saldırgan doğrudan son adımın isteğini gönderebiliyorsa süreç atlatılmış olur. Bu tür açıklar özellikle ödeme sistemlerinde kritik sonuçlar doğurabilir.

4. Yarış Durumu (Race Condition)

Aynı işlem eş zamanlı olarak birden fazla kez gönderildiğinde uygulama beklenmeyen davranışlar sergileyebilir — aynı hediye çekinin iki kez kullanılması, bakiyenin iki kez harcanması, aynı ürünün stoktan birden fazla kez düşmesi gibi.

Gerçek Bir Senaryo

Bir çevrim içi satış platformunda sipariş oluşturma ve ödeme işlemleri ayrı servisler üzerinden yürütülmektedir. Yapılan sızma testi sırasında, ödeme isteği iptal edilmesine rağmen sipariş servisinin bu durumu doğrulamadığı tespit edilmiştir. Sonuç olarak kullanıcı ödeme yapmadan sipariş oluşturabilmiş, sipariş "başarılı" durumuna geçmiş ve lojistik süreci otomatik olarak başlamıştır. Teknik açıdan sistemde SQL Injection, XSS veya RCE gibi klasik açıklar bulunmamasına rağmen, yalnızca iş akışındaki bu eksiklik ciddi finansal kayıp riski oluşturmuştur.

SecureSys Business Logic Test Yaklaşımı

Testlerimiz kapsamında iş akışlarının adım adım doğrulanması, yetki ve rol değişimlerinin analiz edilmesi, ödeme ve sipariş süreçlerinin test edilmesi, kampanya/kupon mekanizmalarının incelenmesi ve race condition senaryolarının oluşturulması gerçekleştirilir. Bu yaklaşım sayesinde teknik olarak güvenli görünen uygulamalardaki kritik iş mantığı zafiyetleri ortaya çıkarılır.

İş Mantığı Hatası ve Olası Sonuçları

İş Mantığı Hatası	Olası Sonuç
İndirim kuponunun tekrar kullanılabilmesi	Gelir kaybı
Ürün fiyatının istemci tarafında değiştirilebilmesi	Finansal zarar
Ödeme adımının atlanabilmesi	Yetkisiz siparişler
Onay sürecinin atlatılması	Yetkisiz işlem

İş mantığı açıklarının tespiti için deneyimli manuel test ekibi gerekir — bu konuda Web Uygulama Sızma Testi Hizmeti sayfamızdan bize ulaşabilirsiniz.