Man In The Middle with Basic Auth

Man-in-the-Middle (MITM) attacks exploit the fundamental weakness of HTTP Basic Authentication: credentials are sent with every request in a Base64-encoded Authorization header, but this encoding is not encryption. When Basic Auth is used over an unencrypted HTTP connection, an attacker positioned between the client and server can passively sniff network traffic or actively intercept requests to steal these credentials. The attack is trivial: capturing a single packet reveals the Authorization: Basic <credentials> header, which decodes to username:password.

Specific attack patterns include:

• Network Sniffing on Public Wi-Fi: An attacker on the same network uses tools like Wireshark to capture HTTP traffic. Any Basic Auth request exposes full credentials.
• Rogue Access Points: An attacker sets up a Wi-Fi hotspot with a common name (e.g., "CoffeeShop_WiFi"). Users connecting and authenticating to APIs over HTTP send credentials directly to the attacker.
• Compromised Network Infrastructure: Malicious routers or DNS hijacking redirect traffic through an attacker's system, enabling credential theft from any HTTP-based Basic Auth endpoint.
• SSL Stripping: If an API supports both HTTP and HTTPS, an attacker can downgrade a user's initial HTTPS request to HTTP, then intercept subsequent Basic Auth headers.

Basic Auth exacerbates the risk because it is stateless and credentials are reused for every request until the client session ends. Unlike session cookies that can be invalidated, stolen Basic Auth credentials remain valid until manually changed. This makes them a high-value target. The OWASP API Security Top 10 includes Broken User Authentication (API7:2023) as a category, and MITM via unencrypted transport falls under this when authentication mechanisms are exposed.

Real-world impact is severe: stolen credentials can lead to full account takeover, data exfiltration, and lateral movement. For example, CVE-2020-15598 highlighted a mobile app that transmitted Basic Auth credentials over HTTP, allowing network attackers to hijack user sessions.

Detecting MITM vulnerabilities in Basic Auth requires verifying that all authentication traffic is encrypted. The primary indicator is any use of http:// URLs for endpoints that accept Basic Auth. Even if a login page uses HTTPS, subsequent API calls over HTTP expose credentials. Manual detection involves:

• Inspecting network traffic (via browser DevTools or proxy tools like mitmproxy) to confirm no Authorization headers travel over HTTP.
• Checking server configurations for HTTP-to-HTTPS redirects and HSTS headers.
• Testing for mixed content: an HTTPS page that loads HTTP resources can leak credentials via referer headers or embedded requests.

Scanning with middleBrick
middleBrick automates this detection through its Encryption security check, one of the 12 parallel tests run on every scan. When you submit an API endpoint URL, middleBrick:

1. Attempts to access the endpoint over both HTTP and HTTPS.
2. Inspects responses for Authorization: Basic headers (or simulates sending them if unauthenticated testing is allowed).
3. Flags any instance where Basic Auth credentials could be transmitted without TLS encryption.

The scan returns a risk score (0–100) and a letter grade (A–F). A finding for unencrypted Basic Auth typically appears as a high-severity issue under the Encryption category, with a description like: "Basic Authentication credentials transmitted over unencrypted HTTP. Attackers on the network can steal credentials." The report includes the specific endpoint URL and request/response details, enabling immediate verification.

For example, scanning http://api.example.com/v1/users with middleBrick would produce a critical finding if that endpoint accepts Basic Auth. You can run this from the Web Dashboard, the CLI tool (middlebrick scan http://api.example.com/v1/users), or integrate it into CI/CD via the GitHub Action to catch regressions before deployment.

Remediation focuses on ensuring Basic Auth is never used over unencrypted channels and that the server enforces HTTPS strictly. The goal is to prevent any HTTP request that carries credentials.

1. Enforce HTTPS at the Server
Configure your web server or application framework to redirect all HTTP traffic to HTTPS and set HTTP Strict Transport Security (HSTS) headers. This ensures clients only communicate over TLS.

Example: Node.js with Express and Helmet

const express = require('express');
const helmet = require('helmet');
const app = express();

// Enforce HTTPS and set HSTS
app.use(helmet.hsts({ maxAge: 31536000, includeSubDomains: true }));

// Redirect HTTP to HTTPS (if behind a proxy like nginx, handle redirect there)
app.use((req, res, next) => {
  if (!req.secure) {
    return res.redirect(`https://${req.headers.host}${req.url}`);
  }
  next();
});

// Basic Auth middleware (example)
const auth = (req, res, next) => {
  const authHeader = req.headers['authorization'];
  if (!authHeader || !authHeader.startsWith('Basic ')) {
    return res.status(401).send('Authentication required');
  }
  // Decode and verify credentials...
  next();
};
app.get('/api/data', auth, (req, res) => {
  res.json({ data: 'secure' });
});

app.listen(3000);

2. Disable HTTP Completely
If possible, configure your load balancer or web server (e.g., nginx, Apache) to listen only on port 443 and reject port 80 requests. For cloud deployments, use security groups or firewall rules to block inbound HTTP.

Example: nginx configuration

server {
    listen 443 ssl http2;
    server_name api.example.com;
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    
    location / {
        # Proxy to application
        proxy_pass http://localhost:3000;
    }
}

# Optional: return 444 (no response) for HTTP requests
server {
    listen 80;
    server_name api.example.com;
    return 444;
}

3. Client-Side Enforcement
Ensure client applications (mobile apps, scripts) use only HTTPS URLs. Do not allow fallback to HTTP. In mobile apps, use network security configurations (Android) or App Transport Security (iOS) to block clear-text traffic.

4. Consider Stronger Authentication
Basic Auth is inherently vulnerable to credential theft if TLS is misconfigured. For sensitive APIs, migrate to token-based schemes like OAuth 2.0 or API keys with short lifespans. However, if Basic Auth must be used, the above steps are mandatory.

After remediation, rescan with middleBrick to verify the Encryption check passes and the overall risk score improves. The Pro plan's continuous monitoring can alert you if an HTTP endpoint accidentally reappears.