From 7255d2401160a4107a394fb71242c0d8d0a2396a Mon Sep 17 00:00:00 2001
From: Mehdi <pentest.co@gmail.com>
Date: Fri, 2 Aug 2024 17:31:40 +0330
Subject: [PATCH] Update writeups.md

---
 writeups.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/writeups.md b/writeups.md
index a62b8a5..7550307 100644
--- a/writeups.md
+++ b/writeups.md
@@ -17,9 +17,9 @@ echo "testphp.vulnweb.com" | gauplus | grep "?" | qsreplace 'xssz"><img/src=x on
 ## 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!
 
-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.