Dns Rebinding in Fiber with Basic Auth

DNS rebinding is an application-layer attack that manipulates DNS responses to make a victim’s browser believe a remote host is a local one. In a Fiber application protected by HTTP Basic Authentication, this combination can bypass intended network boundaries. When Basic Auth is required, an attacker may first obtain a valid username and password (e.g., via phishing, credential stuffing on another service, or accidental exposure in logs or source code). With credentials in hand, the attacker crafts a malicious page that performs a DNS rebinding maneuver: the initial request includes the Authorization header, and subsequent requests to the same hostname are redirected to an internal IP address, such as 127.0.0.1 or 192.168.x.x.

Because the browser continues to send the valid Basic Auth credentials with each request, the Fiber endpoint that relies solely on Basic Auth for access control may treat the rebound request as legitimate and authorized. This can expose admin interfaces, local health checks, or internal microservices that are not intended to be reachable from the public internet. The attack does not exploit a flaw in Fiber itself, but rather the interaction between weak network segregation and over-reliance on Basic Auth as the sole protective measure. For example, an endpoint like /debug or /metrics, which might be bound to localhost but exposed through a reverse proxy, can be invoked by the victim’s browser once the DNS rebinding occurs and credentials are presented automatically.

In a black-box scan, middleBrick tests unauthenticated attack surfaces and, when credentials are supplied, validates how authentication mechanisms behave across DNS changes. Without additional controls like same-origin enforcement, strict CORS policies, or binding to trusted interfaces, Basic Auth in Fiber can inadvertently allow access to sensitive internal endpoints after a successful rebinding event. Attackers may chain this with other techniques such as SSRF to probe internal infrastructure, emphasizing the need to treat Basic Auth as one layer rather than a comprehensive boundary.

To mitigate DNS rebinding risks when using Basic Auth in Fiber, implement defense-in-depth: avoid relying on Basic Auth alone, bind services to localhost or a controlled interface, and enforce strict request validation. Below are concrete code examples for a Fiber application that reduce the attack surface.

1. Restrict binding to localhost and enforce reverse proxy controls

Ensure your Fiber server listens only on 127.0.0.1 when it does not need to be publicly reachable. Place a properly configured reverse proxy in front to handle authentication and network exposure.

const fiber = require('fiber');
const app = fiber();

// Bind to localhost only; external traffic must pass through a proxy
app.listen('127.0.0.1:3000', () => {
  console.log('Fiber server bound to localhost:3000');
});

2. Use Basic Auth with request origin and host validation

Validate the Origin and Host headers on each request to reduce the likelihood that a rebinding attack will succeed. Combine this with a strict Content-Security-Policy to limit which contexts your endpoints can be embedded in.

const fiber = require('fiber');
const app = fiber();

// Basic Auth middleware with origin/host checks
const basicAuth = (req, res) => {
  const user = req.get('Authorization');
  const expectedToken = 'Basic ' + Buffer.from('admin:strongpassword').toString('base64');

  if (user !== expectedToken) {
    res.status(401).send('Unauthorized');
    return null;
  }

  const origin = req.get('Origin');
  const host = req.get('Host');
  // Reject requests with missing or unexpected origins/hosts
  if (!origin || !host || !origin.includes('yourtrusteddomain.com') || host !== 'api.yourtrusteddomain.com') {
    res.status(403).send('Forbidden');
    return null;
  }

  return { user: 'admin' };
};

app.all('*', basicAuth);

app.get('/debug', (req, res) => {
  res.json({ status: 'ok', environment: 'internal' });
});

app.listen('127.0.0.1:3000');

3. Implement layered access controls and avoid exposing sensitive endpoints publicly

Do not rely on Basic Auth as the only access control. Use role-based checks, IP allowlists at the proxy level, and ensure that sensitive routes are not accessible from public interfaces. If you must expose endpoints, require additional context such as a custom header or mutual TLS at the proxy.

const fiber = require('fiber');
const app = fiber();

// Example of an additional route-level guard
app.get('/admin/settings', (req, res) => {
  const auth = req.get('Authorization');
  if (auth !== 'Basic ' + Buffer.from('admin:strongpassword').toString('base64')) {
    return res.status(401).send('Unauthorized');
  }
  // Additional check: ensure request came from a trusted proxy or internal network
  const forwardedFor = req.get('X-Forwarded-For');
  const trustedSubnets = ['10.0.0.0/8', '192.168.1.0/24'];
  if (!isFromTrustedSubnet(forwardedFor, trustedSubnets)) {
    return res.status(403).send('Forbidden');
  }
  res.json({ settings: 'secure' });
});

function isFromTrustedSubnet(ip, subnets) {
  // Simplified check; use a library like ipaddr.js for production
  return subnets.some(subnet => matchesSubnet(ip, subnet));
}

app.listen('127.0.0.1:3000');

4. Leverage a reverse proxy for authentication and network segregation

Terminating Basic Auth at a proxy (e.g., Nginx, Envoy) ensures that internal Fiber routes are not directly exposed. Configure the proxy to validate credentials, normalize headers, and restrict requests based on hostname and target IP.

# Example Nginx configuration snippet
server {
  listen 443 ssl;
  server_name api.yourtrusteddomain.com;

  ssl_certificate /etc/ssl/certs/api.crt;
  ssl_certificate_key /etc/ssl/private/api.key;

  location / {
    # Basic Auth at the proxy
    auth_basic 'Restricted';
    auth_basic_user_file /etc/nginx/.htpasswd;

    # Proxy to local Fiber app
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header Origin $scheme://$host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    # Enforce strict Host and Referer checks
    if ($host != 'api.yourtrusteddomain.com') {
      return 403;
    }
  }
}