In this case, you may be able to bypass the validation entirely by registering an arbitrary domain name that ends with the same sequence of characters as a whitelisted one:Īlternatively, you could take advantage of a less-secure subdomain that you have already compromised: Other sites will try to apply matching logic to allow for arbitrary subdomains. 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. For example, some parsing algorithms will omit the port from the Host header, meaning that only the domain name is validated. This can sometimes reveal loopholes that can be used to bypass the validation. You should try to understand how the website parses the Host header. This doesn't necessarily mean that they're immune to Host header attacks. For example, some websites will validate whether the Host header matches the SNI from the TLS handshake. Instead of receiving an " Invalid Host header" response, you might find that your request is blocked as a result of some kind of security measure. In this case, you should move on to trying some of the techniques outlined below. This is especially likely if your target is accessed via a CDN. The front-end server or load balancer that received your request may simply not know where to forward it, resulting in an " Invalid Host header" error of some kind. On the other hand, as the Host header is such a fundamental part of how the websites work, tampering with it often means you will be unable to reach the target application at all. In this case, you can begin studying what the application does with the Host header and whether this behavior is exploitable. If your target website happens to be the default, you're in luck. For example, servers are sometimes configured with a default or fallback option in case they receive requests for domain names that they don't recognize. Sometimes, you will still be able to access the target website even when you supply an unexpected Host header. You can edit the target manually by clicking the pencil icon. The target URL is displayed either at the top of the panel (for Burp Repeater and Proxy interception) or on the "Target" tab in Burp Intruder. This separation allows you to supply any arbitrary or malformed Host header that you want, while still making sure that the request is sent to the intended target. However, Burp Suite accurately maintains the separation between the Host header and the target IP address. Some intercepting proxies derive the target IP address from the Host header directly, which makes this kind of testing all but impossible any changes you made to the header would just cause the request to be sent to a completely different IP address. When probing for Host header injection vulnerabilities, the first step is to test what happens when you supply an arbitrary, unrecognized domain name via the Host header. If so, you can use this header to probe the application and observe what effect this has on the response. In short, you need to identify whether you are able to modify the Host header and still reach the target application with your request. To test whether a website is vulnerable to attack via the HTTP Host header, you will need an intercepting proxy, such as Burp Proxy, and manual testing tools like Burp Repeater and Burp Intruder. How to test for vulnerabilities using the HTTP Host header We'll then provide examples of how you can exploit this, along with several interactive labs that you can use to practice these exploits on a deliberately vulnerable website. In this section, we'll look more closely at how you can identify whether a website is vulnerable to HTTP Host header attacks. How to identify and exploit HTTP Host header vulnerabilities
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |