Arp Spoofing with Oauth2

ARP spoofing (also called ARP poisoning) is a layer‑2 attack where an attacker sends falsified ARP replies to associate their MAC address with the IP address of a legitimate host on the same LAN. When the victim is an OAuth2 client or authorization server, the attacker can become a man‑in‑the‑middle (MITM) for any HTTP traffic that is not protected by TLS.

In an OAuth2 flow the attacker can target three critical moments:

• Authorization request – The client redirects the user‑agent to the authorization endpoint (https://auth.example.com/authorize). If the client uses HTTP or accepts a redirect to an HTTP URL, the attacker can sniff the state parameter, the response_type, and the redirect_uri and then craft a malicious redirect that steals the authorization code.
• Token request – The client exchanges the authorization code for an access token at the token endpoint (https://auth.example.com/token). Without TLS, the attacker can read the authorization code in plaintext and, if the client does not use PKCE, directly request a token.
• Token usage – Access tokens sent in the Authorization: Bearer header can be sniffed and replayed against resource servers that do not enforce token binding or mutual TLS.

Real‑world examples include CVE‑2020-13944, where a misconfigured Spring Security OAuth2 authorization server accepted arbitrary redirect_uri values, allowing an attacker on the same LAN to redirect the victim’s browser to a malicious site after an ARP spoofing‑based MITM. The impact is the same as a classic OAuth2 interception: leakage of authorization codes, access tokens, and refresh tokens, leading to account takeover.

middleBrick does not perform layer‑2 network analysis, but it scans the unauthenticated attack surface of an API and can surface the conditions that make ARP spoofing‑based token theft feasible. When you submit an OAuth2 endpoint URL, middleBrick runs the following relevant checks:

• Transport Security – Flags endpoints that accept HTTP or expose TLS versions < 1.2, because without encryption the attacker can read OAuth2 parameters after ARP spoofing.
• Redirect URI Validation – Analyses the authorization endpoint’s handling of the redirect_uri parameter (via OpenAPI spec and live probing) to detect missing whitelist validation, a prerequisite for the redirect‑URI injection seen in CVE‑2020-13944.
• PKCE Enforcement – Detects whether the token endpoint requires the code_verifier parameter for public clients; absence of PKCE makes authorization‑code theft directly usable.
• Token Binding / Mutual TLS – Checks for the presence of mtls or token-binding headers in token responses; missing bindings indicate that stolen bearer tokens could be replayed.
• Rate Limiting on Token Endpoint – Ensures that brute‑force attempts to guess stolen codes are throttled.

If any of these checks return a finding, middleBrick assigns a severity (typically Medium‑High) and provides remediation guidance. For example, a finding might read:

Authorization endpoint accepts HTTP and does not validate redirect_uri against a whitelist. An attacker on the same LAN could perform ARP spoofing, downgrade to HTTP, and redirect the victim to a malicious site to capture the authorization code.

By addressing the findings, you remove the conditions that let an ARP spoofing attacker turn a network‑level MITM into a full OAuth2 compromise.

The most effective mitigations are built into the OAuth2 specification and its common libraries. Below are concrete examples for a Node.js Express client using simple-oauth2 and a Java Spring Boot resource server.

1. Enforce TLS and Redirect‑URI Whitelisting (Node.js)

const { AuthorizationCode } = require('simple-oauth2');

const client = new AuthorizationCode({
  client: { id: process.env.CLIENT_ID, secret: process.env.CLIENT_SECRET },
  auth: {
    tokenHost: 'https://auth.example.com',
    authorizePath: '/oauth/authorize',
    tokenPath: '/oauth/token',
    // enforce HTTPS – the library will reject any HTTP URLs
  },
  // PKCE is enabled automatically for public clients
  options: { authorizationMethod: 'header' }
});

// Before redirecting, validate redirect_uri against a strict whitelist
function getAuthorizationUrl(state) {
  const redirectUri = 'https://myapp.com/callback';
  const allowed = ['https://myapp.com/callback', 'https://myapp.com/mobile/callback'];
  if (!allowed.includes(redirectUri)) {
    throw new Error('Invalid redirect_uri');
  }
  return client.authorizeURL({
    redirect_uri: redirectUri,
    scope: 'read write',
    state: state
  });
}

// Use the returned URL to redirect the user‑agent (browser)
app.get('/login', (req, res) => {
  const state = crypto.randomBytes(16).toString('hex');
  req.session.oauthState = state;
  res.redirect(getAuthorizationUrl(state));
});

Key points:

• The tokenHost uses https://; the library will throw if an HTTP URL is supplied.
• Redirect‑URI is checked against a hard‑coded whitelist before the authorization URL is built.
• PKCE is enabled by default for public clients, preventing reuse of a stolen authorization code.

2. Enforce Mutual TLS on the Token Endpoint (Spring Boot)

@Configuration
@EnableResourceServer
public class ResourceServerConfig extends ResourceServerConfigurerAdapter {

    @Override
    public void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
                .antMatchers("/api/**").authenticated()
            .and()
            .oauth2ResourceServer()
                .jwt()
                .jwtAuthenticationConverter(jwtAuthenticationConverter());

        // Require client certificate for token endpoint
        http.requiresChannel()
            .antMatchers("/oauth/token")
            .requiresSecure()
            .and()
            .x509()
                .subjectPrincipalRegex("CN=(.*?)")
                .userDetailsService(certificateUserDetailsService());
    }
}

This configuration forces TLS with client‑certificate authentication on the /oauth/token endpoint. Even if an attacker performs ARP spoofing and can read the traffic, they cannot present a valid client certificate, so the token request is rejected.

3. Additional Defensive Measures

• Enable Signed OAuth2 Requests (RFC 9068) or DPoP to bind access tokens to the client’s key.
• Short‑lived access tokens (e.g., 5‑10 minutes) combined with refresh‑token rotation limit the window for replay.
• Monitor logs for sudden spikes in token‑endpoint failures; middleBrick’s continuous monitoring (Pro plan) can alert on such anomalies.

By applying these OAuth2‑native controls, you eliminate the exploitable conditions that ARP spoofing relies on, turning a network‑level MITM into a harmless event.