Inband signalling is such a terrible idea and is so hard to get right. Here's the next step: try screwing up how you write headers. Use line wrapping and comments[1], or mix up crlf with just cr or lf. Very possible you'll make one proxy ignore your malicious header, but have the next HTTP software take it. This type of attack can be called "confused deputy".<p>This same issue exists on many VoIP networks as they share the same broken parsing ideas (in SIP).<p>1: HTTP allows you to line wrap headers and add <i>comments</i>. It's stupidly bizarre. It comes from the 70s or 60s where you wouldn't have a client program, so human-formatted headers weren't just a debug benefit, but a necessary requirement. The IETF can be rather clueless, so they blindly copy these terrible ideas into new protocols, like HTTP and SIP.
IP white-listing can be great until you one day add a load balancer and all requests now come from a trusted IP :P<p>Lesson learned: Add more "layers" of security.
What was the advantage of directing your requests through ssh and Squid, as opposed to just ssh? Squid page talks about reducing bandwidth, was that it?
It sounds like this was the root of the problem:<p><i>> But IIS was misconfigured to rewrite Remote_Addr from X-Forwarded-For if it existed.</i><p>Does anyone know why that might've happened? Is this something IIS does by default, something it inadvertently encourages, etc.? And is there another example of a web server doing something like this?
> Not only was I not denied access, but I was granted full access to everything. I had the developer console to see what people were doing.<p>Now THAT would be an awesome screenshot.
Interesting.<p>As an aside, I find this phrase strange, given the context:<p>"The SO team was absolutely incredible to deal with during this. They were fast, responsive and reasonable."