Webhook Güvenliği: İmza, Replay ve Teslimat Testleri

Kısa cevap

Webhook güvenliği IP allowlist’ten ibaret değildir. Alıcı; isteğin tam içeriğini kriptografik olarak doğrulamalı, olayın güncelliğini kontrol etmeli, meşru tekrar teslimatı çift işleme dönüştürmemeli ve olayın doğru müşteri hesabına ait olduğunu sunucu tarafında kanıtlamalıdır. İnceleme, provider isteğinden kuyruğa ve son iş etkisine kadar uzanmalıdır.

Webhook’lar ödeme, abonelik, kimlik ve e-ticaret sistemlerini bağlar. Bir doğrulama açığı sahte ödeme onayı, hesap etkinleştirme, yinelenen iade veya tenant’lar arası veri karışıklığına dönüşebilir.

Önce güven sınırını çıkarın

Her entegrasyonda olay üreticisini, imza secret’ını, imzalanan bayt dizisini, tenant eşlemesini ve doğrulama sonrası çalışan servisleri kaydedin. İstek endpoint’te kabul edilip kuyruğa yazılıyor ve ayrı bir worker tarafından uygulanıyorsa kimlik ve bütünlük bağlamının her adımda korunduğunu kontrol edin.

İmza doğrulamasını bozarak deneyin

Uygulamanın provider’ın belirttiği kanonik girdi ve ham gövdeyi doğruladığını teyit edin. JSON’u parse edip tekrar serialize etmek alan sırası, boşluk ve sayı biçimi nedeniyle farklı bayt üretebilir. Geçerli test isteğini alın; gövde alanını, imzayı, algoritmayı ve key ID’yi ayrı ayrı değiştirin. Her varyant reddedilmeli ve ödeme veya hesap durumu değişmemelidir.

Middleware hata verdiğinde sistem fail closed olmalıdır. Eksik, bozuk veya bilinmeyen anahtar imzası iş mantığına geçmemelidir. Secret’lar loglarda ya da hata mesajlarında görünmemeli; anahtar rotasyonunda eski ve yeni anahtarların birlikte kabul edildiği pencere sınırlı olmalıdır.

Replay ile retry’ı ayırın

Replay, saldırganın geçmişte geçerli bir isteği yeniden göndermesidir. Retry, provider’ın ağ hatası sonrası aynı olayı tekrar teslim etmesidir. Geçerli isteği kabul penceresi içinde ve dışında tekrar oynatın; timestamp’in imzaya dahil edildiğini ve süresi geçmiş olayın reddedildiğini doğrulayın. Aynı iş etkisini farklı event ID ile üretmeyi de deneyin; event-ID kontrolü içerik doğrulamasının yerine geçmez.

Meşru retry’da idempotency kaydı ile iş etkisi atomik olmalıdır. İşlemden önce tamamlandı işareti koymak olayı kaybettirebilir; işlemden sonra gecikmeli kayıt ise çift iade doğurabilir. Transaction, dayanıklı inbox veya kuyruk tasarımının bu iki hata penceresini kapattığını kanıtlayın.

Tenant ve URL sınırları

Gövde içindeki tenant_id, account_id veya customer_id yetki kanıtı değildir. İmza anahtarının hangi merchant/kuruluma ait olduğunu sunucu belirlemeli ve kaynak kimliğini bu kayıtla eşleştirmelidir. Tenant A anahtarıyla Tenant B kaynağını, silinmiş entegrasyonu, döndürülmüş anahtarı ve test/üretim ortamı karışmasını negatif test edin.

Müşteri tanımlı callback URL’leri ayrı SSRF riski oluşturur. Redirect, DNS değişimi, özel IP, metadata endpoint’i ve protokol kısıtlarını değerlendirin; yalnızca ilk DNS kontrolüne güvenmeyin, gerçek bağlantı hedefini de sınırlandırın.

Retest kontrol listesi

• Geçersiz imza hiçbir yan etki üretmiyor.
• Eski istek reddediliyor; meşru retry yalnızca bir kez işleniyor.
• Tenant çaprazlaması başarısız oluyor.
• Queue, worker ve manuel replay aynı güven modelini uyguluyor.
• Loglar secret içermeden olay ve tenant araştırmasına yetecek kanıt sağlıyor.

Operasyonel dayanıklılık ve bulgu kanıtı

İmza doğrulaması doğru olsa bile kabul edilen olayın sonradan nasıl işlendiği önemlidir. Queue dolduğunda, worker yeniden başladığında veya provider uzun süre retry yaptığında sistemin kaydı kaybetmediğini ve aynı olayı kontrolsüzce çoğaltmadığını inceleyin. Dead-letter kuyruğundan manuel tekrar çalıştırma, normal alım endpoint’inden farklı bir bypass yolu oluşturmamalı; operatör işlemi kimlik doğrulamalı, yetkili ve audit edilebilir olmalıdır.

Bir bulgu raporunda yalnızca “imza kontrolü eksik” demek yerine, test hesabında hangi alanın değiştirildiğini, hangi doğrulamanın geçmediğini ve hangi iş durumunun değiştiğini kanıtlayın. Ödeme entegrasyonunda provizyonu gerçekten tahsilata çevirmeden, sandbox işlemi veya kontrollü test nesnesi kullanın. Etkiyi; sahte olay kabulü, çift işlem, başka tenant’a yönelme veya secret sızıntısı olarak net biçimde sınıflandırın.

İzleme tarafında provider event ID’si, entegrasyon kimliği, tenant, doğrulama sonucu ve işleme durumu korelasyon için yeterlidir. İmza header’ını veya secret’ı loglamak gerekmez. Alarm kuralları; aynı event’in anormal tekrarını, imza hatası artışını, beklenmeyen tenant eşleşmesini ve uzun süre tamamlanmayan kuyruk kaydını kapsamalıdır. Böylece güvenlik kontrolü sadece pentest gününde değil, entegrasyonun yaşam döngüsü boyunca gözlemlenebilir olur.

Olay sözleşmesi ve sürüm değişiklikleri

Provider event şemasını değiştirdiğinde yeni/opsiyonel alanların doğrulama kodunu gevşetmediğini ve bilinmeyen event türlerinin varsayılan olarak hassas işlem başlatmadığını inceleyin. Aynı olayın eski API sürümünden veya farklı content type ile gelmesi için uyumluluk politikasını test edin. Schema doğrulaması imza doğrulamasının yerine geçmez; ancak imzası geçerli bir isteğin beklenmeyen yapıda iş mantığını yanlış dala sokmasını önler. Sürüm yükseltmesinde sandbox regression örnekleri saklayın ve kabul edilen event türlerini açık listeyle sınırlandırın.

Bir webhook endpoint’inin 2xx dönmesi güvenlik başarısı değildir. Retest, iş durumunun değişmediğini ve kabul edilen olayın tek, doğru hesaba ait bir iş etkisine dönüştüğünü kanıtlamalıdır. Daha geniş API incelemesi için API güvenliği değerlendirmemize bakabilirsiniz.