2

I have a backend web server that serves an API (over HTTPS) to a frontend browser client on a different subdomain. It uses CORS to allow this.

The CORS spec directs you to not send the CORS headers if the origin isn't present or doesn't match your list of permitted origins, which I do.

But Section 6.3 adds that:

In addition to checking the Origin header, resource authors are strongly encouraged to also check the Host header. That is, make sure that the host name provided by that header matches the host name of the server on which the resource resides. This will provide protection against DNS rebinding attacks.

Is this valuable to add to our API server? My understanding is that DNS rebinding is an attack that you'd perform to access something on a local system like a router, so I'm not sure if that applies to us.

If we should check the Host header, what action should we take? Just not sending back the CORS headers, or rejecting the request altogether? The first option makes more sense to me, since otherwise the recommendation wouldn't belong in a CORS spec, but the document is unclear.

Improve this question
2
  • You say the backend server serves an API "to a frontend web server"; is the frontend server making the request to the backend server (acting as a client to the backend), or is the frontend server delivering web content that causes the user's client (web browser) to access the backend server? The latter is the usual case for CORS; if it's the former, you should just firewall off the backend server such that it can't be accessed by anything except the frontend, and use an HTTP client library that can make arbitrary requests without bothering with CORS. Commented Jul 12, 2018 at 23:10
  • @CBHacking Sorry that was unclear—it's the latter. Commented Jul 13, 2018 at 0:58

1 Answer 1

Reset to default
2

My understanding is that DNS rebinding is an attack that you'd perform to access something on a local system like a router ...

A DNS rebinding attack is not restricted to a router or other local network devices. It is an attack which is used to bypass the same origin policy and thus not only submit data to a server like in CSRF but also read the response back.

While the typical use case is to read data from servers which can not be directly reached from outside (like the internal company wiki) it could for example also be used to get data from internet reachable systems which use IP-based authentication (i.e. some client given special rights based on there source IP address).

Given that CORS is about restricting cross-site read/write the recommendation to check the Host header in order to protect against DNS rebinding makes sense, since DNS rebinding is essentially the attempt to make a cross-site request behave like a same-site request.

Improve this answer
2
  • Thanks @SteffenUllrich. Do you know if the correct thing to do is not send back the CORS headers in the case of a Host-mismatch, or should we reject the requests altogether? Commented Jul 12, 2018 at 21:37
  • @MaxGabriel Generally a mismatched Host header indicates either a client error / bug, a DNS error, or a malicious request. It's perfectly reasonable to return HTTP 400 (with no CORS headers) in that case, or even just close the connection without responding at all. A legit client might try connecting by IP rather than hostname, but this is essentially never done for HTTPS (it'll result in cert errors) and in any case doesn't work on multi-tenant servers, so it's generally fine to not support this case. That's especially true when the only expected client is running your own code! Commented Jul 12, 2018 at 23:05

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.