Let op, HTTP_HOST is niet altijd betrouwbaar

Als je in je applicatie wilt weten welke site exact wordt aangesproken in een omgeving die naar verschillende domeinen luistert, kan je gebruikmaken van Request-variabele HTTP_HOST. Als ik naar www.w3c.org gaat, dan zal de variabele HTTP_HOST op die server www.w3c.org zijn, bijvoorbeeld.

Hier zit echter een addertje onder het gras! HTTP_HOST is namelijk een waarde die door de client, in de meeste gevallen een browser, meegestuurd wordt.

Een voorbeeld: In .NET Core heb ik simpele webapplicatie gemaakt. Als ik met de browser naar https://localhost:44329/ ga, dan staat er in de browser:

HTTP_HOST: localhost:44329

Dit doe ik via:

ViewData["HTTP_HOST"] = Request.Host;
//en:
HTTP_HOST: @ViewData["HTTP_HOST"]

In de console zie ik dat er een Request-header wordt gestuurd:

Host: localhost:44329

Niks aan de hand. Ik kan deze pagina ook aanroepen via curl, maar dan een andere Host-header meesturen:

curl https://localhost:44329/ -H 'Host:localhost:1234'

Het antwoord van de server is in dat geval:

HTTP_HOST: localhost:1234

Dit is omdat HTTP_HOST is gebaseerd op de header die wordt meegestuurd door de client (curl stuurt standaard het aangeroepen domein mee als Host-header). Dit zal vrijwel nooit een probleem opleveren, of eerder: dit probleem zal zich niet snel voordoen, maar dat kan wel gebeuren als een browser een normaal poortnummer meestuurt, dus localhost:80 of localhost:443, terwijl je in je applicatie verwacht dat localhost wordt meegestuurd als header.

Mocht ik een ander domein meegeven, dus: curl https://localhost:44329/ -H 'Host:sigmasolutions.nl', dan geeft .NET Core terug: Bad Request - Invalid Hostname. Dat is goed; er kan door een kwaadwillende client niet gedaan worden alsof het een andere site bezoekt.

Dit is kortom een potentiële valkuil voor je applicatie. Hou hier rekening mee door geen gebruik te maken van HTTP_HOST, maar bijvoorbeeld SERVER_NAME, als dat nodig is, of zorg ervoor dat het poortnummer, als deze aanwezig is, wordt verwijderd.