Idempotency ve Race Condition Güvenliği

Race condition, backend güvenliğinde en az konuşulan ama en pahalı sonuçlar doğuran hata sınıflarından biridir. Bir endpoint tek tek test edildiğinde güvenli görünebilir; ancak aynı istek milisaniyeler içinde paralel gönderildiğinde ödeme iki kez onaylanabilir, kupon birden fazla kullanılabilir, stok eksiye düşebilir veya limit kontrolü atlanabilir.

Bu hata türü klasik scanner araçlarıyla zor yakalanır çünkü zafiyet syntax hatası değil, zamanlama ve state yönetimi problemidir. Backend'in gerçek davranışı, aynı kaynağa aynı anda gelen istekler altında ortaya çıkar.

Idempotency Neden Güvenlik Kontrolüdür?

Idempotency, aynı işlemin birden fazla kez çağrıldığında aynı güvenli sonucu üretmesidir. Ödeme, sipariş, transfer, refund, subscription update ve data export gibi işlemlerde bu özellik yoksa saldırgan tekrar eden isteklerle sistemi beklenmeyen state'e sokabilir.

Örneğin kullanıcı POST /api/orders isteğini gönderdiğinde timeout alırsa client aynı isteği tekrar yollayabilir. Bu normal bir kullanıcı davranışı da olabilir, saldırganın bilinçli replay denemesi de. Backend idempotency key kullanmıyorsa iki ayrı sipariş, iki ayrı ödeme veya iki ayrı fulfillment süreci oluşabilir.

Sağlıklı bir backend tasarımında idempotency key şu özelliklere sahip olmalıdır:

Kullanıcı veya tenant bağlamına bağlı olmalı.
İşlem türüyle birlikte saklanmalı.
Transaction içinde kontrol edilmeli.
İşlem sonucu ile birlikte kalıcılaştırılmalı.
Belirli süre sonunda güvenli şekilde expire olmalı.

Sadece client tarafından gönderilen key'e güvenmek yeterli değildir. Backend, aynı key'in başka kullanıcı veya tenant tarafından kullanılmasını engellemelidir.

Race Condition Nasıl İstismar Edilir?

Saldırganın amacı genellikle tek bir request'i bozmak değil, aynı request'i paralel çalıştırarak backend'in karar anını yakalamaktır. Örneğin kupon kullanımında sistem önce "kupon kullanılmamış mı?" diye kontrol eder, sonra indirimi uygular, sonra kuponu kullanılmış işaretler. Bu üç adım atomic değilse iki paralel request aynı anda "kupon kullanılmamış" sonucunu alabilir.

Benzer hatalar şu akışlarda sık görülür:

Para transferi ve bakiye düşümü
Stok rezervasyonu
Kupon ve kampanya kullanımı
Trial üyelik başlatma
API quota ve rate limit tüketimi
Dosya export hakkı
Admin approval akışları

Her biri iş mantığına bağlı olduğu için generic güvenlik araçları tarafından kolayca bulunmaz. Gerçek test, uygulama state'ini anlayan ve paralel saldırı senaryosu kuran bir yaklaşım gerektirir.

Transaction Sınırları Yanlışsa Kilitler İşe Yaramaz

Bazı ekipler "database transaction kullanıyoruz" diyerek race condition riskinin kapandığını düşünür. Ancak transaction yanlış yerde başlıyorsa, dış servis çağrıları transaction dışında kalıyorsa veya unique constraint yoksa risk devam eder.

Backend tarafında güvenli tasarım için şu prensipler önemlidir:

Kritik state değişimleri tek transaction içinde yapılmalı.
Unique constraint iş kuralını desteklemeli.
SELECT then UPDATE yerine atomic update tercih edilmeli.
Dış ödeme sağlayıcı çağrıları idempotency ile bağlanmalı.
Retry mantığı aynı yan etkiyi tekrar üretmemeli.
Queue'ya gönderilen mesaj transaction sonucu ile tutarlı olmalı.

Örneğin stok düşme işleminde sadece uygulama kodunda if stock > 0 kontrolü yapmak zayıftır. Daha güvenli yaklaşım, database seviyesinde stock > 0 koşuluyla atomic update yapmak ve etkilenen satır sayısına göre karar vermektir.

API Gateway Race Condition Çözmez

Rate limit faydalıdır ama race condition güvenliğini tek başına çözmez. Saldırgan aynı kullanıcı hesabından, farklı connection'lar üzerinden, düşük sayıda ama doğru zamanlanmış isteklerle zafiyeti tetikleyebilir. WAF veya API gateway bu davranışı her zaman anormal görmeyebilir.

Bu yüzden race condition kontrolü uygulamanın iş mantığı içinde çözülmelidir. Gateway sadece kaba hacmi azaltır; state tutarlılığını garanti etmez.

Test Stratejisi

Backend ekipleri race condition testlerini CI/CD ve güvenlik testlerinin parçası haline getirmelidir. Kritik endpoint'ler için paralel istek testleri, transaction boundary review ve idempotency davranış testleri yazılmalıdır.

Test planında şu sorular bulunmalıdır:

Aynı ödeme isteği 20 kez paralel gönderilirse ne olur?
Aynı kupon iki cihazdan aynı anda kullanılırsa ne olur?
Refund request timeout sonrası tekrar gönderilirse ne olur?
Queue retry aynı yan etkiyi ikinci kez üretir mi?
Admin approval aynı anda iki kişi tarafından işlenirse state bozulur mu?

Eresus Yaklaşımı

Eresus Security, backend sistemlerinde race condition testlerini sadece otomatik yük testi olarak ele almaz. İş akışını, veri modelini, transaction sınırlarını ve exploit edilebilir ekonomik etkiyi birlikte inceler. Özellikle fintech, e-ticaret, SaaS ve abonelik sistemlerinde idempotency hataları doğrudan finansal kayıp veya veri tutarsızlığı yaratabilir.

Backend Development ve Backend Security Engineering çalışmalarında Eresus, kritik iş akışlarınızı hem mimari hem de saldırgan gözüyle değerlendirir. Amaç sadece "race condition var" demek değil, hangi işlemde hangi koşulla nasıl istismar edileceğini ve nasıl kalıcı şekilde düzeltileceğini kanıtlamaktır.

Operasyonel İnceleme Checklisti

Object ownership kontrolü her endpointte var mı?
Tenant ID sunucu tarafında doğrulanıyor mu?
JWT kapsamı gerçek yetkilendirme yerine kullanılmıyor mu?
Webhook ve async job aynı yetki modelini izliyor mu?
Rate limit maliyetli aksiyonlara göre ayrıldı mı?
Admin ve düşük yetkili kullanıcı çapraz test edildi mi?
BOLA ve IDOR senaryoları kanıtla doğrulandı mı?
Provider token kapsamı daraltıldı mı?
Hata cevapları gereksiz veri sızdırıyor mu?
API dokümantasyonu gerçek davranışla uyumlu mu?
Kapsam net yazıldı mı?
Etkilenen varlık sahibi belli mi?
Test ortamı production etkisinden ayrıldı mı?
Kullanıcı rolleri doğru temsil ediliyor mu?
Hassas veri sınıfı tanımlandı mı?
Yetki sınırı teknik olarak doğrulandı mı?
Log kaynağı ve saklama süresi belli mi?
Bulgu tekrar üretilebilir kanıtla destekleniyor mu?
İş etkisi teknik etkiden ayrı açıklandı mı?
Düzeltme sahibi belirlendi mi?
Retest kriteri yazıldı mı?
Benzer risklerin nerelerde tekrar edebileceği kontrol edildi mi?
Monitoring veya alert tarafında görünürlük var mı?
Olay müdahale adımı gerekiyorsa planlandı mı?
Yönetim özeti teknik jargona boğulmadan hazırlanabilir mi?

Sonraki Teknik Adım

Bu checklist tamamlandıktan sonra bulgular önem sırasına göre backlog’a taşınmalı, kritik riskler için retest planı çıkarılmalı ve ilgili servis/hub sayfasına iç bağlantı verilmelidir. Eresus Security bu aşamada kapsam netleştirme, kanıt üretme ve remediation önceliklendirme konusunda teknik ekiplerle birlikte çalışır.

Ek Kontrol Soruları

Bu risk hangi varlıkları etkiliyor?
Hangi kullanıcı rolleri bu akışa erişebiliyor?
Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
Bulgunun müşteri verisine etkisi var mı?
Loglardan olayın izi sürülebiliyor mu?
Düzeltme sonrası retest nasıl yapılacak?
Geçici önlem ile kalıcı çözüm ayrıldı mı?
İş etkisi teknik ekibin dışında da anlaşılır mı?
Benzer hata için önleyici kontrol eklenebilir mi?
Ekip bu kontrolü release sürecine bağlayabilir mi?
Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?