Routing Based SSRF
SSRF through Host Header Injection
In this blog, we will discuss about host header injection attack and how it is chained to perform SSRF (Server-Side Request Forgery). Firstly, let’s understand what SSRF and Host Header Injection are. For the exploitation part we will also see a demonstration on PortSwigger academy’s lab.
Server-Side Request Forgery
SSRF occurs when an attacker tricks a web application into making unauthorized requests to unintended location.
By exploiting SSRF, attackers can send requests to both external and internal servers, bypassing security measures. This is often used maliciously to gain access to internal networks, local systems, or facilitate other types of attacks.
Host Header Injection
Host Header Injection is an attack that exploits the vulnerability in how web servers and applications process the Host header in HTTP requests.
Attackers can manipulate the Host header to deceive the server into treating the request as coming from a different domain than it actually is. Attackers achieve this by injecting malformed or spoofed Host header values into the HTTP requests, tricking the server into processing the request in unintended ways.
Exploitation
Now that we have cleared the basics out, let’s see how we can detect such host header injection attacks and chain it to perform SSRF.
Detection
Here, in the lab, we are presented with a simple webpage. Let’s inspect the traffic through our proxy.
There’s not much to see but a /
GET call to request the home page. Now, let's check for host header injection by entering any other Hosts in the field. Let’s enter our burp collaborator’s IP to listen for any request that is made from the web application.
On doing so, we got a 200 OK
response from the server. Let’s check what our collaborator has received.
We can see the application tried to fetch our collaborator IP which is the Host that we provided. So, we could verify that the application was vulnerable to host header injection.
Exploitation
Now, let’s try to perform SSRF leveraging this host header injection attack. Here, we can FUZZ the internal IP in the host field to figure out where the application is running. In a real world scenario, we can fuzz all A, B and C classes of private IP to determine the location of the service running internally. However, in this lab we are provided that the admin page is hosted within 192.168.0.0/24
network. The /24
range contains total of 256 IPs. So, let's take the request to the burp’s intruder and fuzz the whole range of /24
subnet.
Select the Numbers List up from 0 to 255 (256 iterations) as payload and start the attack.
Finally, we can see among all the requests sent through the intruder, 192.168.0.185
has redirected to /admin
which is the admin page hosted internally. Following the redirection, let’s view the page.
In the admin page we could see a user deletion form. Sending POST request to /admin/delete
with the csrf
token and username
parameter could delete any user. This is how we could perform SSRF leveraging the host header injection.
Finally, the request to delete the user is sent, and the user is deleted. We were able to forge the request on behalf of the application or the server to perform unauthorized and high-privilege actions. This is how we can perform SSRF by chaining it with host header injection.
Remedies
- Employ server-side validation for host headers.
- Use whitelist approach for validations.
- Set host header explicitly.
In this blog, we discussed about host header injection attack and how it can be chained to perform SSRF.