Out Of Bounds Write in Aspnet with Basic Auth

An Out Of Bounds Write occurs when an application writes data outside the intended memory boundaries, which in the context of ASP.NET often maps to unsafe handling of byte arrays, streams, or buffers passed to framework APIs. When Basic Authentication is used, the Authorization header carries credentials in Base64-encoded form. Although the header itself is not mutable by an unauthenticated scanner, the presence of predictable credentials can change how the application routes or processes requests, indirectly affecting bounds checks.

Consider an endpoint that reads the Authorization header, decodes it, and uses the decoded username or password as an index or size hint for a buffer. If the application trusts the decoded value without validating its length, an attacker can supply a long but valid Base64 string that decodes into a large or crafted payload. Because the scan tests unauthenticated attack surfaces, middleBrick can still trigger code paths where the header is present but unchecked, exposing an Out Of Bounds Write in the parsing or copying logic.

In ASP.NET, this often surfaces in custom middleware or handlers that manipulate streams. For example, reading the request body into a fixed-size buffer and using header-derived values to determine copy length can lead to writes past the allocated memory. Real-world patterns include using the decoded username as an offset for array access or as a chunk size in buffered writes. These patterns violate the principle of validating input length against the destination capacity. OWASP API Top 10 categorizes this under Security Misconfiguration and Improper Input Validation, and it may align with underlying CWE entries related to buffer handling.

middleBrick’s checks include Input Validation and Unsafe Consumption, which test whether the API properly constrains user-influenced data. While the scanner does not execute authenticated scenarios, it can detect missing length validation and large header values that commonly precede such flaws. An OpenAPI spec that defines security schemes but lacks explicit size or format constraints for headers can further mask the risk, making runtime testing essential.

To illustrate, the following snippet shows an ASP.NET endpoint that incorrectly uses a header-derived value to size a buffer, creating an Out Of Bounds Write risk:

using System.IO;
using System.Text;
using Microsoft.AspNetCore.Http;

public class UnsafeBufferMiddleware
{
    private readonly RequestDelegate _next;

    public UnsafeBufferMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        if (context.Request.Headers.TryGetValue("Authorization", out var authHeader))
        {
            // Basic Auth: "Basic base64(credentials)"
            var token = authHeader.ToString().Split(' ')[1];
            var credentialBytes = Convert.FromBase64String(token);
            var credentialString = Encoding.UTF8.GetString(credentialBytes);
            var parts = credentialString.Split(':');
            if (parts.Length == 2 && int.TryParse(parts[1], out var sizeHint))
            {
                // Risk: sizeHint may be larger than the actual buffer
                var buffer = new byte[256];
                context.Request.Body.Read(buffer, 0, sizeHint); // potential out-of-bounds write
            }
        }
        await _next(context);
    }
}

In this example, sizeHint derived from the password portion of Basic Auth is used directly in Read, which can attempt to write beyond the 256-byte buffer if the hint is too large. middleBrick’s Input Validation check would flag missing bounds on sizeHint and unsafe buffer usage.

Additionally, if the API specification does not document the expected format or range for the Authorization-derived values, scanners cannot infer safe constraints. This highlights the importance of combining precise OpenAPI definitions with runtime security checks, a capability emphasized in the Pro plan’s continuous monitoring and GitHub Action integrations that can fail builds when risk scores degrade.

Remediation focuses on removing any dependency on attacker-controlled values for memory operations and ensuring all lengths are validated against fixed limits. Do not use decoded credentials to determine buffer sizes, array indices, or copy counts. Instead, enforce strict boundaries and use safe abstractions provided by the framework.

Below is a corrected version of the previous middleware that validates size hints against a maximum allowed value and uses a fixed destination buffer:

using System.IO;
using System.Text;
using Microsoft.AspNetCore.Http;

public class SafeBufferMiddleware
{
    private const int MaxBufferSize = 256;
    private readonly RequestDelegate _next;

