Aracı Kurum Web Uygulamalarında İşlem Mantığı ve Race Condition Riskleri

İşlem Mantığı Kavramı

Klasik uygulama zafiyetleri doğrudan kod yazımındaki teknik hatalardan kaynaklanır. Örneğin SQL Enjeksiyonu ve XSS doğrudan bu kategoride yer alır. Ancak işlem mantığı (business logic) hataları tamamen farklı bir yapı gösterir. Çünkü bu senaryolarda kaynak kod teknik açıdan hatasız çalışır.

Buna karşın asıl problem, geliştiricilerin kurguladığı hatalı iş akışı varsayımlarında başlar. Örneğin geliştirici, kullanıcının emir formundaki adımları her zaman sırayla izleyeceğini düşünür. Oysa saldırganlar HTTP istek sıralarını araya girerek kolayca değiştirir. Bu nedenle yazılım, tasarlanırken hesaba katılmamış beklenmedik durumlar üretir.

Otomatik güvenlik tarayıcıları yalnızca imza ve kalıp kontrolü yapar. Bu araçlar hatalı bir veri tabanı sorgusunu anında yakalar. Ancak hiçbir otomatik yazılım, bir kullanıcının mevcut bakiyesini aşıp aşmadığını anlayamaz. Dolayısıyla işlem mantığı açıkları finansal platformlar için son derece tehlikeli bir risk oluşturur.

Finansal yazılımlarda iş akışları birbirine bağlı kurallardan oluşur. Örneğin bir hisse alımında bakiye blokajı, komisyon oranı ve marjin katsayısı sırayla hesaplanır. Eğer sistem bu adımların sırasını sunucu tarafında zorunlu kılmazsa mantık açığı doğar. Kötü niyetli kullanıcılar parametreleri değiştirerek haksız işlem avantajı sağlar.

Ayrıca mikroservis mimarileri bu riskleri daha da artırır. Çünkü farklı servisler arasındaki veri senkronizasyonu gecikebilir. Bir servis bakiye düşerken diğer servis emri piyasaya iletebilir. İki servis arasındaki zamanlama uyumsuzluğu sisteme mantıksal müdahale imkanı tanır.

Race Condition Mimarisi

Finansal platformlar her saniye binlerce işlem çağrısını yönetir. Bu sebeple eş zamanlılık mimarisi hayati bir rol oynar. Yarış durumu ya da teknik adıyla Race Condition, iki farklı isteğin aynı veriye eş zamanlı erişmesiyle başlar. Sistem istekleri doğru sıraya koyamazsa veri bütünlüğü anında bozulur.

Aracı kurumlarda en sık “Kontrol ve Kullanım Arasındaki Zaman Farkı” (TOCTOU) riski yaşanır. Örneğin yatırımcının hesabında sadece 10.000 TL nakit bakiye bulunur. Yatırımcı, milisaniyeler içinde aynı anda iki adet 10.000 TL tutarında alım emri gönderir. Sunucu ilk isteğin bakiye kontrolünü başarıyla tamamlar.

Fakat sunucu ilk emrin tutarını henüz bakiyeden düşmeden, ikinci istek kontrol noktasına varır. İkinci istek de bakiyeyi hâlâ 10.000 TL olarak okur ve emri onaylar. Sonuç olarak kullanıcı toplam 20.000 TL değerinde pozisyon açar. Bu açık kurum nezdinde negatif bakiye ve teminat açığı doğurur.

Ayrıca para transferi süreçlerinde de benzer yarış durumları yaşanır. Örneğin kullanıcı paralel HTTP istekleriyle bakiyesini aynı anda birden fazla hesaba çeker. Veritabanı kayıtları işlem bazında kilit taşımazsa mükerrer para çekimi gerçekleşir. Böylece aracı kurum doğrudan nakit zararı yaşar.

Dağıtık sistemlerde yarış durumları daha karmaşık hale gelir. Çünkü veritabanı replikasyonu anlık gecikmeler yaşayabilir. Ana sunucu bakiyeyi güncellerken yedek sunucu eski bakiyeyi okuyabilir. Saldırganlar bu milisaniyelik replikasyon gecikmelerini kullanarak çift bakiye harcaması yapar.

Kredili işlemlerde de race condition büyük tehdit oluşturur. Örneğin kullanıcı gün içi teminat limitini aşan birden fazla emri milisaniyelik aralıklarla iletir. Risk motoru limit kontrolünü tamamlayana kadar emirler borsaya ulaşır. Sonuçta aracı kurum istemeden yasal sınırların üzerinde kredi kullandırmış olur.

Kritik Finansal Senaryolar

Aracı kurum sistemleri karmaşık kurallar ve çoklu servis entegrasyonları barındırır. Bu yüzden mantık hataları farklı adımlarda ortaya çıkar. Sektörde en sık karşılaşılan senaryolar şunlardır:

İstemci Taraflı Emir Parametreleri

