Ssrf in Aspnet with Basic Auth

Server-Side Request Forgery (SSRF) in ASP.NET becomes more nuanced when Basic Authentication is involved. In an unauthenticated black-box scan, middleBrick tests whether an API endpoint can be coerced into making outbound requests to internal or unexpected destinations. When Basic Auth is required by the upstream service, an SSRF-vulnerable endpoint may allow an attacker to supply a target URL that includes embedded credentials (user:pass@host:port). If the backend uses a standard HttpClient or WebRequest and forwards the URL directly, the embedded credentials can be used to reach internal services that otherwise require authentication, bypassing network-level segregation.

For example, an endpoint that accepts a webhook or image URL may receive a payload like http://admin:secret@169.169.169.254/latest/meta-data/iam/security-credentials/. Because the backend includes those credentials in the request, it can retrieve sensitive metadata from cloud provider instance metadata services, which would normally be blocked by firewall rules. middleBrick’s checks for SSRF include testing whether the unauthenticated attack surface allows protocol smuggling to internal endpoints, and whether responses reveal internal data paths or cloud metadata. Even without direct authentication headers, the presence of Basic Auth in the target URL can expose internal systems that are otherwise not reachable, illustrating how improper input validation around user-supplied URLs can combine with credential-bearing requests to create a severe access escalation path.

Another scenario involves authentication headers leaking into SSRF probes. If the ASP.NET application uses default system handlers that pick up proxy or credential managers, an attacker might induce requests that include inherited credentials, escalating the impact. middleBrick’s cross-referencing of OpenAPI specs with runtime findings helps identify whether endpoint definitions declare authentication requirements while runtime tests show the ability to reach internal destinations, highlighting a mismatch between declared security and actual behavior.

Remediation focuses on preventing untrusted input from controlling the request target and ensuring credentials are not embedded in user-supplied URLs. Avoid passing user-provided URLs directly to HttpClient; instead, use a strict allowlist of domains and a validated destination mechanism. When you must call external services, store credentials securely using ASP.NET Core configuration and the Options pattern, and inject them via HttpClientHandler or IHttpClientFactory rather than embedding them in the request URI.

Example: Safe outbound call without embedded credentials

// Program.cs or service registration
builder.Services.AddHttpClient("SecureClient")
    .ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler
    {
        // Credentials are managed by the handler, not the URL
        Credentials = new NetworkCredential(Configuration["Api:User"], Configuration["Api:Password"])
    });

// Usage in a controller or service
public class DataController : ControllerBase
{
    private readonly IHttpClientFactory _clientFactory;
    public DataController(IHttpClientFactory clientFactory) => _clientFactory = clientFactory;

    [HttpPost("fetch")]
    public async Task<IActionResult> FetchExternal([FromBody] ExternalRequest request)
    {
        // Validate host against an allowlist
        var allowedHosts = new[] { "api.trusted.com", "data.example.org" };
        if (!allowedHosts.Contains(new Uri(request.Url).Host))
            return BadRequest("Destination not allowed");

        var client = _clientFactory.CreateClient("SecureClient");
        // Use only the validated path/query; do not forward the raw user URL
        var response = await client.GetAsync(new Uri(request.Url).PathAndQuery);
        response.EnsureSuccessStatusCode();
        var content = await response.Content.ReadAsStringAsync();
        return Ok(content);
    }
}

public class ExternalRequest
{
    public string Url { get; set; } = string.Empty;
}

Example: Rejecting URLs with embedded credentials

private bool IsValidRequestUri(string userSuppliedUrl)
{
    var uri = new Uri(userSuppliedUrl);
    // Reject if userinfo is present in the authority
    if (!string.IsNullOrEmpty(uri.UserInfo))
        return false;
    // Additional checks: host allowlist, scheme (https only), etc.
    return uri.Scheme == Uri.UriSchemeHttps;
}

These patterns ensure that Basic Auth credentials are managed by the runtime or explicitly configured, not concatenated from user input. They also enforce destination validation, which is a primary mitigation for SSRF. middleBrick’s findings can highlight whether embedded credentials are accepted and whether internal endpoints are reachable, enabling teams to align implementation with expected security boundaries.