Arp Spoofing in Aspnet with Openid Connect

Arp spoofing is a Layer 2 attack where an adversary sends falsified ARP messages to associate their MAC address with the IP of a legitimate host, typically the gateway or another service in the network path. In an ASP.NET application that uses OpenID Connect for authentication, arp spoofing can expose critical security risks when network-level protections are absent. Even though OpenID Connect operates at the application layer over HTTPS, an attacker on the same local network can intercept and manipulate traffic by poisoning ARP tables, redirecting the victim’s traffic through their machine.

When OpenID Connect is used in ASP.NET, the browser is redirected to an identity provider for authentication, and authorization codes or tokens are returned over HTTPS. However, arp spoofing can enable session hijacking by intercepting authorization codes or tokens if transport security is not properly enforced or if the attacker combines ARP spoofing with additional techniques like SSL stripping or downgrade attacks. In scenarios where HTTPS is not strictly enforced or mixed content is allowed, intercepted HTTP traffic might leak tokens or redirect URIs. Moreover, an attacker can use arp spoofing to redirect traffic to a rogue proxy that terminates TLS improperly, enabling visibility into metadata or authentication flows that should remain protected.

The combination of arp spoofing and OpenID Connect in ASP.NET is particularly concerning during the token exchange phase. If the application does not validate the token endpoint host strictly or does not use certificate pinning, an attacker can intercept the token response and extract sensitive information. Because OpenID Connect relies on redirect URIs and state parameters to prevent CSRF, arp spoofing alone does not break the protocol, but it can facilitate auxiliary attacks that weaken the overall security posture. Therefore, network-level defenses such as static ARP entries, port security, or encrypted channels (e.g., VPNs) are essential complements to OpenID Connect implementation in ASP.NET.

Middleware components in ASP.NET that handle OpenID Connect, such as UseOpenIdConnectAuthentication in older templates or AddOpenIdConnect in modern setups, assume a secure network boundary. Arp spoofing violates that assumption by allowing an attacker to position themselves within that boundary. While the protocol itself remains intact, the environment’s integrity is compromised. This makes it crucial to ensure that ASP.NET applications using OpenID Connect are deployed in networks with proper Layer 2 security controls, such as disabling unused ports, enabling dynamic ARP inspection on switches, and isolating authentication traffic onto separate VLANs.

Detection of arp spoofing typically involves monitoring ARP replies for inconsistencies or using network-based intrusion detection systems. For applications, the consequence is not direct exploitation of OpenID Connect cryptographic properties, but rather the exposure of authentication artifacts that travel across the compromised link. Therefore, defense in depth is required: secure coding practices for OpenID Connect in ASP.NET must be paired with network security measures to mitigate the risk introduced by arp spoofing.

Securing OpenID Connect in ASP.NET against arp spoofing and related network attacks requires a combination of protocol hardening, transport security, and runtime configuration. The following code examples demonstrate concrete remediation steps that align with best practices and reduce the attack surface exposed by ARP-based attacks.

1. Enforce HTTPS and Secure Redirect URIs

Ensure that all communication with the OpenID Connect provider occurs over HTTPS and that redirect URIs are explicitly defined and limited to HTTPS endpoints. This prevents token interception over insecure channels.

services.AddAuthentication(options =>
{
    options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
})
.AddCookie()
.AddOpenIdConnect(options =>
{
    options.Authority = "https://auth.example.com";
    options.ClientId = "my-client-id";
    options.ResponseType = "code";
    options.SaveTokens = true;
    options.RequireHttpsMetadata = true; // Enforce HTTPS for metadata retrieval
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuer = true,
        ValidIssuer = "https://auth.example.com",
        ValidateAudience = true,
        ValidAudience = "my-client-id",
        ValidateLifetime = true
    };
    options.Events = new OpenIdConnectEvents
    {
        OnRedirectToIdentityProvider = context =>
        {
            context.ProtocolMessage.RedirectUri = EnsureHttps(context.ProtocolMessage.RedirectUri);
            return Task.CompletedTask;
        }
    };
});

string EnsureHttps(string uri)
{
    if (!uri.StartsWith("https://", StringComparison.OrdinalIgnoreCase))
        throw new InvalidOperationException("Redirect URI must use HTTPS.");
    return uri;
}

2. Strict Token Validation and Issuer Checks

By strictly validating the issuer and audience, you reduce the risk that tokens issued to a malicious party due to network manipulation are accepted by your application.

services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddOpenIdConnect(options =>
    {
        options.Authority = "https://secure-identity-provider.com";
        options.ClientId = "web-client";
        options.ResponseType = "code";
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidIssuer = "https://secure-identity-provider.com",
            ValidateAudience = true,
            ValidAudience = "web-client",
            ValidateLifetime = true,
            ClockSkew = TimeSpan.FromMinutes(2)
        };
        options.RequireHttpsMetadata = true;
    });

3. Use Back-Channel Token Validation

Instead of relying solely on the discovery document retrieved over HTTP (if misconfigured), enforce back-channel token validation and metadata retrieval over HTTPS. This prevents tampering via ARP spoofing that might redirect metadata requests.

services.AddAuthentication()
    .AddOpenIdConnect(options =>
    {
        options.Authority = "https://login.example.com";
        options.RequireHttpsMetadata = true;
        options.Configuration = new OpenIdConnectConfiguration
        {
            Issuer = "https://login.example.com",
            TokenEndpoint = "https://login.example.com/connect/token"
        };
    });

4. Network Hardening and Defense in Depth

While not code, it’s important to configure the hosting environment to mitigate ARP spoofing. Use dynamic ARP inspection on network switches, enforce port security, and isolate authentication traffic. In cloud environments, use private subnets and security groups to limit lateral movement.

5. State and Nonce Validation

OpenID Connect uses the state and nonce parameters to prevent CSRF and replay attacks. Ensure these are validated strictly to prevent attackers from forging authentication responses even if they intercept network traffic.

services.AddOpenIdConnect(options =>
{
    options.SaveTokens = true;
    options.GetClaimsFromUserInfoEndpoint = true;
    options.ResponseType = "code id_token";
    options.UseNonce = true;
    options.UsePkce = true;
});