Geliştiriciler kullanıcı deneyimini hızlandırmak için tarayıcıda JavaScript kontrolleri uygular. Örneğin taban, tavan ve lot limitlerini istemci tarafı doğrular. Ancak bu kontroller güvenlik sağlamaz. Saldırganlar HTTP isteklerini araya girerek kolayca manipüle eder. Sonuç olarak sunucu piyasa kurallarına aykırı emirleri kabul eder.

Çok Adımlı Akışların Atlanması

Yatırımcılar yasal mevzuat gereği belirli anketleri tamamlamak zorundadır. Örneğin risk profili anketi ve sözleşme onayları sırayla ilerler. Ancak adımlar bağımsız API uçlarına bağlıysa kullanıcı ara ekranları doğrudan atlar. Böylece kullanıcı yetkisiz şekilde türev piyasa işlem izni alır.

Komisyon ve Promosyon Suistimalleri

Aracı kurumlar dönemsel olarak indirim kodu ve hacim bonusu dağıtır. Bu kurallar ana emir motorundan ayrı bir serviste çalışır. Sistem indirim kodlarının kullanım adetlerini merkezi bir kilitle doğrulamazsa suistimal başlar. Saldırganlar aynı kampanya kodunu defalarca işleterek haksız kazanç sağlar.

İptal ve Geri Alma Tutarsızlıkları

Yazılım ekipleri genellikle işlemlerin başarıyla bittiği senaryoları test eder. Oysa kısmi gerçekleşen emir iptalleri daha karmaşık bir mantık işletir. Sistem emir iptali anında bloke tutarı iki defa iade ederse kurum portföy dengesi bozulur.

Yetkilendirme ve Hesap Numarası Manipülasyonu

API isteklerinde yer alan hesap numaraları tahmin edilebilir diziler taşır. Eğer sunucu kullanıcının oturumu ile hesap numarasını eşleştirmezse yetki aşımı oluşur. Kullanıcı parametreyi değiştirerek başka yatırımcıların portföyünü görüntüler veya emirlerini iptal eder.

Zafiyet Türü	Hatalı Varsayım	Doğrudan Operasyonel Risk
Race Condition	İsteklerin her zaman sıralı işleneceği düşüncesi	Mevcut limitin üstünde pozisyon açılması ve negatif bakiye
İstemci Bazlı Kontrol	Tarayıcıdan gelen parametrelerin güvenilir kabul edilmesi	Piyasa sınırları dışındaki fiyat ve lot manipülasyonu
İş Akışı Atlama	Kullanıcının form adımlarını sırayla takip edeceği kabulü	Uygunluk testi yapmadan kaldıraçlı işlem yetkisi alma
Kampanya Kural Motoru	Kupon kodlarının tek merkezde tekil doğrulandığı varsayımı	Mükerrer komisyon indirimi ve haksız referans kazancı
Geri Alma Mantığı	İptal anında sistemin hatasız eski haline döneceği kabulü	Teminat tutarlarının çift iadesi ve bakiye tutarsızlığı
Parametre Manipülasyonu	Kullanıcının sadece kendi hesap verisini göndereceği kabulü	Başka yatırımcıların portföy ve emir geçmişine izinsiz erişim

Mali ve İdari Riskler

İşlem mantığı zafiyetleri geleneksel veri sızıntılarından farklı sonuçlar doğurur. Çünkü saldırganlar bu açıkları çalıştırdığında sistem loglarında olağan dışı hata görünmez. Sunucu tüm istekleri standart bir HTTP 200 yanıtı ile tamamlar. Bu nedenle ekipler suiistimali ancak mutabakat aşamasında fark eder.

Finansal zararların yanı sıra yasal yaptırımlar da kurumları zorlar. Sermaye Piyasası Kurulu (SPK) düzenlemeleri kurumların bilgi sistemlerini güvenceye almasını emreder. Yetersiz risk kontrolü nedeniyle oluşan bakiye açıkları kurumlara ağır idari cezalar getirir.

Ayrıca yatırımcı güveninin sarsılması telafisi imkansız bir prestij kaybı yaratır. Platformunda bakiye açığı çıkan kurumlar müşteri tabanını hızla kaybeder. Dolayısıyla işlem mantığı güvenliği doğrudan kurumun ticari sürekliliğini belirler.

Adli bilişim süreçleri de bu zafiyetlerde çok zor ilerler. Çünkü log kayıtlarında sisteme sızma veya zararlı kod izi bulunmaz. Her istek meşru bir kullanıcı tarafından normal bir API çağrısı gibi iletilir. Denetçiler kasıtlı suiistimal ile sistem hatasını birbirinden ayırmakta zorlanır.

Bunun yanında takas kurumları nezdinde temerrüt riski doğar. Gerçekte olmayan bir bakiye ile açılan büyük pozisyonlar gün sonunda aracı kurumu borçlandırır. Kurum kendi özkaynaklarından bu açığı kapatmak zorunda kalır ve doğrudan sermaye erimesi yaşar.

Tespit Zorlukları

Otomatik güvenlik tarayıcıları (DAST ve SAST) yalnızca bilinen teknik kod kalıplarını inceler. Örneğin bu araçlar hatalı SQL sorgularını rahatlıkla bulur. Ancak hiçbir yazılım aracı, teminat oranının doğru hesaplanıp hesaplanmadığını anlayamaz.

Çünkü her finansal kurumun iş mantığı, kampanya modeli ve emir akışı farklı kurallar içerir. Bir sistemin güvenliği kurumun belirlediği iş kurallarına dayanır. Bu yüzden mantık açıklarını yalnızca sektörel uzmanlar manuel testlerle ortaya çıkarır.

Güvenlik uzmanları test sırasında platformu bir yatırımcı gözüyle inceler. Ancak uzmanlar yazılımcıların öngörmediği sınır senaryoları dener. Örneğin istek sıralarını bozar, paralel çağrılar gönderir ve mikroservis tutarlılığını analiz eder.

Klasik sızma testleri çoğunlukla OWASP Top 10 başlıklarına odaklanır. Fakat finansal platformlarda asıl tehlike iş akışlarının arkasında saklanır. Test uzmanı sermaye piyasası terimlerini ve emir tiplerini bilmek zorundadır. Sektörel bilgi eksikliği mantık açıklarının raporda yer almamasına neden olur.

Ayrıca test ortamlarının canlı ortamla birebir aynı olmaması tespiti güçleştirir. Canlıdaki veri tabanı yükü ve ağ gecikmeleri test ortamında oluşmaz. Bu nedenle race condition açıkları sadece yüksek işlem trafiğinde ortaya çıkar. Güvenlik ekipleri özel yük ve eş zamanlılık test araçları kullanmalıdır.

Bütüncül Savunma Stratejisi

Ekipler işlem mantığı ve race condition açıklarını önlemek için geliştirme aşamasında sıkı kurallar uygulamalıdır. Kurumların alması gereken temel önlemler şunlardır:

• Veritabanı Satır Kilitleme: Ekipler bakiye ve teminat güncellemelerinde satır düzeyinde kilitleme (pessimistic locking) uygulamalıdır. Böylece aynı kayıt üzerinde aynı anda sadece tek bir işlem çalışır.
• Atomik İşlem Bütünlüğü: Emir iletimi ve bakiye düşümü mutlaka tek bir atomik transaction içinde bitmelidir. Adımlardan biri aksarsa sistem tüm süreci geri almalıdır.
• Sunucu Taraflı Kesin Doğrulama: Ekipler istemciden gelen hiçbir veriyi güvenli saymamalıdır. Sunucu katmanı fiyat limitlerini ve kullanıcı yetkilerini her defasında yeniden hesaplamalıdır.
• Durum Makinesi Mimarisi: Çok adımlı akışlarda her aşama sunucu durumuna bağlanmalıdır. Sistem önceki adımı tamamlamayan kullanıcılara sonraki adımı açmamalıdır.
• Hız ve İstek Sınırlama: Güvenlik katmanı finansal uç noktalara gelen yoğun çağrıları sınırlandırmalıdır. Eş zamanlı gelen milisaniyelik istekler sıraya alınmalıdır.
• Davranışsal Anomali Takibi: Güvenlik sistemleri kullanıcıların sıra dışı işlem sıklığını ve beklenmedik parametre denemelerini anlık olarak izlemelidir.
• İşlem Kimliği (Idempotency Key): Finansal API çağrılarında her istek için benzersiz bir işlem anahtarı üretilmelidir. Sistem mükerrer gelen aynı anahtarlı istekleri reddetmelidir.
• Sıkı Tehdit Modellemesi: Ürün geliştirme aşamasında iş kuralları kötüye kullanım senaryolarına göre denetlenmelidir. Geliştiriciler sadece beklenen senaryoları değil uç riskleri de kodlamalıdır.

Sibertim Güvenlik Metodolojisi

Finansal platformlar için yüzeysel güvenlik taramaları yeterli koruma sağlamaz. Çünkü standart testler derin iş mantığı açıklarını gözden kaçırır. Sibertim, aracı kurumlar ve sermaye piyasası yazılımları için derinlemesine sızma testi hizmeti sunar.

Uzmanlarımız kurumun iş süreçlerini analiz ederek olası mantık hatalarını haritalandırır. Emir iletim döngüleri, marjin hesaplamaları ve çok adımlı müşteri akışları kontrollü test senaryolarıyla incelenir. Böylece potansiyel finansal ve operasyonel riskler platform canlıya geçmeden çözüme kavuşur.

Sibertim metodolojisi sadece teknik zafiyetleri değil, iş akışlarını da baştan sona denetler. Test sürecinde bakiye manipülasyonu, yetkisiz veri erişimi ve eş zamanlı işlem senaryoları titizlikle denenir. Denetim sonunda kuruma özel somut çözüm önerileri ve mimari iyileştirme planı sunulur.

Sık Sorulan Sorular