vos9/Web_Hacking
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update writeups.md

Browse Source
This commit is contained in:
Mehdi 2024-08-02 17:31:40 +03:30 committed by GitHub
parent 443e2c456a
commit 7255d24011
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
writeups.md
View File

@ -17,9 +17,9 @@ echo "testphp.vulnweb.com" | gauplus | grep "?" | qsreplace 'xssz"><img/src=x on
## The Blank Host Header trick ## The Blank Host Header trick
**Concise tip:** Try to find places in websites where the “host” HTTP header is reflected on the page. If you find this, try a blank host header in the request and the website may leak internal hostnames! **Concise tip:** Try to find places in websites where the “host” HTTP header is reflected on the page. If you find this, try a blank host header in the request and the website may leak internal hostnames!
If a site is reflecting the host header in the response even when you it to something like example.com, it may be vulnerable to this. First, you need to change the HTTP protocol on the request from HTTP/1.1, the default, to HTTP/1.0. This is because empty host headers are invalid in the newer protocol. This is done in different ways depending on how you are replaying this HTTP request, but for example in Burp Repeater, you simply change “HTTP/1.1” in the top line of the request to “HTTP/1.0”. Next, you want to make the “host” HTTP header blank, so it looks like “Host:”. Now when you send the request, the response may show an IP address or a weird looking web address where the host header was previously reflected. 99% of the time this is an internal hostname or an internal IP address. These can be used in other exploits to perform attacks on internal infrastructure, so companies generally do not want these leaked! If a site is reflecting the host header in the response even when you it to something like example.com, it may be vulnerable to this. First, you need to change the HTTP protocol on the request from `HTTP/1.1`, the default, to `HTTP/1.0`. This is because empty host headers are invalid in the newer protocol. This is done in different ways depending on how you are replaying this HTTP request, but for example in Burp Repeater, you simply change `HTTP/1.1` in the top line of the request to `HTTP/1.0`. Next, you want to make the `host` HTTP header **blank**, so it looks like `Host:`. Now when you send the request, the response may show an IP address or a weird looking web address where the host header was previously reflected. **99%** of the time this is an **internal hostname or an internal IP address**. These can be used in other exploits to perform attacks on internal infrastructure, so companies generally do not want these leaked!
This is common on Apache servers when the bottom line of an error page reads something like “Apache Server at example.com Port 443” because example.com is simply being reflected from the host header in the request. This is common on `Apache` servers when the bottom line of an error page reads something like **Apache Server at example.com Port 443** because example.com is simply being reflected from the host header in the request.