Privilege Escalation in Aspnet with Bearer Tokens

In ASP.NET APIs, Bearer Tokens are commonly used for stateless authentication via schemes like JWT. Privilege escalation occurs when authorization logic does not properly validate token claims or roles, allowing a lower-privilege token to access higher-privilege endpoints. This can happen when route-based or policy-based authorization is missing or misconfigured, enabling an authenticated user to modify the token’s role claims client-side and elevate permissions.

For example, consider an endpoint intended only for administrators: DELETE /api/admin/users/{id}. If the server only checks that a valid Bearer Token exists and does not enforce a role or scope claim such as roles: admin, an attacker with a standard user token can change the token payload (if unsigned or improperly validated) or simply send a request with an altered Authorization: Bearer <token> header to perform privileged actions. This maps to common OWASP API Top 10 API1:2023 — Broken Object Level Authorization, and can be discovered as a BOLA/IDOR or BFLA/Privilege Escalation finding by middleBrick’s parallel security checks.

ASP.NET’s policy-based authorization provides a strong mitigation when used consistently, but gaps remain. For instance, if policies are defined but not applied to all controllers, or if developers rely on simple role checks via [Authorize(Roles = "Admin")] without validating token issuance, the attack surface persists. middleBrick tests these scenarios by running active probes that submit Bearer Tokens with different claim sets to observe whether authorization is enforced at the endpoint level, ensuring that token-based privileges cannot be abused across scopes.

Another subtle risk involves token binding and audience validation. If an ASP.NET API does not validate the aud (audience) or iss (issuer) claims strictly, a token issued for a less-privileged service might be accepted by the target API, leading to unintended authorization outcomes. middleBrick’s OpenAPI/Swagger analysis, with full $ref resolution, cross-references spec definitions with runtime findings to highlight missing audience or issuer constraints that could facilitate escalation.

Additionally, insecure default configurations in development environments can expose Bearer Token validation to escalation. For example, allowing HTTP instead of HTTPS terminates transport security before token validation, making it easier to tamper with tokens in transit. middleBrick checks encryption and transport settings as part of its parallel scans to ensure tokens are protected end-to-end and cannot be leveraged for privilege escalation via interception or replay.

To remediate privilege escalation with Bearer Tokens in ASP.NET, enforce strict policy-based authorization and validate token claims on every request. Below are concrete code examples demonstrating secure configuration.

1. Define and apply policies with roles and scopes

Use ASP.NET Core’s policy system to require specific roles or scopes, and apply policies globally or per endpoint.

// Program.cs
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.Authority = "https://your-identity-provider";
        options.Audience = "api1";
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true
        };
    });

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("AdminOnly", policy =>
        policy.RequireRole("Admin"));
    options.AddPolicy("ScopeReadUsers", policy =>
        policy.RequireClaim("scope", "users.read"));
});

var app = builder.Build();
app.UseAuthentication();
app.UseAuthorization();

Then secure endpoints with the policy:

[ApiController]
[Route("api/admin")]
public class AdminController : ControllerBase
{
    [HttpDelete("users/{id}")]
    [Authorize(Policy = "AdminOnly")]
    public IActionResult DeleteUser(Guid id)
    {
        // Only users with the Admin role can reach here
        return NoContent();
    }

    [HttpGet("users")]
    [Authorize(Policy = "ScopeReadUsers")]
    public IActionResult ListUsers()
    {
        // Requires scope users.read in the token
        return Ok(new[] { "alice", "bob" });
    }
}

2. Validate issuer and audience explicitly

Ensure tokens are issued for your API and come from a trusted authority by configuring validation parameters.

options.TokenValidationParameters = new TokenValidationParameters
{
    ValidIssuer = "https://your-identity-provider",
    ValidAudience = "api1",
    RoleClaimType = "role",
    NameClaimType = "name"
};

3. Avoid fallback or permissive role checks

Do not use [Authorize(Roles = "Admin,User")] when only admin should act; prefer policies. Avoid using User.IsInRole in business logic without policy enforcement, as this can be bypassed if claims are manipulated.

4. Use HTTPS and enforce transport security

Configure Kestrel and reverse proxies to require HTTPS, preventing token tampering in transit.

// appsettings.json
{
  "Kestrel": {
    "Endpoints": {
      "Https": {
        "Url": "https://0.0.0.0:5001"
      }
    }
  }
}

By combining strict authentication, policy-based authorization, and token claim validation, ASP.NET APIs can securely use Bearer Tokens without enabling privilege escalation. middleBrick’s scans verify these configurations by checking authentication, BFLA/Privilege Escalation, and encryption checks in parallel, providing prioritized findings and remediation guidance.