| name | http-connection-contamination |
| description | How to test for HTTP connection contamination vulnerabilities in web applications. Use this skill whenever you need to audit HTTP/2+ connection coalescing, test reverse proxy routing, investigate potential security issues with wildcard TLS certificates, or assess shared infrastructure risks. Make sure to use this skill when you mention HTTP/2, HTTP/3, connection coalescing, reverse proxy misconfiguration, wildcard certificates, or any scenario involving multiple subdomains on shared infrastructure. |
HTTP Connection Contamination Testing
This skill helps you identify and test for HTTP connection contamination vulnerabilities, where browsers reuse HTTP/2+ connections across different websites through connection coalescing, potentially causing request misrouting in reverse proxies.
Understanding the Vulnerability
What is HTTP Connection Coalescing?
Web browsers can reuse a single HTTP/2+ connection for different websites when:
- They share the same IP address
- They have a common TLS certificate (e.g., wildcard certificate like
*.example.com)
The Attack Vector
When combined with first-request routing in reverse proxies, this can cause:
- Subsequent requests to be directed to the back-end determined by the first request
- Security vulnerabilities like XSS, information disclosure, or authentication bypass
- Requests to
secure.example.com being wrongly processed by a different back-end (e.g., WordPress)
Why HTTP/3 Makes This Worse
HTTP/3 proposals relax the IP address match requirement, potentially broadening the attack surface without needing a MITM attack.
Detection and Testing
Step 1: Identify Potential Targets
Look for these conditions:
- Multiple subdomains on the same IP address
- Wildcard TLS certificates (
*.example.com)
- Reverse proxy infrastructure (nginx, Apache, HAProxy, etc.)
- Different applications behind the same proxy
Step 2: Check for Connection Coalescing
Use Chrome's Network tab or Wireshark to observe if requests to different subdomains share the same connection.
Step 3: Test for First-Request Routing
Run the connection contamination test to see if requests get misrouted.
Testing Scripts
Basic Connection Contamination Test
Use the test-connection-coalescing.js script to test if two subdomains share a connection:
node test-connection-coalescing.js --subdomain1 sub1.example.com --subdomain2 sub2.example.com
This script:
- Makes a request to the first subdomain
- Immediately makes a request to the second subdomain
- Reports whether connection coalescing occurred
Advanced Testing with curl
For manual testing, use curl with connection reuse:
curl -v --http2 https://sub1.example.com/
curl -v --http2 --keepalive-time 30 https://sub2.example.com/
Automated Detection Script
Use detect-contamination.sh to automate the detection process:
./detect-contamination.sh --domain example.com --subdomains sub1 sub2 sub3
This script:
- Checks if subdomains share IP addresses
- Verifies TLS certificate coverage
- Tests for connection coalescing
- Reports potential contamination vectors
Analysis Checklist
When analyzing potential vulnerabilities, check:
Remediation Guidance
For Server Administrators
- Avoid first-request routing in reverse proxies when possible
- Use separate certificates for different applications instead of wildcards
- Implement proper Host header validation on back-end servers
- Consider HTTP/2 connection isolation for sensitive applications
- Monitor for unusual request patterns that might indicate contamination
For Security Auditors
- Document all subdomains and their back-end services
- Map certificate coverage across infrastructure
- Test connection coalescing during penetration tests
- Review reverse proxy configurations for routing logic
- Assess HTTP/3 readiness and potential new attack vectors
Common Scenarios
Scenario 1: WordPress + Admin Panel
If wordpress.example.com and admin.example.com share infrastructure:
- Test if admin requests can be routed to WordPress
- Check for XSS or information disclosure possibilities
- Verify session isolation between applications
Scenario 2: API + Web Frontend
If api.example.com and app.example.com share infrastructure:
- Test if API requests can be misrouted to the web frontend
- Check for authentication bypass possibilities
- Verify CORS and origin header handling
Scenario 3: Multiple Customer Portals
If customer1.example.com and customer2.example.com share infrastructure:
- Test for cross-tenant data access
- Verify proper isolation between customer environments
- Check for session hijacking possibilities
References
Notes
- This vulnerability is currently limited due to the rarity of first-request routing
- HTTP/3 changes may expand the attack surface significantly
- Regular testing and awareness of these interconnected vulnerabilities are crucial
- Always test in controlled environments before production assessment