Container Escape in Aspnet with Bearer Tokens

A container escape in an ASP.NET application that relies on Bearer token authentication occurs when an attacker who has obtained or manipulated a token gains the ability to interact with the host container’s runtime or underlying host resources. This specific combination is risky because Bearer tokens are typically passed in the Authorization header and are accepted by many endpoints without additional host context checks. If the application processes tokens in a way that grants elevated host-level permissions (for example, invoking host binaries, mounting sensitive volumes, or accessing the Docker metadata service), an authenticated request can lead to container escape.

Consider an ASP.NET Core API that accepts a Bearer token and, based on claims or scopes, conditionally runs a privileged process or reads files from paths constructed using user input. An attacker could leverage a valid token to exploit such logic and read host files like /var/run/docker.sock or execute commands on the host. Because the scan tests unauthenticated attack surfaces where possible, middleBrick flags endpoints that accept Bearer tokens yet expose host-sensitive operations without proper authorization checks.

Attack patterns relevant here include insecure deserialization if tokens are embedded in serialized objects, and over-privileged service accounts inside the container. If the container runs with capabilities such as SYS_ADMIN or mounts the host filesystem, a compromised token can be used to traverse into host namespaces. OWASP API Top 10 items such as Broken Object Level Authorization (BOLA) and Security Misconfiguration intersect with this scenario. A misconfigured API route that trusts the Bearer token alone, without validating the token’s intended audience or binding the request to a safe execution context, can inadvertently expose host-level operations.

Real-world references include CVE scenarios where token validation is incomplete and container breakout is possible via exposed runtime endpoints. For instance, an API that uses token claims to decide whether to invoke a host-side helper binary without path validation may allow an attacker to supply a malicious path and achieve code execution on the host. This illustrates why mapping findings to frameworks like OWASP API Top 10 and PCI-DSS is important when assessing APIs that use Bearer tokens in containerized environments.

middleBrick detects such issues by running checks in parallel, including Authentication, BOLA/IDOR, Property Authorization, and Unsafe Consumption. It reviews how Bearer tokens are accepted, how authorization is enforced, and whether runtime behaviors expose host resources. The scanner cross-references OpenAPI/Swagger specs with runtime findings, ensuring that declared security schemes align with actual endpoint behavior. This helps teams see whether token acceptance is narrowly scoped or overly permissive.

Remediation focuses on strict token validation, minimizing token scope, and ensuring that token usage does not implicitly grant host-level operations. In ASP.NET Core, prefer policy-based authorization and avoid using token claims to gate dangerous host interactions. Always validate the token audience, issuer, and scopes, and bind authorization decisions to resource ownership rather than token privileges alone.

Example of insecure token usage to avoid:

// Insecure: using token scope to decide host file access
[Authorize]
[HttpGet("/files/{name}")]
public IActionResult GetFile(string name)
{
    var scope = User.FindFirst("scope")?.Value;
    if (scope == "read_files")
    {
        var path = $"/host-data/{name}";
        return PhysicalFile(path, "application/octet-stream");
    }
    return Forbid();
}

The above example is vulnerable because a valid Bearer token with the read_files scope can read arbitrary host files via path traversal. An attacker with a valid token can supply ../../../etc/passwd as the name and access sensitive host files, potentially enabling container escape.

Secure alternative with concrete code:

// Secure: validate ownership and sanitize paths; do not rely on token scopes for host access
[Authorize]
[HttpGet("/documents/{documentId}")]
public async Task<IActionResult> GetDocument(Guid documentId, ClaimsPrincipal user)
{
    // Map document to a tenant/user and ensure the token’s subject owns it
    var userId = user.FindFirst(ClaimTypes.NameIdentifier)?.Value;
    if (string.IsNullOrEmpty(userId))
    {
        return Forbid();
    }

    var document = await _context.Documents
        .FirstOrDefaultAsync(d => d.Id == documentId && d.OwnerId == userId);
    if (document == null)
    {
        return NotFound();
    }

    // Serve the file from an application-controlled location, not directly from host paths
    var filePath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "document_storage", document.FileName);
    if (!System.IO.File.Exists(filePath))
    {
        return NotFound();
    }
    return PhysicalFile(filePath, "application/octet-stream", document.FileName);
}

This approach ensures that token validation is combined with resource ownership checks and that file paths are constructed from trusted sources rather than user input. It also avoids using token claims to authorize host-level filesystem access, reducing the risk of container escape.

Additional measures include restricting container capabilities, avoiding mounts of sensitive host paths, and using read-only filesystems where possible. middleBrick’s checks for Authentication, Authorization, and Unsafe Consumption help surface endpoints that accept Bearer tokens while performing risky operations, enabling teams to apply these patterns iteratively.