    public SafeBufferMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        const int maxAllowedHint = 1024; // cap on header-derived values
        if (context.Request.Headers.TryGetValue("Authorization", out var authHeader))
        {
            var headerValue = authHeader.ToString();
            if (headerValue.StartsWith("Basic ", StringComparison.OrdinalIgnoreCase))
            {
                var token = headerValue.Substring(6);
                var credentialBytes = Convert.FromBase64String(token);
                var credentialString = Encoding.UTF8.GetString(credentialBytes);
                var parts = credentialString.Split(':');
                if (parts.Length == 2 && int.TryParse(parts[1], out var sizeHint) && sizeHint > 0 && sizeHint <= maxAllowedHint)
                {
                    var buffer = new byte[MaxBufferSize];
                    // Ensure we do not read more than the buffer can hold
                    var bytesRead = context.Request.Body.Read(buffer, 0, Math.Min(sizeHint, MaxBufferSize));
                    // Process only bytesRead; no out-of-bounds access
                }
            }
        }
        await _next(context);
    }
}

Key changes:

• The size hint is capped at a predefined maximum (maxAllowedHint) before being used.
• The actual copy length is bounded by Math.Min(sizeHint, MaxBufferSize), preventing writes beyond the buffer.
• The buffer size is fixed and unrelated to dynamic credential values.

For Basic Auth validation and parsing, prefer built-in mechanisms or well-vetted libraries instead of manual splitting. The following shows a safer pattern using Microsoft.AspNetCore.Authentication.Basic (if available) or at least robust error handling:

using System;
using System.Text.Encodings.Web;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Authentication;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Options;

public class BasicAuthOptions : AuthenticationSchemeOptions { }

public class BasicAuthHandler : AuthenticationHandler<BasicAuthOptions>
{
    public BasicAuthHandler(
        IOptionsMonitor<BasicAuthOptions> options,
        ILoggerFactory logger,
        UrlEncoder encoder,
        ISystemClock clock)
        : base(options, logger, encoder, clock)
    {
    }

    protected override async Task<AuthenticateResult> HandleAuthenticateAsync()
    {
        if (!Request.Headers.ContainsKey("Authorization"))
        {
            return AuthenticateResult.Fail("Missing Authorization Header");
        }

        var authHeader = Request.Headers["Authorization"].ToString();
        if (!authHeader.StartsWith("Basic ", StringComparison.OrdinalIgnoreCase))
        {
            return AuthenticateResult.Fail("Invalid Authorization Header");
        }

        var token = authHeader.Substring(6);
        try
        {
            var credentialBytes = Convert.FromBase64String(token);
            var credentialString = Encoding.UTF8.GetString(credentialBytes);
            var parts = credentialString.Split(':');
            if (parts.Length != 2)
            {
                return AuthenticateResult.Fail("Invalid Credential Format");
            }

            var (username, password) = (parts[0], parts[1]);
            // Validate length of parsed components to avoid downstream misuse
            if (username.Length > 100 || password.Length > 100)
            {
                return AuthenticateResult.Fail("Credential Too Long");
            }

            // Replace with actual user validation logic
            var isValid = ValidateUser(username, password);
            if (!isValid)
            {
                return AuthenticateResult.Fail("Invalid Username or Password");
            }

            var ticket = new AuthenticationTicket(new ClaimsPrincipal(), Scheme.Name);
            return AuthenticateResult.Success(ticket);
        }
        catch (FormatException)
        {
            return AuthenticateResult.Fail("Invalid Base64");
        }
    }

    private bool ValidateUser(string username, string password)
    {
        // Implement secure user store lookup
        return true;
    }
}

This handler validates credential length and avoids using parsed values in memory operations, reducing the risk of boundary violations. It also centralizes Basic Auth logic, making it easier to audit and test.

middleBrick’s CLI can be used to verify that such fixes reduce the risk score: middlebrick scan <url>. For ongoing safety, the Pro plan’s continuous monitoring and GitHub Action integration can enforce that future changes do not reintroduce similar issues.