Hızlı cevap: Webhook, bir sistemin bir olay gerçekleştiğinde başka bir sisteme otomatik HTTP isteği göndermesidir (örneğin ödeme alındığında bildirim). Güvenlik açısından webhook'lar iki yönlü risk taşır: webhook'u alan taraf gelen isteğin gerçekten beklenen kaynaktan geldiğini doğrulamalı (imza doğrulama), gönderen taraf ise webhook URL'lerinin iç sistemlere yönlendirilerek SSRF'e dönüşmesini engellemelidir. Temel savunmalar: imza doğrulama, tekrar saldırısı önleme ve URL doğrulama.

Webhook neden özel bir risk?

Webhook'lar, sistemler arası otomasyonun temelidir ama güvenlik açısından sık ihmal edilir. Sorun şudur: webhook'u alan bir uç, internete açık ve kimlik doğrulaması zayıf olabilir. Saldırgan bu uca sahte istekler göndererek sistemi yanıltabilir, örneğin sahte bir "ödeme alındı" bildirimi uydurabilir.

Diğer yönde ise, kullanıcıların webhook URL'si girebildiği sistemler (örneğin bir entegrasyon ayarı), bu URL iç bir adrese yönlendirildiğinde SSRF saldırısına dönüşebilir. Yani webhook hem alırken hem gönderirken dikkat gerektirir.

Webhook güvenlik katmanları

Katman Önlem
İmza doğrulama Gelen her webhook'u paylaşılan sır ile imzalayıp doğrulama (HMAC)
Tekrar saldırısı önleme Zaman damgası ve tek kullanımlık kimlikle eski isteği reddetme
Kaynak doğrulama Yalnızca bilinen gönderici IP ya da kimlikten kabul
SSRF önleme Giden webhook URL'lerinde iç adresleri engelleme
TLS Webhook trafiğini her zaman şifreli taşıma
İş mantığı kontrolü Webhook verisine körü körüne güvenmeme, doğrulama

İmza doğrulama neden kritik?

Webhook güvenliğinin kalbi imza doğrulamadır. Gönderen sistem, her webhook'u paylaşılan gizli bir anahtarla imzalar (genellikle HMAC). Alan sistem aynı anahtarla imzayı doğrular. İmza tutmuyorsa istek reddedilir. Bu, saldırganın sahte webhook göndermesini engeller çünkü gizli anahtar olmadan geçerli imza üretemez. İmza doğrulamayan bir webhook ucu, internetteki herkesin sahte bildirim gönderebileceği açık bir kapıdır.

KAOS ve DSET yaklaşımı

DSET, webhook uçlarının güvenlik denetimini yapar: gelen webhook'lar imza ile doğrulanıyor mu, tekrar saldırısına açık mı, giden webhook URL'leri SSRF'e dönüşüyor mu. Geliştirdiğimiz KAOS güvenlik motoru, imza doğrulamayan webhook uçlarını ve SSRF'e açık URL girişlerini kanıta dayalı değerlendirir. Saha deneyimimizde en sık gördüğümüz sorun, webhook ucunun gelen isteği hiç doğrulamamasıdır. Amacımız webhook'un sahte isteklere açık olup olmadığını göstermektir.

Bağlantılı okumalar: SSRF server-side request forgery korunma, API güvenliği ve OWASP API Top 10, API gateway güvenliği, HMAC ve hash doğrulama, otel rezervasyon ve kanal yöneticisi güvenliği, sızan API anahtarları ve sır yönetimi.

Sık sorulan sorular

Webhook'u nasıl doğrularım? En güvenli yöntem imza doğrulamadır. Gönderen sistem her webhook'u paylaşılan gizli bir anahtarla imzalar (HMAC) ve imzayı bir başlıkta taşır. Alan sistem aynı anahtarla imzayı yeniden hesaplar ve karşılaştırır. Tutmuyorsa istek reddedilir. İmza doğrulamayan bir webhook ucu, sahte bildirimlere açıktır.

Tekrar saldırısı (replay attack) webhook'ta nedir? Saldırgan, geçerli ve imzalı bir webhook'u yakalayıp aynısını tekrar tekrar göndererek işlemi mükerrer tetiklemeye çalışır. Örneğin bir "ödeme alındı" webhook'unu tekrar göndermek. Önlem, webhook'a bir zaman damgası ve tek kullanımlık kimlik eklemek ve alan tarafın eski ya da daha önce işlenmiş istekleri reddetmesidir.

Webhook URL'si nasıl SSRF'e dönüşür? Kullanıcıların webhook URL'si girebildiği bir sistemde, saldırgan bu URL'yi iç bir adrese (örneğin bulut meta veri servisine ya da iç bir API'ye) yönlendirebilir. Sistem o URL'ye istek gönderdiğinde, farkında olmadan iç kaynaklara erişmiş olur. Önlem, giden webhook URL'lerinde iç ve özel adresleri engellemektir.

Kaynaklar

Webhook uçlarınızın güvenlik denetimi için Ankara Hacettepe Teknokent'teki ekibimizle görüşebilirsiniz. DSET ile iletişime geçin.