What Is Man-in-the-Middle Attack (MITM)? - Security Glossary

How It Works

A Man-in-the-Middle attack positions the attacker as a transparent relay between client and server, enabling interception, modification, or injection of traffic.

ARP Poisoning (local network) — On a local network (office WiFi, public hotspot), the attacker sends fake ARP (Address Resolution Protocol) reply packets that associate their MAC address with the default gateway's IP address. All other devices on the network update their ARP tables accordingly and route their traffic through the attacker's machine. The attacker forwards traffic normally to avoid detection while reading and optionally modifying all packets.

SSL Stripping — Once network traffic is flowing through the attacker, they intercept the victim's initial HTTP request to your application (before the HTTPS redirect). The attacker forwards the request to the real server over HTTPS, receiving the encrypted response. They decrypt it (as a legitimate HTTPS client), then deliver a plain HTTP response to the victim. The victim sees correct content over HTTP — the padlock icon is missing, but many users do not notice.

Rogue Access Point — The attacker creates a WiFi access point with the same SSID as a legitimate network (e.g., "CoffeeShop_WiFi"). Devices that previously connected to the real network auto-connect to the attacker's access point instead. All traffic from these devices flows through the attacker's hardware.

BGP Hijacking — At internet scale, attackers can announce more specific BGP routes for an organization's IP prefix, causing global internet traffic to be routed through their ASN (Autonomous System). This has been used to intercept traffic at the routing level, affecting users globally who are not on any local network with the attacker.

Defense — HSTS prevents SSL stripping by eliminating the initial HTTP request. Secure session cookies prevent cookie theft if HTTP traffic is somehow intercepted. Certificate Transparency monitoring detects unauthorized certificates that could be used for MITM even against HTTPS connections.

Types of Man-in-the-Middle Attack (MITM)

SSL Stripping

Attacker on the network path intercepts the initial HTTP request before HTTPS negotiation, downgrading the connection to plaintext and reading all traffic.

# SSL stripping attack flow:
# 1. Victim: GET http://yourapp.com/login (HTTP)
# 2. Attacker intercepts, forwards to server over HTTPS
# 3. Attacker receives HTTPS response, strips to HTTP, sends to victim
# 4. Victim: sees login form over HTTP — session cookie stolen in transit

ARP Poisoning

Attacker broadcasts fake ARP replies on a local network, associating their MAC address with the gateway IP, routing all victim traffic through the attacker's machine.

# ARP poisoning (for illustration — requires local network access)
# arpspoof -i eth0 -t victim_ip gateway_ip
# Result: victim traffic flows through attacker before reaching router

Rogue WiFi Access Point

Attacker creates a fake WiFi network with the same name as a trusted network, intercepting all traffic from devices that connect automatically.

# Defense: enforce HTTPS and HSTS so even rogue WiFi cannot read traffic
# curl -I https://yourapp.com | grep -i strict
# Strict-Transport-Security: max-age=31536000; includeSubDomains

Certificate Spoofing

Attacker obtains or forges a TLS certificate for your domain (via a compromised CA or subdomain takeover) and presents it in a MITM position.

# Monitor Certificate Transparency for unauthorized certs
curl -s "https://crt.sh/?q=yourapp.com&output=json" | jq .[].not_before

In Laravel Applications

MITM attacks against Laravel applications are prevented by enforcing HTTPS (SSL/TLS), setting the HSTS header, and ensuring cookies have the "secure" flag set in config/session.php.

Code Examples

Session Cookie Flags: Insecure vs. Secure Configuration

Vulnerable

// config/session.php — INSECURE: cookies travel over HTTP, JS-readable
return [
    'driver'    => env('SESSION_DRIVER', 'file'),
    'lifetime'  => 120,
    'secure'    => false,     // Cookie sent over HTTP — interceptable by MITM
    'http_only' => false,     // Cookie readable by JavaScript — stealable via XSS
    'same_site' => null,      // No cross-site protection
];

Secure

// config/session.php — SECURE: full cookie protection against MITM
return [
    'driver'    => env('SESSION_DRIVER', 'redis'),
    'lifetime'  => 120,
    'expire_on_close' => false,
    'secure'    => env('SESSION_SECURE_COOKIE', false), // true in production .env
    'http_only' => true,          // JavaScript cannot read this cookie
    'same_site' => 'lax',         // Cross-site submission protection
];
// .env production:
// SESSION_SECURE_COOKIE=true
// SESSION_DRIVER=redis

Real-World Example

On an unsecured WiFi network, an attacker intercepts HTTP traffic to your Laravel app and steals session cookies, gaining access to user accounts.

Why It Matters

Man-in-the-middle attacks are most dangerous in scenarios where users connect over untrusted networks: public WiFi, hotel networks, mobile carrier interception. An attacker who can intercept traffic between a user and your Laravel application can read session cookies, capture form submissions (including passwords), and modify responses to inject malicious content.

Prevention requires a combination of controls: TLS everywhere (no HTTP responses), HSTS (prevents protocol downgrade), secure and HttpOnly session cookies (prevents theft even if HTTP traffic is intercepted), and certificate pinning (for mobile apps communicating with your Laravel API).

