Arp Spoofing with Session Cookies
How ARP Spoofing Manifests in Session Cookies
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 (often the gateway or a target server). When successful, the attacker can intercept, inspect, and modify traffic flowing between the victim and the server on the same LAN segment.
In the context of session cookies, the danger arises when the application transmits cookies over unencrypted HTTP or when HTTPS is downgraded via SSL‑stripping techniques that often accompany ARP spoofing. If a session cookie lacks the Secure attribute, the browser will send it in clear text over HTTP, making it readable to the attacker who has positioned themselves as a man‑in‑the‑middle. Likewise, missing HttpOnly allows client‑side script (e.g., injected via XSS) to read the cookie, but ARP spoofing does not require XSS; the attacker can simply sniff the cookie value from the wire.
Typical code paths that expose this risk include:
- Login endpoints that set a session cookie without
Securewhen the application is reachable via HTTP (common in development or misconfigured production). - API responses that echo back a session token in a
Set‑Cookieheader over HTTP. - Middleware that conditionally omits
Securebased onreq.secureorX-Forwarded-Protoheaders that can be spoofed when the attacker controls the network path.
Real‑world examples of ARP‑based session hijacking include attacks observed against corporate Wi‑Fi networks where tools like bettercap or Ettercap performed ARP spoofing followed by SSL‑stripping (via sslstrip) to capture authentication cookies, leading to account takeover (see CVE‑2014‑6271 – “Shellshock” – not directly ARP but illustrates how network‑level footholds enable credential theft).
Session Cookies-Specific Detection
middleBrick’s black‑box scan evaluates the unauthenticated attack surface of any API endpoint. While it does not perform ARP spoofing itself, it checks for the configuration weaknesses that make session cookies exploitable when an attacker can intercept traffic.
During the scan, middleBrick examines HTTP response headers for Set‑Cookie directives and flags the following issues:
- Missing Secure flag – the cookie is sent over non‑HTTPS connections.
- Missing HttpOnly flag – the cookie is accessible to JavaScript, increasing theft surface.
- Missing or lax SameSite attribute** – allows the cookie to be sent with cross‑site requests, which can be leveraged in conjunction with ARP‑based man‑in‑the‑middle to perform CSRF‑style token replay.
- Excessive cookie lifetime** – long‑lived sessions increase the window of exposure if intercepted.
- Cookie names that suggest session identifiers** (e.g.,
sessionid,auth_token) are highlighted for prioritized remediation.
The scanner also tests for HTTP downgrade susceptibility by requesting the target via plain HTTP and observing whether the server redirects to HTTPS or continues to serve sensitive endpoints without encryption. If the API accepts HTTP and returns a Set‑Cookie without Secure, middleBrick reports a high‑severity finding under the "Transport Security" category.
These findings are presented in the dashboard with a severity rating, a short description, and remediation guidance. Users can run the same checks locally via the CLI:
# Install the middleBrick CLI (npm package)
npm i -g middlebrick
# Scan an API endpoint for session‑cookie issues
middlebrick scan https://api.example.com/login
In CI/CD, the GitHub Action can be configured to fail a build when the session‑cookie related findings exceed a threshold:
name: API Security Check
on: [push]
jobs:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run middleBrick scan
uses: middlebrick/action@v1
with:
api-url: https://staging.example.com
fail-below: B # fail if score drops below B
The MCP Server integration allows developers to invoke the same scan from within AI‑powered IDEs (e.g., Claude, Cursor) to get immediate feedback while writing API code.
Session Cookies-Specific Remediation
Remediation focuses on configuring session cookies so that even if an attacker successfully performs ARP spoofing and intercepts traffic, the cookie cannot be misused. The fixes rely on native language/framework features; no third‑party wrapping or automatic patching is involved.
1. Always set the Secure flag – ensures the browser only transmits the cookie over HTTPS.
Node.js (Express):
const express = require('express');
const app = express();
app.post('/login', (req, res) => {
// Assume token is generated after successful auth
const token = generateSessionToken();
res.cookie('sessionid', token, {
httpOnly: true,
secure: true, // <‑‑ critical
sameSite: 'strict',
maxAge: 24 * 60 * 60 * 1000 // 24 h
});
res.json({ success: true });
});
app.listen(3000);
Python (Flask):
from flask import Flask, make_response
app = Flask(__name__)
app.config.update(
SESSION_COOKIE_SECURE=True,
SESSION_COOKIE_HTTPONLY=True,
SESSION_COOKIE_SAMESITE='Lax'
)
@app.route('/login', methods=['POST'])
def login():
# auth logic …
token = generate_token()
resp = make_response({'status': 'ok'})
resp.set_cookie('sessionid', token, httponly=True, secure=True, samesite='Lax')
return resp
if __name__ == '__main__':
app.run(host='0.0.0.0', port=5000)
2. Enable HttpOnly – prevents client‑side script access, reducing the impact of any XSS that might be chained with network interception.
3. Apply a strict SameSite policy – SameSite=Strict or Lax prevents the cookie from being sent with cross‑site requests, mitigating CSRF‑style replay even if the token is captured.
4. Enforce HTTPS everywhere – redirect all HTTP requests to HTTPS and enable HSTS (Strict-Transport-Security) to prevent SSL‑stripping.
Example middleware for Express to enforce HTTPS:
const helmet = require('helmet');
app.use(helmet.hsts({ maxAge: 31536000, includeSubDomains: true, preload: true }));
app.use((req, res, next) => {
if (req.headers['x-forwarded-proto'] !== 'https') {
return res.redirect(`https://${req.headers.host}${req.url}`);
}
next();
});
After applying these changes, re‑run a middleBrick scan (CLI, GitHub Action, or MCP Server) to verify that the session‑cookie findings are resolved and the overall security score improves.
By addressing the cookie attributes directly, you eliminate the low‑hanging fruit that ARP spoofing attackers rely on, turning a network‑level interception attempt into a dead end for session hijacking.
Frequently Asked Questions
Does middleBrick perform ARP spoofing to test my APIs?
How can I verify that my session cookies are safe after applying the fixes?
middlebrick scan https://your-api.com), the GitHub Action in your CI pipeline, or the MCP Server integration in your IDE. The scanner will re‑evaluate the Set‑Cookie headers and report whether the Secure, HttpOnly, and SameSite attributes are now present. A passing result (no high‑severity session‑cookie findings) indicates the remediation was effective.