Clickjacking in Aspnet with Basic Auth

Clickjacking is a client-side injection vulnerability where an attacker tricks a user into interacting with a hidden UI element inside an invisible or disguised iframe. In an ASP.NET application that uses HTTP Basic Authentication, embedding the application inside an iframe can expose a dangerous combination: the browser automatically sends stored credentials with the request, and the user may be unaware they are performing an authenticated action on a different origin. Because Basic Auth credentials are transmitted with each request to the protected origin, a malicious site that loads the app in a hidden iframe can leverage the user’s existing authentication state without their knowledge.

Consider a scenario where an ASP.NET app at https://api.example.com/dashboard uses Basic Auth and does not set appropriate framing protections. An attacker crafts a page that loads this endpoint inside an invisible iframe and overlays interactive elements (e.g., a button that triggers a fund transfer) on top of it. When the user visits the attacker’s site while logged in via Basic Auth (credentials cached by the browser), the forged UI actions are executed in the context of the authenticated session. Because Basic Auth relies on the browser to manage and send the Authorization header automatically, there is no additional user prompt, making the attack seamless.

ASP.NET does not inherently prevent pages from being rendered in frames unless explicit anti-framing defenses are implemented. The presence of Basic Auth amplifies the impact: if an app is reachable while authenticated and lacks X-Frame-Options or Content-Security-Policy frame-ancestors rules, an attacker can perform actions with the victim’s privileges. This is especially relevant for state-changing endpoints (POST, PUT, DELETE) that do not require a CSRF token or same-origin checks, as the browser will include the Basic Auth header regardless of the framing context. The attack does not require stealing credentials; it exploits the automatic inclusion of those credentials by the browser when the embedded resource is requested.

Note that middleBrick scans can detect whether an endpoint that uses Basic Auth sends the proper framing headers and whether the unauthenticated attack surface allows UI injection vectors. By testing headers and inline behaviors without authentication, the scanner highlights missing defenses such as the absence of X-Frame-Options or Content-Security-Policy, which are critical to mitigating clickjacking in this scenario.

To mitigate clickjacking in ASP.NET applications that use Basic Auth, you must prevent the application from being embedded in frames and ensure that authentication does not silently authorize cross-origin actions. The most direct defenses are anti-framing headers and strict CSP policies. Below are concrete code examples for both approaches.

1) Set X-Frame-Options header

The X-Frame-Options header instructs browsers on whether a page can be displayed in a frame. Use DENY or SAMEORIGIN depending on whether you ever need to embed the app in a frame on your own domain.

// In Startup.cs or Program.cs for ASP.NET Core
app.Use(async (context, next) =>
{
    context.Response.Headers.Add("X-Frame-Options", "DENY");
    await next.Invoke();
});
app.UseStaticFiles();
app.UseRouting();
// ... rest of pipeline

2) Use Content-Security-Policy frame-ancestors

For modern browsers, Content-Security-Policy (CSP) provides finer-grained control. The frame-ancestors directive replaces X-Frame-Options and allows you to specify which origins can embed the page.

// In Startup.cs or Program.cs for ASP.NET Core
app.Use(async (context, next) =>
{
    context.Response.Headers.Add("Content-Security-Policy", "frame-ancestors 'none'");
    await next.Invoke();
});

If you need to allow frames from specific domains (for example, a trusted portal), adjust the directive accordingly:

context.Response.Headers.Add("Content-Security-Policy", "frame-ancestors 'self' https://trusted.example.com");

3) Example Basic Auth endpoint with protections

Below is a minimal authenticated endpoint using Basic Auth, with headers applied to reduce clickjacking risk. This example demonstrates how to combine authentication and framing defenses in ASP.NET Core.

// Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddAuthentication("Basic")
    .AddScheme("Basic", null);
builder.Services.AddAuthorization();
var app = builder.Build();

app.Use(async (context, next) =>
{
    context.Response.Headers.Add("X-Frame-Options", "DENY");
    context.Response.Headers.Add("Content-Security-Policy", "frame-ancestors 'none'");
    await next();
});
app.UseAuthentication();
app.UseAuthorization();

app.MapGet("/dashboard", () => "Secure Dashboard")
    .RequireAuthorization();

app.Run();

public class BasicHandler : AuthenticationHandler
{
    public BasicHandler(
        IOptionsMonitor options,
        ILoggerFactory logger,
        UrlEncoder encoder,
        ISystemClock clock)
        : base(options, logger, encoder, clock) { }

    protected override async Task 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 credentialString = Encoding.UTF8.GetString(Convert.FromBase64String(authHeader.Substring(6)));
        var credentials = credentialString.Split(':', 2);
        if (credentials.Length != 2)
            return AuthenticateResult.Fail("Invalid Credentials");

        // Replace with secure user validation logic
        if (credentials[0] == "admin" && credentials[1] == "password123")
        {
            var claims = new[] { new Claim(ClaimTypes.Name, credentials[0]) };
            var identity = new ClaimsIdentity(claims, Scheme.Name);
            var principal = new ClaimsPrincipal(identity);
            var ticket = new AuthenticationTicket(principal, Scheme.Name);
            return AuthenticateResult.Success(ticket);
        }

        return AuthenticateResult.Fail("Invalid Username or Password");
    }
}

4) Additional recommendations

• Avoid caching pages that contain sensitive actions if they are served with Basic Auth; use Cache-Control: no-store to prevent intermediaries from storing responses.
• Ensure that all sensitive endpoints require authentication and that the Basic Auth credentials are transmitted only over HTTPS to prevent credential leakage.
• Consider replacing Basic Auth with token-based mechanisms where feasible, reducing the risk of credentials being automatically sent in frames or insecure contexts.

By combining framing defenses with secure transport and proper authentication handling, you reduce the window for clickjacking against endpoints protected by Basic Auth in ASP.NET.