Webhook, bir sistemin başka bir sisteme "şu an bir şey oldu" demesinin en basit yoludur. Bir ödeme altyapısı tahsilatın tamamlandığını, bir form aracı yeni bir talep geldiğini veya bir iş ortağı belge durumunun değiştiğini webhook ile bildirir. Basitliği büyük bir avantajdır; ama aynı basitlik, webhook uç noktalarını dışarıya açık kapılar haline de getirir. Bu yazı, acente yazılımına gelen webhook çağrılarının güvenle kabul edilmesi için gereken teknik kontrolleri sırasıyla ele alıyor.
Webhook uç noktası neden risklidir?
Webhook adresi, internet üzerinden erişilebilen bir URL'dir. Adresi öğrenen herkes bu adrese istek gönderebilir. Kontrolsüz bir uç noktada şu senaryolar gerçekleşebilir:
- Sahte bir "tahsilat tamamlandı" bildirimiyle ödenmemiş bir kaydın ödenmiş görünmesi
- Eski ve geçerli bir isteğin kaydedilip tekrar tekrar gönderilmesi
- Çok sayıda istekle sistemin kuyruğunun doldurulması
Bu risklerin her biri farklı bir katmanda çözülür. Tek bir önlem yeterli değildir.
Birinci katman: HMAC imza doğrulama
Yaygın ve etkili yöntem, gönderen ile alıcının paylaştığı gizli bir anahtarla isteğin gövdesini imzalamaktır. Gönderen taraf, ham istek gövdesinin HMAC-SHA256 özetini hesaplar ve bir başlıkta iletir. Alıcı taraf aynı hesaplamayı kendi tarafında yapar ve iki değeri karşılaştırır.
Uygulamada dikkat edilecek ayrıntılar
- Ham gövdeyi kullanın: JSON'u ayrıştırıp yeniden serileştirmek boşluk ve alan sırasını değiştirebilir. İmza, isteğin byte düzeyindeki ham haliyle hesaplanmalıdır.
- Sabit zamanlı karşılaştırma yapın: Basit metin karşılaştırması, zamanlama farkları üzerinden bilgi sızdırabilir. Dillerin sunduğu güvenli karşılaştırma fonksiyonları tercih edilmelidir.
- Anahtarı koddan ayırın: Gizli anahtar kaynak kodda değil, ortam değişkeninde veya bir gizli bilgi kasasında tutulmalıdır.
- Anahtar rotasyonunu planlayın: Geçiş döneminde eski ve yeni anahtarın ikisini birden kabul edebilen bir yapı, kesintisiz değişim sağlar.
İkinci katman: Zaman damgası penceresi
İmza, mesajın değiştirilmediğini kanıtlar; ancak mesajın ne zaman gönderildiğini kanıtlamaz. Bir saldırgan geçerli bir isteği yakalayıp günler sonra tekrar gönderirse imza yine doğru çıkar. Bu yüzden gönderen taraf, isteğe bir zaman damgası ekler ve bu damgayı da imzanın içine dahil eder.
Alıcı taraf, damganın kabul edilebilir bir pencere içinde olup olmadığını kontrol eder. Pencere çok dar tutulursa sunucular arasındaki küçük saat farkları meşru istekleri reddettirir; çok geniş tutulursa tekrar saldırılarına alan açılır. Sunucu saatlerinin NTP ile eşitlenmesi bu dengenin ön koşuludur.
Üçüncü katman: Tekrar koruması
Zaman penceresi içinde bile aynı isteğin iki kez işlenmemesi gerekir. Bunun için her webhook mesajı benzersiz bir kimlik taşımalıdır. Alıcı, işlediği kimlikleri pencere süresi boyunca kısa ömürlü bir depoda tutar. Aynı kimlik yeniden gelirse istek kabul edilir ama iş mantığı ikinci kez çalıştırılmaz.
Bu yaklaşım yalnızca saldırılara karşı değil, gönderenin kendi yeniden deneme mekanizmasına karşı da korur. Birçok servis, yanıt alamadığında aynı bildirimi birkaç kez gönderir. Tekrar koruması olmayan bir uç noktada bu, mükerrer tahsilat kaydı veya mükerrer görev anlamına gelir.
Dördüncü katman: Hızlı yanıt ve arka planda işleme
Webhook gönderen sistemler genellikle kısa bir süre içinde başarılı yanıt bekler. Alıcı, isteği doğruladıktan sonra hemen kabul yanıtı dönmeli ve asıl işi bir kuyruğa bırakmalıdır. Uzun süren işlemleri webhook isteğinin içinde yapmak, zaman aşımı ve gereksiz yeniden denemeler doğurur.
Ek savunma önlemleri
- Yalnızca HTTPS: Şifrelenmemiş kanaldan gelen istekler hiç kabul edilmemelidir.
- Gövde boyutu sınırı: Beklenmedik büyüklükteki istekler daha ayrıştırılmadan reddedilmelidir.
- Hız sınırlama: Tek bir kaynaktan gelen aşırı istekler kısılmalıdır.
- Kaynak IP listesi: Gönderen servis sabit IP aralıkları yayınlıyorsa ek bir filtre olarak kullanılabilir; ancak imzanın yerini tutmaz.
- Kayıt tutma: Reddedilen istekler, nedenleriyle birlikte loglanmalıdır. Bu kayıtlar hem hata ayıklama hem de güvenlik incelemesi için değerlidir.
Gönderen taraf olduğunuzda sorumluluklar
Acente yazılımı yalnızca webhook almaz; bazı durumlarda kendisi de webhook gönderir. Örneğin bir acente, poliçe kaydedildiğinde kendi muhasebe aracına veya iç raporlama sistemine bildirim gitmesini isteyebilir. Bu durumda güvenlik sorumluluğu yer değiştirir ve gönderen tarafın da bazı kurallara uyması gerekir:
- Her abonelik için ayrı bir gizli anahtar üretilmeli; bir acentenin anahtarı başka bir acentenin bildirimlerini doğrulamakta kullanılamamalıdır.
- Hedef adres yalnızca HTTPS olmalı ve iç ağ adreslerine yönlendirme engellenmelidir. Aksi halde webhook özelliği, sunucunun iç servislerine erişmek için kötüye kullanılabilir.
- Başarısız gönderimler artan aralıklarla yeniden denenmeli, belirli bir denemeden sonra durdurulup kullanıcıya bildirilmelidir.
- Gönderim geçmişi; zaman, yanıt kodu ve deneme sayısıyla birlikte panelde görüntülenebilmelidir.
Test ortamında webhook doğrulamak
Webhook güvenliği, yalnızca canlı ortamda fark edilen bir konu olmamalıdır. Test aşamasında imzası bozuk bir istek, süresi geçmiş bir zaman damgası ve aynı kimlikle iki kez gönderilen bir mesaj bilinçli olarak denenmelidir. Bu üç negatif senaryonun her birinde sistemin beklenen şekilde reddetmesi ve bunu loglaması, katmanların gerçekten çalıştığını gösterir.
Hata yanıtlarını doğru seçmek
Doğrulamadan geçemeyen isteklere verilen yanıt kodu da önemlidir. İmza hatası veya süresi geçmiş zaman damgası için kalıcı hata kodları dönülmeli, gönderen tarafın boşuna yeniden denemesine yol açılmamalıdır. Buna karşılık sistem geçici olarak meşgulse geçici hata kodu dönmek, gönderenin isteği daha sonra tekrar iletmesini sağlar. Yanıt gövdesinde hangi kontrolün başarısız olduğunu ayrıntılı açıklamak ise saldırgana ipucu verebileceği için kısa ve genel tutulmalıdır.
Acente yazılımı açısından değerlendirme
InsureHub gibi acentelere yazılım sağlayan bir platformda webhook'lar; web sitesi formları, ödeme bildirimleri ve iş ortağı sistemlerinden gelen durum güncellemeleri için kullanılabilir. Bu verilerin Acente CRM kayıtlarına ve sigorta acentesi yazılımı içindeki iş akışlarına güvenle girmesi, yukarıdaki katmanların birlikte çalışmasına bağlıdır.
Kendi entegrasyonlarınızı gözden geçirirken kısa bir kontrol yapabilirsiniz: İmza ham gövde üzerinden mi doğrulanıyor, zaman damgası imzaya dahil mi, mesaj kimliği tekrarları engelliyor mu, iş mantığı kuyruğa mı bırakılıyor? Bu dört sorudan birine "hayır" cevabı veriliyorsa, önceliği o katmana vermek gerekir.