Connection State Attack — First Request Validation
The purpose of the HTTP host header is to help identify which back-end service the client wants to communicate with, in addition, many applications rely on the host header to generate password reset link or redirect address, etc. The logic flaw or misconfiguration may result in different types of HTTP host header attacks. One of them is HTTP connection request smuggling when the host header is only validated in the first request sent over a HTTP connection.
This blog post will walk you through a PortSwigger lab to understand HTTP connection request smuggling attack.
Before start the PortSwigger lab, you need to get familiar with a few concepts.
1. Prerequisite Knowledge
1.1 Virtual Hosting
It is common that more than one websites or applications are hosted on one single system or web server, sharing resources such as CPU and memory. Websites hosted this way on a single server are known as “virtual hosts”. Visitors to a website or application are routed to the correct virtual host in the following virtual hosting methods:
- IP-based
The IP-based virtual hosting requires a dedicated IP address per virtual host. It is achieved by creating multiple IP addresses for a single web server.
- Port-based
The port-based virtual hosting uses different ports, the web server is configured to route the traffic to the virtual host by the port.
- Name-based
The name-based virtual hosting allows one IP address to host more than one websites. The traffics are routed by host name in the HTTP requests. This approach requires that the client must support HTTP 1.1(or HTTP 1.0 with 1.1 extensions).
1.2 Routing Traffic via an Intermediary Device
Another common scenario is that different websites are hosted on distinct back-end servers, but they all travel through an intermediary device before reach the target back-end server. Typically, reverse proxy servers and load balancers can act as such an intermediary, situated in the request path. This design allows multiple websites to be resolved to a single IP address of the intermediary component, the requests are distributed accordingly to intended back-end servers behind the intermediary component. To achieve it, the routing can be based on host name in request.
1.3 Host Header
Host header is important for name-based virtual hosting and host-based routing via an intermediary device to know where to forward the traffic once the request comes in. When users visit a website, the URL will resolve to the IP address of a particular server or an intermediary device. Inside the request, host header specifies the domain name that the client wants to access.
1.4 HTTP Host Header Attack
As the host header is in fact user controllable, this practice can lead to a number of issues. HTTP host header attacks exploit vulnerable websites that trust the host header without validate it properly. Attackers can tamper with host header via malformation or duplication to manipulate the backend server behavior. Companies sometimes host publicly accessible websites and internal websites on the same server, attackers may be able to access internal website via host header manipulation.
1.5 Keep-alive Connection
A TCP connection is established with a three-way handshake, it requires both the server and the client exchange SYN and ACK packets before data can be transmitted. By default, HTTP connections close after each request, a new connection will be made for the next request. The handshake incurs a overhead for the connection and slow the whole connection process down. To improve performance, the HTTP keep-alive header holds the TCP socket/connection open and allows multiple requests and responses to reuse one established TCP connection.
The workflows (exclude SSL handshake) are illustrated as below for both keep-alive disabled and enabled:
You can use the cURL command to get better understanding of how reusing the same connection reduces the connection delay.
To measure how long a request to a server takes, you can specify the timings in the cURL command.
time_connect is the TCP three-way handshake from the client’s perspective. time_appconnect here is TLS setup. time_starttransfer is just before cURL reads the first byte from the network (it hasn’t actually read it yet).
Issuing the similar cURL command as the following:
# curl -v -s -w "TCP time: %{time_connect}, TLS setup time: %{time_appconnect}, Time to first byte: %{time_starttransfer}\n\n" -o /dev/null https://example.com/ -o /dev/null https://example.com/
* Trying ***:443...
* Connected to example.com (***) port 443 (#0)
* schannel: disabled automatic use of client certificate
* ALPN: offers http/1.1
* ALPN: server did not agree on a protocol. Uses default.
> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/7.83.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
...
< Keep-Alive: timeout=10
< Content-Length: 0
<
* Connection #0 to host example.com left intact
TCP time: 0.571379, TLS setup time: 1.441327, Time to first byte: 1.867394
* Found bundle for host: 0x1bcf22be890 [serially]
* Re-using existing connection #0 with host example.com
* Connected to example.com (***) port 443 (#0)
> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/7.83.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
...
< Keep-Alive: timeout=10
< Content-Length: 0
<
* Connection #0 to host example.com left intact
TCP time: 0.005519, TLS setup time: 0.005520, Time to first byte: 0.428777Inspect the result of the curl command and you can see Connection # 0 is created in the first request and is reused by the second request. Time to connect for two requests in the same connection is outlined as below:
...
TCP time: 0.571379, TLS setup time: 1.441327, Time to first byte: 1.867394
...
TCP time: 0.005519, TLS setup time: 0.005520, Time to first byte: 0.428777The first TCP connection time is 0.571379 s and the second request only takes 0.005519 s in total.
But not all the servers enable keepalive, as disabling keepalive turns out to be a solution to slow the abusive clients down to mitigate some attack traffic.
2. Connection State Attack - First-request validation
In connection state attacks, some applications perform host header validation only on the first request in a connection. This means attackers can gain access to internal websites by issuing a request to a legitimate host name, followed by one for the internal site down the same connection. The connection state attack lab in portswigger site is vulnerable to routing based SSRF, you can get the entry to the lab. Now we will go through the lab together.
When an user accesses the vulnerable website, use burpsuite to capture GET / request which we call request #1:
Duplicate the above request as request #2 and change the request by setting the path to /admin, and host header to 192.168.0.1, send the request.
It is observed that you are simply redirected to the homepage.
Now create a tab group to put request #1 and request #2 together.
Name the tab group as Group 1, and add request #1 and request #2 into the group.
Select “Send group in sequence(single connection)” to place these two requests in one HTTP connection.
Change the Connection in two requests to keep-alive and click “Send group in sequence (single connection)” button. It is seen that the second request has successfully accessed the internal admin panel.
The reason is that host header in request #1 pass the validation, but the validation isn’t applied to the subsequent requests down the same HTTP connection with request#1, so when host header is tampered in request #2, the request #2 is routed successfully to the internal website 192.168.0.1, the admin panel is exposed to the end user.
You can follow the solution in the portswigger site to complete the lab.
Final Thoughts
If you have any questions or feedback, feel free to leave a comment. If you think this blog post is helpful, please click the clap 👏 button below a few times to show your support!
