Dns Cache Poisoning with Bearer Tokens

Bearer token validation often relies on a remote introspection or userinfo endpoint to confirm that a token is still active and has not been revoked. When an application builds the URL for that endpoint from a configurable host string, a successful DNS cache poisoning attack can cause the resolver to return an attacker‑controlled IP address for the legitimate host. The application then sends the bearer token (and sometimes client credentials) to the malicious server, which can harvest the token, replay it, or use it to escalate privileges.

Typical vulnerable code paths include:

• Fetching token introspection from a base URL stored in an environment variable without any additional validation.
• Using a hardcoded hostname but trusting the OS DNS resolver without DNSSEC validation or certificate pinning.
• Calling a third‑party userinfo endpoint (e.g., OAuth2 provider) where the hostname is derived from a discovery document that itself could be poisoned.

Example of a vulnerable Node.js snippet that builds the introspection URL from a config value:

// config.introspectionEndpoint = process.env.AUTH_INTROSPECTION_URL
const response = await fetch(`${config.introspectionEndpoint}`, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ token: bearerToken })
});
const data = await response.json();
if (!data.active) { throw new Error('Invalid token'); }

If an attacker poisons the DNS for the host in process.env.AUTH_INTROSPECTION_URL, the fetch call goes to the attacker’s server, leaking the bearer token.

Detecting this issue requires checking whether the application validates the authenticity of the endpoint it contacts for token validation. Indicators of risk include:

• The token validation endpoint URL is constructed solely from user‑controlled or environment‑derived strings without an allow‑list of approved hosts.
• No certificate pinning, DNSSEC verification, or strict TLS hostname validation is performed.
• The application relies on a remote introspection service instead of locally verifying the token signature (JWT).

middleBrick can help discover these conditions during its unauthenticated black‑box scan. When you submit the base URL of your API, middleBrick probes common token introspection paths (e.g., /oauth/introspect, /userinfo, /auth/token/introspect) and reports:

• Whether the endpoint returns token details without requiring authentication (a sign that the endpoint is exposed).
• If the response contains sensitive fields such as access_token, scope, or client_id that could be harvested by an attacker.
• Any missing security headers (e.g., Strict-Transport-Security) that would mitigate man‑in‑the‑middle attacks.

You can run a quick check from the terminal using the middleBrick CLI:

middlebrick scan https://api.example.com/oauth/introspect

The output will include a severity rating for the "Token Endpoint Exposure" finding, along with remediation guidance.

Fixing DNS cache poisoning in the context of bearer token validation involves two layers: ensuring the application reaches the genuine authentication server and reducing reliance on remote validation where possible.

1. **Validate the endpoint’s identity** – enforce strict TLS hostname verification and, if feasible, pin the server’s certificate or use DNSSEC‑validated resolvers. In Node.js, the built‑in https module already validates certificates when rejectUnauthorized is set to true (the default). Explicitly set it and avoid disabling it for convenience.

const https = require('https');

const options = {
  hostname: 'auth.example.com',
  port: 443,
  path: '/oauth/introspect',
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  rejectUnauthorized: true   // enforce certificate validation
};

const req = https.request(options, (res) => {
  let data = '';
  res.on('data', chunk => data += chunk);
  res.on('end', () => {
    const payload = JSON.parse(data);
    if (!payload.active) { throw new Error('Token inactive'); }
  });
});

req.on('error', err => { console.error('Request failed', err); });
req.write(JSON.stringify({ token: bearerToken }));
req.end();

2. **Prefer local token verification** – if the bearer token is a JWT, verify its signature, expiration, and audience locally instead of calling an introspection endpoint. This removes the network call that could be poisoned.

const jwt = require('jsonwebtoken');

try {
  const payload = jwt.verify(bearerToken, publicKey, { algorithms: ['RS256'], audience: 'my-api' });
  // payload contains claims; token is valid
} catch (err) {
  // token is invalid or expired
  throw new Error('Invalid token: ' + err.message);
}

3. **Restrict outbound connections** – maintain an allow‑list of trusted authentication hostnames/IPs and reject any DNS resolution that falls outside the list. This can be implemented at the application layer or via network policies (e.g., Kubernetes NetworkPolicy, AWS Security Groups).

By combining strict TLS validation, local JWT verification, and outbound allow‑listing, you eliminate the attack surface that DNS cache poisoning would exploit against bearer token validation.