MatMoore
commented
1 month ago The permanent redirect from HTTP -> HTTPS is this kubernetes default behaviour https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#server-side-https-enforcement-through-redirect
This kicks in before the request reaches django, which does validate the host header.
The remediation above assumes we are directly configuring nginx, but we're configuring it via kubernetes annotations so this needs adapting.
Modsecurity documentation is here https://user-guide.cloud-platform.service.justice.gov.uk/documentation/networking/modsecurity.html
LavMatt
The service appears to implicitly trust the user-supplied Host header. If this input is not properly validated, an attacker could inject harmful payloads through the Host header, manipulating server-side behaviour.
During this assessment, it was possible to inject an arbitrary domain name into the Host header, resulting in the server responding with a 308 redirection response. This vulnerability allows an attacker to potentially poison the web cache. By exploiting this vector, an adversary could cause future requests to be redirected to a malicious domain, leading to various harmful outcomes.
Additionally, if the target URL does not match the Host header, the application appears to redirect users to a different website. This mismatch can create confusion for the server and intermediary systems such as proxies, load balancers, or caching layers.
If an attacker repeatedly sends requests with a malicious domain in the Host header, and the website uses a web cache, this could lead to cache poisoning. Consequently, all future requests to the site could be redirected to an attacker-controlled domain. This redirection could facilitate further malicious activities, such as phishing, malware distribution, or data theft.
Proof of Concept:
Similarly if the host header is changed, it redirects to exploit-db.com
Likelihood is as follows:
Social Engineering Attack: The likelihood of tricking a user to click a malicious link through social engineering is mitigated by browsers that ensure a valid host header is always supplied. This reduces the risk of such an attack being successful through mere social engineering tactics.
Scripted Attack: The likelihood of a scripted attack that exploits the host header to poison the web cache is higher, provided that the attacker has the capability to manipulate the host headers and the targeted website has not implemented adequate protections against cache poisoning. This type of attack requires specific conditions (e.g., a vulnerable caching mechanism) to be successful but is plausible if these conditions are met.
Remediation
To enhance security in NGINX configurations, it's crucial to validate host headers effectively. This involves setting up checks that only allow requests from recognized hostnames, thereby preventing unauthorised access and potential security vulnerabilities like web cache poisoning. By implementing a validation process that includes a whitelist of approved hostnames and rejecting requests that do not match these names, organisations can safeguard their environments from various host header attacks. This approach is fundamental in maintaining the integrity and security of web applications served by NGINX.
https://blog.shalvah.me/posts/fixing-the-host-header-vulnerability-with-nginx