# SSRF via flawed request parsing

<div align="left"><figure><img src="/files/45u1JkPvkn0d0kE9aibQ" alt=""><figcaption></figcaption></figure></div>

## <mark style="color:red;">Exploitation</mark>

Send the `GET /` request that received a 200 response to Burp Repeater.

<div align="left"><figure><img src="/files/4rcJiQnbA07nZw4tQZCu" alt=""><figcaption></figcaption></figure></div>

open burp collaborator and copy the collaborator payload

<div align="left"><figure><img src="/files/VVc5HzfSNzoo9NIvgZQM" alt=""><figcaption></figcaption></figure></div>

now let's see if the server makes requests to an arbitrary server

Observe that the website validates the `Host` header and blocks any requests in which it has been modified.

<div align="left"><figure><img src="/files/GJ20PBdqpD4TJle4Sd7W" alt=""><figcaption></figcaption></figure></div>

### <mark style="color:red;">Supplying absolute URL :</mark>&#x20;

#### according to <mark style="color:orange;">**portswigger**</mark> =>&#x20;

Although the request line typically specifies a relative path on the requested domain, many servers are also configured to understand requests for absolute URLs.

The ambiguity caused by supplying both an absolute URL and a Host header can also lead to discrepancies between different systems. Officially, the request line should be given precedence when routing the request but, in practice, this isn't always the case. You can potentially exploit these discrepancies in much the same way as duplicate Host headers.

`GET https://vulnerable-website.com/ HTTP/1.1`&#x20;

<mark style="color:blue;">**`Host:`**</mark>` ``bad-stuff-here`

* <mark style="color:green;">**xhihu3s65epievf5qfgkoqysajgd43ss.oastify.com :**</mark> burp collaborator server&#x20;

if you are using burp suite version 2022 and later it defaults to http/2 protocol to send http requests and this protocol doesn't support supplying absolute urls in Http verbs so to overcome this problem we have to downgrade temporarily to http/1.1

<div align="left"><figure><img src="/files/HavCviyo9seq5xbNEa5L" alt=""><figcaption></figcaption></figure></div>

step1 -> go to settings

<div align="left"><figure><img src="/files/wbjC9P8nWeXszGZWS13O" alt=""><figcaption></figcaption></figure></div>

step2 -> go to HTTP

<div align="left"><figure><img src="/files/IyApdoXuVcm4ubq0cLGm" alt=""><figcaption></figcaption></figure></div>

step3 -> deselect the **Default to HTTP/2 if the server supports it** option

<div align="left"><figure><img src="/files/f9TKtNfxrK9UGVaTpFRm" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="/files/P9JEc21q93bG2U3h2594" alt=""><figcaption></figcaption></figure></div>

go to collaborator and click "poll now" and we made the application server issue request to an arbitrary server

<div align="left"><figure><img src="/files/oaieAP7TdttxCiOYjbQs" alt=""><figcaption></figcaption></figure></div>

To solve the lab, access the internal admin panel located in the `192.168.0.0/24` range, then delete the user `carlos`.

so let's make a request and making the host header walk through all the ip addresses in this range until we access the admin panel

<div align="left"><figure><img src="/files/3xjuNz82hj2xtyEhBlGS" alt=""><figcaption></figcaption></figure></div>

send this request to intruder

<div align="left"><figure><img src="/files/2L04rAqadc7nAYmpfORv" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="/files/JAh9GbU6UAT3Fmm0zpSX" alt=""><figcaption></figcaption></figure></div>

click on start attack and then click on ignore

now click on the length to show the diffrent response which will be the ip address that accessed the admin panel

so the admin panel exists at 192.168.0.165

<div align="left"><figure><img src="/files/ebwGHTPQV7hAFwxxC4Mw" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="/files/bBOKemSviV1Htjj7aFsi" alt=""><figcaption></figcaption></figure></div>

on the response click on show response on browser copy the link and paste it in the browser

<div align="left"><figure><img src="/files/XYs5Y6UPShBpGGG1dVSD" alt=""><figcaption></figcaption></figure></div>

type carlos and before clicking on delete user button intercept this request using burp

we can find it in http history let's send the request to repeater

<div align="left"><figure><img src="/files/wELIaQYAkVZgMxHQQkbY" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="/files/aiFQ8YZKkEMf1n2WDToB" alt=""><figcaption></figcaption></figure></div>

and we have solved the lab

<div align="left"><figure><img src="/files/4lC1hgHasAv4Uf5UJjOk" alt=""><figcaption></figcaption></figure></div>

hope you found this walkthrough easy to understand and follow

Greeting From [<mark style="color:red;">**Sayonara**</mark>](https://github.com/ismail-arame)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://sayonara.gitbook.io/writeups/portswigger/http-host-header-attacks/ssrf-via-flawed-request-parsing.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.