|
2 | 2 |
|
3 | 3 | ## How it works |
4 | 4 |
|
5 | | -* [https://portswigger.net/web-security/host-header](https://portswigger.net/web-security/host-header) |
6 | | -* [https://www.intruder.io/research/practical-http-header-smuggling](https://www.intruder.io/research/practical-http-header-smuggling) |
7 | | - |
8 | | -<details> |
9 | | - |
10 | | -<summary>Basics</summary> |
| 5 | +### **Basics** |
11 | 6 |
|
12 | 7 | * The HTTP Host header is a mandatory request header as of HTTP/1.1. It specifies the domain name that the client wants to access |
13 | 8 | * The purpose of the HTTP Host header is to help identify which back-end component the client wants to communicate with. This can occur with a single server hosting multiple domains or when websites are hosted on distinct back-end servers, but all traffic between the client and servers is routed through an intermediary system. This could be a simple load balancer or a reverse proxy server of some kind. |
|
19 | 14 | *  Routing-based SSRF |
20 | 15 | *  Classic server-side vulnerabilities, such as SQL injection |
21 | 16 |
|
22 | | -</details> |
| 17 | +### **Reference** |
23 | 18 |
|
24 | | -## Recon and Identification |
| 19 | +* [https://portswigger.net/web-security/host-header](https://portswigger.net/web-security/host-header) |
| 20 | +* [https://www.intruder.io/research/practical-http-header-smuggling](https://www.intruder.io/research/practical-http-header-smuggling) |
25 | 21 |
|
26 | | -<details> |
| 22 | +## Recon and Identification |
27 | 23 |
|
28 | | -<summary>Give an arbitrary Host header and Check for flawed validation</summary> |
| 24 | +### Give an arbitrary Host header and Check for flawed validation |
29 | 25 |
|
30 | 26 | *  You should try to understand how the website parses the Host header. This can sometimes reveal loopholes that can be used to bypass the validation. For example, some parsing algorithms will omit the port from the Host header, meaning that only the domain name is validated. If you are also able to supply a non-numeric port, you can leave the domain name untouched to ensure that you reach the target application, while potentially injecting a payload via the port. |
31 | 27 |
|
|
40 | 36 |  `GET /example HTTP/1.1`\ |
41 | 37 |  `Host: hacked-subdomain.vulnerable-website.com` |
42 | 38 |
|
43 | | - |
44 | | - |
45 | | -</details> |
46 | | - |
47 | | -<details> |
48 | | - |
49 | | -<summary>Send ambiguous requests</summary> |
| 39 | +### Send ambiguous requests |
50 | 40 |
|
51 | 41 | * Inject duplicate headers |
52 | 42 | *  `GET /example HTTP/1.1`\ |
|
58 | 48 | * Add line wrapping |
59 | 49 | * Misc HTTP request smuggling techniques |
60 | 50 |
|
61 | | -</details> |
62 | | - |
63 | | -<details> |
64 | | - |
65 | | -<summary>Inject override headers</summary> |
| 51 | +### Inject override headers |
66 | 52 |
|
67 | 53 | * You can sometimes use `X-Forwarded-Host` to inject your malicious input while circumventing any validation on the Host header itself. |
68 | 54 | *  `GET /example HTTP/1.1`\ |
|
74 | 60 | *  `X-HTTP-Host-Override` |
75 | 61 | *  `Forwarded` |
76 | 62 |
|
77 | | -</details> |
78 | | - |
79 | 63 | ## **HTTP Header Attacks** |
80 | 64 |
|
81 | 65 | **\*\*\*** In Burp Suite, you can use the [Param Miner](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) extension's "Guess headers" function to automatically probe for supported headers using its extensive built-in wordlist.\*\*\* |
82 | 66 |
|
83 | | -<details> |
84 | | - |
85 | | -<summary>Password Reset poisoning</summary> |
| 67 | +### **Password Reset poisoning** |
86 | 68 |
|
87 | | -* [https://portswigger.net/web-security/host-header/exploiting/password-reset-poisoning](https://portswigger.net/web-security/host-header/exploiting/password-reset-poisoning) |
88 | 69 | * Attack Process |
89 | 70 | 1.  The attacker obtains the victim's email address or username, as required, and submits a password reset request on their behalf. When submitting the form, they intercept the resulting HTTP request and modify the Host header so that it points to a domain that they control. For this example, we'll use `evil-user.net`. |
90 | 71 | 2.  The victim receives a genuine password reset email directly from the website. This seems to contain an ordinary link to reset their password and, crucially, contains a valid password reset token that is associated with their account. However, the domain name in the URL points to the attacker's server:\ |
91 | 72 |  `https://evil-user.net/reset?token=0a1b2c3d4e5f6g7h8i9j` |
92 | 73 | 3.  If the victim clicks this link (or it is fetched in some other way, for example, by an antivirus scanner) the password reset token will be delivered to the attacker's server. |
93 | 74 | 4.  The attacker can now visit the real URL for the vulnerable website and supply the victim's stolen token via the corresponding parameter. They will then be able to reset the user's password to whatever they like and subsequently log in to their account. |
| 75 | +* [https://portswigger.net/web-security/host-header/exploiting/password-reset-poisoning](https://portswigger.net/web-security/host-header/exploiting/password-reset-poisoning) |
94 | 76 |
|
| 77 | +### **Web Cache Poisoning via Host Header** |
95 | 78 |
|
96 | | - |
97 | | -</details> |
98 | | - |
99 | | -<details> |
100 | | - |
101 | | -<summary>Web Cache Poisoning via Host Header</summary> |
102 | | - |
103 | | -* To construct a web cache poisoning attack, you need to elicit a response from the server that reflects an injected payload. The challenge is to do this while preserving a cache key that will still be mapped to other users' requests. If successful, the next step is to get this malicious response cached. It will then be served to any users who attempt to visit the affected page. |
| 79 | +*  **** To construct a web cache poisoning attack, you need to elicit a response from the server that reflects an injected payload. The challenge is to do this while preserving a cache key that will still be mapped to other users' requests. If successful, the next step is to get this malicious response cached. It will then be served to any users who attempt to visit the affected page. |
104 | 80 | * [https://portswigger.net/web-security/web-cache-poisoning](https://portswigger.net/web-security/web-cache-poisoning) |
105 | 81 | * [https://portswigger.net/web-security/host-header/exploiting/lab-host-header-web-cache-poisoning-via-ambiguous-requests](https://portswigger.net/web-security/host-header/exploiting/lab-host-header-web-cache-poisoning-via-ambiguous-requests) |
106 | 82 |
|
107 | | -</details> |
| 83 | +### **Classic Server-Side Vulnerabilities** - SQL Injection via the Host Header |
108 | 84 |
|
109 | | -<details> |
110 | | - |
111 | | -<summary>Accessing Restricted Functionality</summary> |
| 85 | +### **Accessing Restricted Functionality** |
112 | 86 |
|
113 | 87 | * Some websites' access control features make flawed assumptions that allow you to bypass these restrictions by making simple modifications to the Host header. |
114 | 88 | * [https://portswigger.net/web-security/host-header/exploiting/lab-host-header-authentication-bypass](https://portswigger.net/web-security/host-header/exploiting/lab-host-header-authentication-bypass) |
115 | 89 |
|
116 | | - |
117 | | - |
118 | | -</details> |
119 | | - |
120 | | -<details> |
121 | | - |
122 | | -<summary>Accessing Internal Websites via Host Brute-Forcing</summary> |
| 90 | +### **Accessing Internal Websites via Host Brute-Forcing** |
123 | 91 |
|
124 | 92 | *  Companies sometimes make the mistake of hosting publicly accessible websites and private, internal sites on the same server. Servers typically have both a public and a private IP address. As the internal hostname may resolve to the private IP address, this scenario can't always be detected simply by looking at DNS records: |
125 | 93 |
|
126 | 94 |  `www.example.com: 12.34.56.78`\ |
127 | 95 |  `intranet.example.com: 10.0.0.132` |
128 | 96 | * In some cases, the internal site might not even have a public DNS record associated with it. Nonetheless, an attacker can typically access any virtual host on any server that they have access to, provided they can guess the hostnames. |
129 | 97 |
|
130 | | -</details> |
131 | | - |
132 | | -<details> |
133 | | - |
134 | | -<summary>Routing Based SSRF</summary> |
| 98 | +### **Routing Based SSRF** |
135 | 99 |
|
136 | 100 | * It is possible to use the Host header to launch high-impact, routing-based SSRF attacks. These are sometimes known as "Host header SSRF attacks". |
137 | 101 | *  You can use Burp Collaborator to help identify these vulnerabilities. If you supply the domain of your Collaborator server in the Host header, and subsequently receive a DNS lookup from the target server or another in-path system, this indicates that you may be able to route requests to arbitrary domains. |
138 | 102 | *  Having confirmed that you can successfully manipulate an intermediary system to route your requests to an arbitrary public server, the next step is to see if you can exploit this behavior to access internal-only systems. To do this, you'll need to identify private IP addresses that are in use on the target's internal network. In addition to any IP addresses that are leaked by the application, you can also scan hostnames belonging to the company to see if any resolve to a private IP address. If all else fails, you can still identify valid IP addresses by simply brute-forcing standard private IP ranges, such as `192.168.0.0/16`. |
139 | 103 | * [https://portswigger.net/web-security/host-header/exploiting/lab-host-header-routing-based-ssrf](https://portswigger.net/web-security/host-header/exploiting/lab-host-header-routing-based-ssrf) |
140 | 104 | * [https://portswigger.net/web-security/host-header/exploiting/lab-host-header-ssrf-via-flawed-request-parsing](https://portswigger.net/web-security/host-header/exploiting/lab-host-header-ssrf-via-flawed-request-parsing) |
141 | 105 |
|
142 | | -</details> |
143 | | - |
144 | | -<details> |
| 106 | +### **SSRF via Malformed Request Line** |
145 | 107 |
|
146 | | -<summary>SSRF via Malformed Request Line</summary> |
147 | | - |
148 | | -* Custom proxies sometimes fail to validate the request line properly, which can allow you to supply unusual, malformed input with unfortunate results. |
| 108 | +*  Custom proxies sometimes fail to validate the request line properly, which can allow you to supply unusual, malformed input with unfortunate results. |
149 | 109 | *  For example, a reverse proxy might take the path from the request line, prefix it with `http://backend-server`, and route the request to that upstream URL. This works fine if the path starts with a `/` character, but what if starts with an `@` character instead? |
150 | 110 |
|
151 | 111 |  `GET @private-intranet/example HTTP/1.1` |
152 | 112 | *  The resulting upstream URL will be `http://backend-server@private-intranet/example`, which most HTTP libraries interpret as a request to access `private-intranet` with the username `backend-server`. |
153 | 113 |
|
154 | | -</details> |
155 | | - |
156 | 114 | ## **HTTP Header Attack Protection** |
157 | 115 |
|
158 | 116 | * **Protect absolute URLs -** When you have to use absolute URLs, you should require the current domain to be manually specified in a configuration file and refer to this value instead of the Host header. This approach would eliminate the threat of password reset poisoning, for example. |
|
0 commit comments