http-connection-request-smuggling

name

http-connection-request-smuggling

description

Detect and test HTTP Connection Request Smuggling vulnerabilities where reverse proxies only validate Host/:authority headers on the first request of a TCP/TLS connection. Use this skill whenever the user mentions HTTP smuggling, connection-state attacks, Host header validation, reverse proxy vulnerabilities, HTTP/2 coalescing abuse, or wants to test for SSRF-like access through connection reuse. Also trigger for requests about testing load balancers, CDNs, or proxies for first-request-only validation weaknesses.

HTTP Connection Request Smuggling Detection

This skill helps you detect and test HTTP Connection Request Smuggling vulnerabilities where reverse proxies, load balancers, or CDNs only validate Host or :authority headers on the first request of a connection, allowing attackers to smuggle requests to internal hosts.

When to Use This Skill

Use this skill when:

• Testing web applications behind reverse proxies, load balancers, or CDNs
• Investigating potential SSRF-like access through connection reuse
• Auditing HTTP/2 or HTTP/3 deployments for coalescing vulnerabilities
• Reviewing proxy configurations for first-request-only validation
• Analyzing responses that suggest requests are being routed to unexpected backends

Core Concepts

Connection-State Attack Vectors

1. First-request Validation: Proxies whitelist Host headers only on the first request
2. First-request Routing: Proxies map outbound connections based exclusively on the first request
3. HTTP/2/3 Coalescing Abuse: Browsers reuse TLS connections when certificate, ALPN, and IP match

Attack Pattern

Request 1 (allowed): Host: public.example.com
Request 2 (smuggled): Host: internal.company.local

If the proxy only validates the first request, Request 2 reaches the internal host.

Detection Workflow

Step 1: Identify the Target Architecture

Determine what sits in front of the target:

• CDN (Cloudflare, Akamai, Fastly, etc.)
• Load balancer (AWS ALB, NGINX, HAProxy, etc.)
• Reverse proxy (Apache, Envoy, Traefik, etc.)

Step 2: Run Automated Detection

Use the detection script to test for connection-state vulnerabilities:

python scripts/detect_connection_smuggling.py --target <url> --internal-host <suspected-internal-host>

Step 3: Manual Verification

If automated detection finds potential issues, verify manually:

1. HTTP/1.1 Keep-Alive Test:

   GET / HTTP/1.1
   Host: allowed-external-host.example
   Connection: keep-alive
   
   GET /admin HTTP/1.1
   Host: internal-only.example
   Connection: keep-alive
   

2. HTTP/2 Stream Multiplexing Test:

   • Open stream ID 1 to a benign host
   • Open stream ID 3 to an internal host on the same connection
   • Check if stream 3 receives a response from the internal backend

Step 4: Analyze Responses

Look for these indicators of vulnerability:

• Different response content between first and second request
• Different response headers (Server, X-Powered-By, etc.)
• Different response times suggesting different backends
• Access to resources that should be internal-only

Exploitation Scenarios

Scenario 1: Internal Host Discovery

If you suspect internal hosts exist:

1. Send first request to public host

2. Send second request with guessed internal hostnames:

   • admin.internal
   • dashboard.local
   • api.internal.company
   • private.company

3. Compare responses to identify which internal hosts are accessible

Scenario 2: HTTP/2 Coalescing Attack

For browser-based exploitation:

1. Control a domain (evil.com) resolving to the same CDN edge as target
2. Embed resource requests to internal hosts in your page
3. Browser coalesces requests on existing TLS connection
4. If proxy only validates first request, internal hosts are exposed

Scenario 3: Password Reset Poisoning

Combine with Host header attacks:

GET / HTTP/1.1
Host: public.example

POST /pwreset HTTP/1.1
Host: private.internal
Content-Type: application/x-www-form-urlencoded

email=[e-mail]&token=...

Mitigation Recommendations

For Security Teams

1. Re-validate Host/:authority on every request, not just connection creation
2. Disable origin coalescing on CDN/load-balancer layers:
   • NGINX: http2_origin_cn off
   • AWS ALB: Update rules engine
3. Use separate certificates or IPs for internal and external hostnames
4. Prefer Connection: close or proxy_next_upstream after each request

Configuration Examples

NGINX:

http2 on;
http2_origin_cn off;  # Disable coalescing

server {
    listen 443 ssl http2;
    server_name public.example;
    
    # Re-validate on every request
    if ($host !~* "public\.example") {
        return 403;
    }
}

Envoy:

# Ensure :authority validation on every stream
route_config:
  virtual_hosts:
  - name: public
    domains:
    - "public.example"
    # Don't allow authority override after first stream

Real-World Vulnerabilities

Year	Component	CVE	Issue
2022	AWS ALB	–	Host header only validated on first request
2023	Apache Traffic Server < 9.2.2	CVE-2023-39852	HTTP/2 connection reuse smuggling
2024	Envoy Proxy < 1.29.0	CVE-2024-2470	Improper :authority validation

Tools

• Burp Suite Professional ≥2022.10: HTTP Request Smuggler → Connection-state probe
• Burp Suite 2023.12+: HTTP/2 Smuggler insertion point
• smuggleFuzz (Microsoft): Python framework for HTTP/2/3 desync testing
• Custom scripts: See scripts/ directory

References

• PortSwigger Research: Browser-Powered Desync Attacks
• PortSwigger: HTTP/2: The Sequel is Always Worse (Black Hat USA 2023)
• Envoy Security Advisory: CVE-2024-2470
• Microsoft: smuggleFuzz