Arp Spoofing in Aspnet with Saml

Arp spoofing is a Layer 2 network attack where an adversary sends falsified Address Resolution Protocol messages to associate their MAC address with the IP address of a legitimate host, typically the default gateway or another server on the LAN. In an ASP.NET application that relies on SAML for authentication, this attack can subvert identity signals that the framework treats as trusted once the session is established.

Consider an ASP.NET app using SAML via Sustainsys.Saml2 (or similar library). The Service Provider (SP) typically exposes endpoints like /Saml2/Acs (Assertion Consumer Service). If an attacker performs arp spoofing on the network between the user and the server, they can intercept or modify HTTP requests to that endpoint. Because SAML assertions are often validated and then used to establish local session cookies, the attacker who can inject or alter requests may be able to:

• Force the binding of a different recipient or audience, causing signature validation failures or acceptance of forged assertions if other controls are weak
• Observe or alter the RelayState parameter, leading to open redirects or phishing flows that appear legitimate
• Insert or modify SAML messages in transit to escalate privileges or impersonate another identity when the application does not enforce strict transport protections and strict endpoint validation

Crucially, SAML itself relies on HTTPS for integrity and confidentiality. If an ASP.NET deployment allows HTTP or terminates TLS at a load balancer without proper validation, arp spoofing increases the feasibility of stripping or modifying SAML messages. Even with HTTPS, if certificate validation is not enforced strictly (for example, if developers disable RemoteCertificateNameMismatch or RemoteCertificateChainErrors checks), a man-in-the-middle attacker can present a malicious certificate and alter the SAML flow.

ASP.NET’s SAML handling typically expects a valid X.509 certificate to verify the SAML signature. An attacker who successfully spoofs ARP and downgrades or intercepts TLS may replace the SAML response with a crafted one that uses a different certificate, or they may forward requests while modifying the destination URL to point to a malicious endpoint that mimics the SP. Because the local session is often established based on the NameID in the assertion, the attacker may gain access if the application does not also validate the binding between the SAML context and the transport layer session. This is why arp spoofing in a network that serves ASP.NET SAML endpoints is particularly dangerous: it can enable token substitution and RelayState manipulation when transport integrity is assumed but not guaranteed.

Defenses must focus on ensuring SAML message integrity, strict endpoint validation, and transport security. Below are actionable, code-level mitigations for an ASP.NET application using SAML.

1. Enforce HTTPS and strict TLS validation

Ensure all SAML endpoints are available only over HTTPS and that certificate validation is never bypassed.

// In Program.cs or Startup.cs
builder.Services.Configure<Saml2Options>(options =>
{
    options.SPOptions.EntityId = new EntityId("https://sp.example.com/Saml2");
    options.SPOptions.ReturnUrl = new Uri("https://sp.example.com/Saml2/Acs");
    options.IdentityProviders.Add(new IdentityProvider(
        new EntityId("https://idp.example.com/metadata"),
        options.SPOptions)
    {
        MetadataLocation = "https://idp.example.com/federationmetadata/2007-06/federationmetadata.xml"
    });
});

// Enforce HTTPS redirection
app.UseHttpsRedirection();

// In production, enforce certificate validation (do not disable errors)
AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", false);

2. Validate SAML destination and audience strictly

Ensure the SAML destination URL matches the ACS endpoint and that the audience restriction matches the SP entity ID.

services.AddSaml2(options =>
{
    options.SPOptions.EntityId = new EntityId("https://sp.example.com/Saml2");
    options.SPOptions.ReturnUrl = new Uri("https://sp.example.com/Saml2/Acs");
    options.IdentityProviders.Add(new IdentityProvider(
        new EntityId("https://idp.example.com/identityprovider"),
        options.SPOptions)
    {
        MetadataLocation = "https://idp.example.com/federationmetadata/2007-06/federationmetadata.xml",
        // Require destination to match ACS
        WantAssertionsSigned = true,
        LoadCertificates = (sender, args) =>
        {
            args.Certificate = GetTrustedIdpCertificate();
            args.AcceptAllCertificates = false;
        }
    });
});

// Custom validation hook (example using Sustainsys.Saml2)
services.Configure<Saml2Options>(options =>
{
    options.Notifications = new Saml2Notifications
    {
        ValidateDestination = (context, _) =>
        {
            var expected = "https://sp.example.com/Saml2/Acs";
            if (context.Destination != expected)
            {
                context.Result = new Saml2ValidationResult("Invalid destination");
            }
            return context.Result;
        }
    };
});

3. Protect RelayState against tampering

Always validate RelayState to prevent open redirects. Use server-side storage or cryptographic signing for RelayState values.

services.AddSaml2(options =>
{
    options.SPOptions.EntityId = new EntityId("https://sp.example.com/Saml2");
    options.SPOptions.ReturnUrl = new Uri("https://sp.example.com/Saml2/Acs");
    // Example: store RelayState in server-side session and validate on return
    options.Notifications = new Saml2Notifications
    {
        CreatingSignInMessage = (context) =>
        {
            // Generate and store RelayState securely; do not trust client value
            var relayState = GenerateSignedRelayState(context.RelayData);
            context.SignInMessage.RelayState = relayState;
        },
        ProcessingResponse = (context) =>
        {
            if (!ValidateSignedRelayState(context.Saml2Response.RelayState, out var validatedData))
            {
                context.Result = new Saml2ValidationResult("Invalid RelayState");
            }
            // Use validatedData to restore application state
        }
    };
});

4. Verify SAML signature and certificate binding

Ensure the SAML response is signed and the certificate is explicitly validated against a trusted store.

services.AddSaml2(options =>
{
    options.SPOptions.EntityId = new EntityId("https://sp.example.com/Saml2");
    options.SPOptions.ReturnUrl = new Uri("https://sp.example.com/Saml2/Acs");
    options.IdentityProviders.Add(new IdentityProvider(
        new EntityId("https://idp.example.com/identityprovider"),
        options.SPOptions)
    {
        MetadataLocation = "https://idp.example.com/federationmetadata/2007-06/federationmetadata.xml",
        LoadCertificates = (sender, args) =>
        {
            // Pin the certificate thumbprint or load from trusted store
            var cert = GetTrustedIdpCertificate();
            if (cert == null) throw new SecurityTokenException("No trusted certificate");
            args.Certificate = cert;
            args.AcceptAllCertificates = false;
        },
        WantAssertionsSigned = true,
        CheckAuthnRequestSignature = false // typically not needed for SP-initiated SSO
    });
});

5. Session binding and CSRF protections

Bind the SAML session to the local authentication context and protect against CSRF by validating the SAML request ID and timestamps.

services.AddAntiforgery(options => options.HeaderName = "XSRF-TOKEN");

// Ensure SAML requests include and validate InResponseTo and IssueInstant
services.Configure<Saml2Options>(options =>
{
    options.Notifications = new Saml2Notifications
    {
        ProcessingResponse = (context) =>
        {
            // Validate InResponseTo matches the sent AuthnRequest ID
            if (string.IsNullOrEmpty(context.Saml2Response.InResponseTo))
            {
                context.Result = new Saml2ValidationResult("Missing InResponseTo");
                return;
            }
            // Validate timestamps to prevent replay
            var clockSkew = TimeSpan.FromMinutes(5);
            if (context.Saml2Response.CreatedUtc + clockSkew < DateTime.UtcNow ||
                context.Saml2Response.CreatedUtc > DateTime.UtcNow + clockSkew)
            {
                context.Result = new Saml2ValidationResult("Invalid timestamp");
            }
        }
    };
});