In config/session.php, the secure option should be true in production to ensure session cookies are never sent over HTTP. The http_only option should also be true to prevent JavaScript from reading the cookie (mitigating XSS-based session theft). These two settings together significantly reduce the impact of any MITM attack.

The most common vector for MITM against modern HTTPS applications is SSL stripping — where an attacker who intercepts the initial HTTP connection presents it as-is to the server (getting an HTTPS response) while presenting plain HTTP to the user. HSTS prevents this by causing the browser to always use HTTPS directly.

Common Misconceptions

Myth: HTTPS prevents all man-in-the-middle attacks.

Reality: HTTPS prevents passive eavesdropping. Active MITM via SSL stripping, rogue certificate authorities, or BGP hijacking can still intercept HTTPS traffic. HSTS and certificate transparency logging add additional protection.

Myth: MITM only happens on public WiFi.

Reality: MITM can occur at any point in the network path: on corporate networks, via compromised ISPs, through BGP route hijacking affecting traffic across the internet, or via ARP poisoning on local networks.

Myth: Our users will notice a MITM attack.

Reality: Modern browsers display certificate warnings for invalid certificates, but SSL stripping prevents the browser from even attempting HTTPS. Certificate Transparency logs allow external monitoring of unauthorized certificates issued for your domain.

How to Detect This

Verify that `config/session.php` has `'secure' => true` and `'http_only' => true`. Run `curl -I http://yourdomain.com` to confirm HTTP redirects to HTTPS with a 301 status. Check that the `Strict-Transport-Security` header is present on HTTPS responses with `curl -I https://yourdomain.com`. Monitor Certificate Transparency logs via crt.sh (`https://crt.sh/?q=yourdomain.com`) to detect any unauthorized SSL certificates issued for your domain. StackShield verifies that your HSTS header is properly configured and checks whether your cookie security flags are correctly set in HTTP response headers.

How to Prevent This in Laravel

1
Set `'secure' => true` and `'http_only' => true` in `config/session.php` — gate the secure flag on `env('SESSION_SECURE_COOKIE', false)` so local development still works over HTTP.
2
Add HSTS middleware returning `Strict-Transport-Security: max-age=31536000; includeSubDomains` on every HTTPS response to prevent SSL stripping of future connections.
3
Call `URL::forceScheme('https')` in `AppServiceProvider::boot()` for production to eliminate any application-generated HTTP links that could trigger a downgrade.
4
Monitor Certificate Transparency logs via crt.sh for your domain — unauthorized certificates are a sign of a MITM attack using a fraudulently issued certificate.
5
Configure `'same_site' => 'lax'` in `config/session.php` to provide browser-level cross-site request protection complementing HSTS.

Frequently Asked Questions

Does HTTPS completely prevent MITM attacks?

HTTPS prevents passive eavesdropping on encrypted connections but does not prevent all MITM attacks. SSL stripping can downgrade the initial HTTP connection before TLS negotiation — prevented by HSTS. Certificate forgery using a compromised Certificate Authority can allow MITM against HTTPS connections — partially mitigated by Certificate Transparency logs and browser CT enforcement. BGP hijacking can redirect traffic at the routing level before it reaches any TLS layer.

What are the correct secure cookie settings for a Laravel production app?

In `config/session.php`: `'secure' => env('SESSION_SECURE_COOKIE', false)` (set `SESSION_SECURE_COOKIE=true` in production `.env`), `'http_only' => true` (prevents JavaScript access), `'same_site' => 'lax'` (prevents cross-site submission). In production `.env`: `SESSION_DRIVER=redis` (file sessions on shared servers can be read by other users). These settings together prevent session cookie theft via network interception and XSS.

How does Laravel protect against MITM attacks out of the box?

Laravel does not include MITM protection by default — you must add it. Laravel provides the configuration settings to enable protection (the `secure` and `http_only` session config options, `URL::forceScheme()`) but does not enable them automatically. You must also add the HSTS middleware yourself, as Laravel does not ship with security headers. The exception is `SESSION_SECURE_COOKIE` when set in `.env`, which Laravel reads and applies to the session cookie.

Should I trust `X-Forwarded-Proto` headers in Laravel for HTTPS detection?

Only if you configure `TrustProxies` middleware to trust your specific proxy (load balancer, Cloudflare, reverse proxy). If you trust all IPs blindly, attackers can send `X-Forwarded-Proto: https` in direct requests to bypass HTTPS checks. Configure `TrustProxies` in `app/Http/Middleware/TrustProxies.php` to list only your load balancer's IP address or CIDR range in the `$proxies` property.

Related Terms

SSL/TLS

Cryptographic protocols that provide encrypted communication between a client (browser) and server. SSL (Secure Sockets Layer) is the predecessor to TLS (Transport Layer Security). TLS 1.2 and 1.3 are the current standards. These protocols ensure data transmitted between users and your application cannot be intercepted or modified.

HTTP Strict Transport Security (HSTS)

A security header that tells browsers to only connect to your website over HTTPS. Once a browser receives the HSTS header, it will automatically convert all future HTTP requests to HTTPS for the specified duration, preventing protocol downgrade attacks and cookie hijacking.

Security Headers

HTTP response headers that instruct browsers how to handle your website's content securely. They protect against common attacks like cross-site scripting (XSS), clickjacking, and protocol downgrade attacks by telling the browser what actions are allowed.