0

I have an Nginx reverse proxy that connects to different servers in the back-end according to the SNI. Recently it was pointed to me that if I add a header X-Forwarded-Host to something like https://evildomain.com would result in a redirect. Something like this:

curl -X GET "https://my.domain.com" -H "X-Forwarded-Host: evildomain.com"

And indeed, the result is a 302 Redirect:

<html><body>You are being <a href="https://evildomain.com/users/sign_in">redirected</a>.</body></html>

So, indeed, this is a misconfiguration. My question is how would an attacker exploit this?

  • If all connections are managed via HTTPS, a proxy wouldn't be able to inject headers (unless the client is connecting to the proxy via HTTP, in which case his/her problems are bigger).
  • A phishing email shouldn't be able to inject headers on a link (unless I'm allowing JS in email, in which case I have more serious issues)

The only scenario I can think of is if I'm already in an evil website and get a link to https://my.domain.com. On the call the attacker would add the headers, and the client would eventually be redirected. Is this the only scenario? How bad is it really?

Improve this question

1 Answer 1

Reset to default
1

This is at least an Open Redirect vulnerability. How easy it can be exploited depends on the client and the backends.

A malicious X-Forwarded-Host header may be injected in, for example, the following cases:

  • The reverse proxy provides a very lax CORS policy which allows an attacker to set the header in a cross-origin Ajax request.
  • The attacker controls a resource on the same origin as the reverse proxy. Then they can always add a header in Ajax requests.
  • There's an additional vulnerability in the client (not necessarily a browser) which allows the attacker to inject the header.

Once the header injection has worked, this becomes a serious problem. For example, if the client caches 302 redirects, this might be exploited for a cache poisoning attack. For a while, all requests intended for https://your-site.example.com/some/resource may be automatically sent do https://malicious-site.com/other/resource.

So you should definitely take this seriously and fix it if possible. Either remove the automatic redirect or create a whitelist of permitted redirect target.

Improve this answer

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.