Heuristic underlying TRUSTED_PROXY may be flawed.

[Patrick Nelson]

Just throwing this out there, in case anyone else thinks this may need to escalate to an issue/PR. I suppose this is currently already an issue, since by default this is enabled. However, I think it should be completely removed and all areas depending on it refactored.

Basically what I'm thinking is that, while for the moment it appears that the TRUSTED_PROXY constant is working pretty well in some situations (determining SSL status and IP address), what if the framework checks Client-IP first (which may be spoofed) while my actual proxy uses X-Forwarded-For (which the framework checks second)? There's nothing prevent a malicious client from crafting either of these. 

Therefore, I'm suggesting that proxy configuration should entail manual configuration not only of trusted IP's (already basically done) but also trusted headers, once the upstream proxy IP address is validated. Maybe be able to also configure which headers are trusted on a per-proxy basis (i.e. basically requiring this to be entirely YAML-based config).

What do y'all think?

- Patrick

[Ingo Schommer]

Hey Patrick, you're onto something there - unless the proxy filters out these headers already, there's still some potential for spoofing. I've kicked off a discussion with the security team, you can expect a release soon. In the future, if you're unsure whether an issue is security related, please email secu...@silverstripe.org first before posting here :)