Webhook Güvenliği: İmza, Tekrar ve Yetki Kontrolleri

Sağlayıcının gerçek imza sözleşmesini okuyun

İmza algoritması, imzalanan veri ve başlık isimleri sağlayıcıya göre farklılaşabilir. Shopify HTTPS teslimatlarında ham gövdeye dayanan HMAC doğrulaması kullanır. [1] Başka sağlayıcının örnek kodunu doğrudan kopyalamak, farklı imza sözleşmesini yanlış uygulayabilir.

Entegrasyon belgesinde ham gövdenin nasıl korunduğu, anahtarın nereden alındığı ve doğrulamanın hangi aşamada yapıldığı yazsın. İstek JSON’a çevrildikten sonra yeniden serileştirilirse aynı baytlar elde edilmeyebilir. Güvenlik kontrolünü iş mantığından önce konumlandırın.

İmza ile tekrar kontrolünü aynı sanmayın

Doğru imzalı mesaj daha önce işlenmiş olabilir. Aynı olayı tekrar almak ikinci para iadesi veya ikinci sipariş oluşturmamalıdır. Teslimat kimliği ve iş olayı kimliği varsa rollerini ayrı belirleyin. İmza geçerli diye her mesajı yeni işlem kabul etmek doğru değildir.

Bazı sağlayıcılar imzalanmış zaman bilgisi ve tazelik kontrolü sunar; Stripe webhook dokümantasyonu bu tür güvenlik ayrıntılarını ele alır. [2] Sağlayıcının imzalamadığı bir zaman alanına güvenerek evrensel tekrar koruması kurmayın. Kullanılan protokolün gerçek destekleri doğrulanmalıdır.

Örnek: geçerli mesaj yeniden gönderiliyor

Varsayımsal sipariş güncellemesi başarıyla işleniyor, fakat alıcı yanıtı sağlayıcıya ulaşmıyor. Sağlayıcı tekrar gönderiyor. Bu olağan yeniden deneme, kötü niyetli tekrar ile aynı biçimde görünebilir. Sistem kararlı kimlikle önceki kaydı tanıyıp güvenli ve tutarlı yanıt verebilmelidir.

Bu tablo savunma tasarımı içindir; belirli bir sistemin güvenli olduğuna dair denetim sonucu değildir. Kontroller üretimden önce yetkili test ortamında doğrulanmalıdır.

Mesajın içeriğini sınırsız yetki olarak kabul etmeyin

Doğrulanmış mesajdaki kaynak kimliği uygulamanızda var mı? İlgili hesap hâlâ etkin mi? Mesajın talep ettiği durum geçişi iş modelinizde mümkün mü? Kaynak doğrulama ile iş yetkilendirmesi ayrı sorulardır. Özellikle çok müşterili sistemlerde mesajın doğru kiracıya yönlendirilmesi kritik önemdedir.

Bir mesajı işleme kuyruğuna alırken doğrulanmış bağlamı kaybedip kullanıcı verisinden yeniden üretmeyin. Kuyruk çalışanı hangi kontrolün daha önce yapıldığını ve hangi kontrolleri kendisinin yapacağını bilmelidir. Güvenlik sorumluluğu servisler arasında belirsiz bırakılmamalıdır.

Anahtar değişimini kesinti senaryosuyla prova edin

Gizli anahtar yenilendiğinde geçiş döneminde hangi anahtarların kabul edileceği sağlayıcı davranışına göre planlanmalıdır. Eski anahtarı süresiz kabul etmek ile ani kesinti yaratmak arasında kontrollü bir geçiş gerekir. Anahtarlar günlüklerde veya hata yanıtlarında görünmemelidir.

Test ortamında yanlış anahtar, eksik imza, bozulmuş içerik, eski mesaj ve yinelenen mesajı deneyin. Doğrulama başarısızken hiçbir iş kaydı veya dış sistem yan etkisi oluşmadığını kontrol edin. Sadece hata kodunun dönmesi yeterli kanıt değildir.

İzleme kayıtlarını güvenli tasarlayın

Hata araştırmak için olay kimliği, kaynak türü ve hata sınıfı çoğu durumda yeterli başlangıç olabilir. Bütün ham yükü süresiz kaydetmek gereksiz kişisel veri ve anahtar sızıntısı riski oluşturabilir. Gerekli saklama kapsamını proje özelinde belirleyin.

Kabul paketinde sağlayıcı sözleşmesi, doğrulama akışı, tekrar politikası ve başarısız mesaj yönergesi bulunsun. Güvenlik ayarlarını geliştirme ortamında kapatıp üretimde unutmayı önleyecek dağıtım kontrolü de eklenmelidir.

Sık sorulan sorular

### HTTPS varsa ayrıca imza gerekir mi? HTTPS aktarımı korur; mesajın uygulamanızın beklediği sağlayıcıdan geldiğini doğrulamak ayrı ihtiyaçtır. Sağlayıcının önerdiği doğrulama yöntemi uygulanmalıdır.

Tekrar gelen bütün mesajları hata olarak mı döndürmeliyim?

Protokole uygun ve yan etki üretmeyen bir davranış seçin. Başarıyla işlenmiş mesajın tekrarını gereksiz hata döngüsüne sokmamak için sağlayıcının yeniden deneme kurallarını inceleyin.