Webhook Spoofing in Aspnet (Csharp)

Webhook spoofing in an ASP.NET application occurs when an attacker can control or predict the URL that the server calls back, causing the application to send sensitive actions or data to a malicious endpoint. In C# ASP.NET, this commonly arises when webhook registrations or callback URLs are derived from user input without strict validation. For example, if a handler accepts a raw callback_url parameter and uses it directly in HttpClient requests or passes it to background services, an attacker can supply a URL they control and intercept or manipulate downstream calls.

ASP.NET’s model binding and dependency injection features can inadvertently simplify spoofing if developers bind user-supplied values to configuration used for outbound calls. Consider a service that accepts a webhook URL to notify third-party systems. If the URL is not validated against an allowlist and lacks verification of the target’s identity (e.g., via a shared secret or signed token), an attacker can redirect notifications to a server they operate. This can lead to unauthorized actions being triggered, such as changing user permissions or exfiltrating data, especially when the webhook is used for privileged operations like payment completion or account updates.

The risk is compounded when the application uses asynchronous patterns or retries, as spoofed endpoints may silently consume retries and appear successful. In C#, common patterns like HttpClient.PostAsJsonAsync or HttpRequestMessage can propagate an untrusted URI if the developer does not sanitize or resolve the endpoint against a trusted set of destinations. Because ASP.NET often runs behind reverse proxies and load balancers, misconfigured headers or forwarded URI logic can further obscure the true destination, making it harder to detect tampering. Attack patterns such as SSRF can also intersect with webhook spoofing if internal services are reachable from the attacker-supplied URL.

To mitigate webhook spoofing in ASP.NET with C#, enforce strict validation and canonicalization of any user-controlled URL used in outbound calls. Prefer configuration-driven or registry-based webhook endpoints rather than runtime-supplied URLs. When dynamic webhooks are necessary, resolve and verify the target against an allowlist of registered domains, and require a cryptographically signed token or shared secret that is validated on the receiving side. In C#, you can encapsulate this logic in a service that normalizes the URI, checks the host against a whitelist, and ensures the scheme is HTTPS.

Below are concrete C# examples demonstrating secure handling in ASP.NET.

Validate and canonicalize the webhook URL

using System;
using System.Net.Http;
using System.Threading.Tasks;

public class WebhookSender
{
    private readonly HttpClient _httpClient;
    private readonly string[] _allowedHosts = { "api.example.com", "hooks.partner.com" };

    public WebhookSender(HttpClient httpClient)
    {
        _httpClient = httpClient;
    }

    public async Task SendEventAsync(string userSuppliedUrl, string payloadJson)
    {
        if (!Uri.TryCreate(userSuppliedUrl, UriKind.Absolute, out var uri))
        {
            throw new ArgumentException("Invalid webhook URL");
        }

        // Ensure HTTPS
        if (uri.Scheme != Uri.UriSchemeHttps)
        {
            throw new ArgumentException("Webhook URL must use HTTPS");
        }

        // Host allowlist check
        var host = uri.Host;
        var isAllowed = false;
        foreach (var allowed in _allowedHosts)
        {
            if (string.Equals(host, allowed, StringComparison.OrdinalIgnoreCase))
            {
                isAllowed = true;
                break;
            }
        }

        if (!isAllowed)
        {
            throw new InvalidOperationException("Webhook host is not authorized");
        }

        // Canonicalize: remove default ports and ensure consistent formatting
        var builder = new UriBuilder(uri)
        {
            Port = uri.IsDefaultPort ? -1 : uri.Port
        };

        var request = new HttpRequestMessage(HttpMethod.Post, builder.Uri)
        {
            Content = new StringContent(payloadJson, System.Text.Encoding.UTF8, "application/json")
        };

        // Include a verified signature if the endpoint expects it
        // request.Headers.Add("X-Signature", ComputeHmac(builder.Uri));

        return await _httpClient.SendAsync(request);
    }
}

Use a registered webhook with signature verification on the receiver

using Microsoft.AspNetCore.Mvc;
using System.Security.Cryptography;
using System.Text;

[ApiController]
[Route("webhooks")]
public class WebhookController : ControllerBase
{
    private const string Secret = "s3cr3t-sh4r3d-k3y";

    [HttpPost("partner")]
    public IActionResult ReceivePartnerWebhook([FromBody] string payload, [FromHeader(Name = "X-Signature")] string signature)
    {
        if (!VerifySignature(payload, signature, Secret))
        {
            return Unauthorized();
        }

        // Process the verified payload
        return Ok();
    }

    private static bool VerifySignature(string payload, string signature, string secret)
    {
        if (string.IsNullOrEmpty(signature)) return false;
        using var hmac = new HMACSHA256(Encoding.UTF8.GetBytes(secret));
        var computed = Convert.ToBase64String(hmac.ComputeHash(Encoding.UTF8.GetBytes(payload)));
        return computed == signature;
    }
}

These patterns enforce host allowlists, HTTPS-only communication, and optional signature verification, reducing the attack surface for webhook spoofing in C# ASP.NET applications.