4 ms·

What would CloudFlare automatically check the Host header against? The Host header would be set to the attacker's domain (which is in CloudFlare) and, per OP, C

by EB66 6y ago

What would CloudFlare automatically check the Host header against? The Host header would be set to the attacker's domain (which is in CloudFlare) and, per OP, CloudFlare does not verify ownership of the origin server IP. It would be a nice feature if CloudFlare customers could opt-in for origin server IP verification. Once the origin IP is verified, it would prevent other CloudFlare users from using the IP as their own origin. However, I understand why CloudFlare doesn't verify origin IPs -- it would require a verification process that doesn't rely solely on uploading a verification file to a web accessible directory. It'd be a bit difficult to keep the verification process simple for end-users if they aren't running a web server. Or maybe I'm wrong and non-HTTP use cases don't need to be considered and a verification file uploaded to a web accessible folder would work fine.

orf 6y ago
Somewhere in the interface you’d have a button that when pressed would send a request to the specified origin server with a Host header set to “foobar.com”. If the status code is 200 you’d display a warning saying “perhaps you should re-read our documentation about verifying host headers”. I can think of a whole bunch of corner cases to this, but that’s the general jist.
- EB66 6y ago
  But in order to safely enable that check for all requests that go from CloudFlare to the origin IP, you would first need to verify ownership of the origin IP. You wouldn't want users who don't own the origin IP to be able to turn on that sort of check and potentially cause a service disruption. It could be the case that the legitimate owner already has a Host header mismatch in their HTTP requests/responses.
  - floatingatoll 6y ago
    Presenting a warning about possible misconfiguration to the customer need not create a service disruption.
    - EB66 6y ago
      We're talking about a situation where an attacker would create the service disruption by enabling Host header checks on an origin server that the attacker doesn't own. So a warning wouldn't help because that warning would be displayed to the attacker. The logic is tricky, but in the end origin server ownership verification is what's required to safely support Host header checks.
      - floatingatoll 6y ago
        If the attacker is logged into the Cloudflare control panel, where presumably the warning would be displayed — where else could it be displayed? certainly not on the content served to end users — then, yes, the attacker could clear the warning. They could also change the origin servers, or do countless other things to disrupt service, that do not require modifying an origin server. I consider that an acceptable failure case for the warning. I'm not arguing for or against ownership verification, but there is opportunity to improve here that does not depend on the question of ownership verification.
EE84M3i 6y ago
I could understand verifying domain names, but verifying IP addresses seems like it would be an extremely complex feature for very little benefit. You'd have to have implement it in-line with the dns resolution in the server before talking to the origin, right? There's no other time you could reasonably do it (DNS changes), and it would have to be checked on all customers requests, not just the ones that opted into the feature (because those other customers could be the "attacker"!). Of course, you would cache it and use an efficient lookup scheme, but in general cloud services really don't like creating features that have non-localized effects like this. Not to mention this sounds like a support nightmare foot gun for enterprise customers.

by EB66 6y ago

orf 6y ago

Somewhere in the interface you’d have a button that when pressed would send a request to the specified origin server with a Host header set to “foobar.com”. If the status code is 200 you’d display a warning saying “perhaps you should re-read our documentation about verifying host headers”. I can think of a whole bunch of corner cases to this, but that’s the general jist.

EB66 6y ago
But in order to safely enable that check for all requests that go from CloudFlare to the origin IP, you would first need to verify ownership of the origin IP. You wouldn't want users who don't own the origin IP to be able to turn on that sort of check and potentially cause a service disruption. It could be the case that the legitimate owner already has a Host header mismatch in their HTTP requests/responses.
- floatingatoll 6y ago
  Presenting a warning about possible misconfiguration to the customer need not create a service disruption.
  - EB66 6y ago
    We're talking about a situation where an attacker would create the service disruption by enabling Host header checks on an origin server that the attacker doesn't own. So a warning wouldn't help because that warning would be displayed to the attacker. The logic is tricky, but in the end origin server ownership verification is what's required to safely support Host header checks.
    - floatingatoll 6y ago
      If the attacker is logged into the Cloudflare control panel, where presumably the warning would be displayed — where else could it be displayed? certainly not on the content served to end users — then, yes, the attacker could clear the warning. They could also change the origin servers, or do countless other things to disrupt service, that do not require modifying an origin server. I consider that an acceptable failure case for the warning. I'm not arguing for or against ownership verification, but there is opportunity to improve here that does not depend on the question of ownership verification.

EE84M3i 6y ago

I could understand verifying domain names, but verifying IP addresses seems like it would be an extremely complex feature for very little benefit. You'd have to have implement it in-line with the dns resolution in the server before talking to the origin, right? There's no other time you could reasonably do it (DNS changes), and it would have to be checked on all customers requests, not just the ones that opted into the feature (because those other customers could be the "attacker"!). Of course, you would cache it and use an efficient lookup scheme, but in general cloud services really don't like creating features that have non-localized effects like this. Not to mention this sounds like a support nightmare foot gun for enterprise customers.