3

The question is very simple: can I trust the value of the Host header?

We are developing an application that serves some resources via HTTP and we wan't to have some private services and some others public.

We have internal domains such as "backoffice.xxxx.com" that can be only accessed internally, and we have other domains that can be accessed from anywhere.

To be more specific, this case is about an application that serves images. So we can have a path like "/pictures/xxxx" via GET and serves the image with that ID to everyone who wants to see it. But we also have mapped the "/pictures" path via POST to upload new images and we don't want anyone to upload pictures.

What we think is that we can use the Host header to validate the request and deny those who come from public domains (or just allow internal domains and deny any other).

What any other options do we have to validate this requests? (If the Host header is not safe enough).

Pablo Matias Gomez
  • 157
  • 6

2 Answers2

5

No.

It is trivial to change the value of the host header, but, depending on your server set up, this may cause the site not to work as intended. In particular, if you are using name based virtual hosts, the web server will look at the host header to determine which site (of many) to load, and (usually) default to the first defined one if it doesn't recognise the host header.

If you have an internal network, you will presumably have a range of internal IP addresses. It is possible to restrict access to functions based on that, although the specific settings depend on the web server in use. You could also look at having LDAP or similar centralised authorisation, so only requests from internal users who have signed in in some way can provide an authorisation header. This is ideal if you are running with a Windows domain - you may even be able to have automatic login to the administration functions in this case, based on the logged in user on the computer.

Matthew
  • 27,233
  • 7
  • 87
  • 101
4

The host header will be the hostname of your web server, and is only used in HTTP requests by clients. It can not be used to validate if the source is authorized to upload images or not. I would develop a login mechanism to which users can authenticate (possibly with a directory service, as mentioned by Matthew) and if authorized, upload new pictures. Deny all other access to the webpage mapped to /pictures. In combination with SSL/TLS and solid password management, this is the most controllable and secure solution.

Stef Heylen
  • 1,726
  • 1
  • 14
  • 16