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".
This same issue exists on many VoIP networks as they share the same broken parsing ideas (in SIP).
1: HTTP allows you to line wrap headers and add comments. 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.
Actually, most header fields don't allow comments. The most common one that does (User-Agent) isn't exactly necessary for processing, and is its own little world of bizarre pain.
There's a lot of historical header abuse caused by the fact that HTTP sort of shared a syntax with email MIME headers, but HTTP implementations have generally started treating such abuses as malformed. (MIME on the other hand still hasn't. It's actually quite gory.)
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?
By using Squid you can easily proxy requests using (for example) HTTP_PROXY environment variable, Squid can then be exposed over ssh. Proxying over socks (-D) or every individual website (-L) becomes rather tiresome. Not all programs will be able to do socks proxies but most can do http proxies - http/1.1 over nc can use a http proxy!
I'd say the point is valid though if the only function the tunnel is supposed to fulfil is channelling traffic from and to a web browser.
As far as browsers go, only Internet Explorer lacks SOCKS5 support. And I doubt an office which such stringent header filtering has an IT department that doesn't provide people with proper browsers...
I'd actually argue that an office with stringent and archaic filtering of internet use is precisely the type of office to provide only IE, laden with corporate spyware.
> But IIS was misconfigured to rewrite Remote_Addr from X-Forwarded-For if it existed.
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?
I wouldn't mind that; I just like peeking at internal admin panels and observing how much design effort a company or individual decides to put into an "industrial" software system that's only meant for internal and/or limited use.
Considering it'd be looking at live data, I would be somewhat freaked out if censor bars weren't present.
What is strange about it? Fast should be clear. Responsive I'm guessing indicates they talked it over (related to fast probably). And reasonable I'm guessing means didn't threaten to sue him for hacking SO and accepted their mistake and wanted to fix it.
Its the expectation / perspective he had. He is talking like someone who had to report the problem, who had to have his issue resolved and was really pleased with the service.
Its not like he just bought an iPhone which had a flaw and he was happy with the customer service that resolved the issue, but it reads like that.
To be more blunt, he is using rhetoric in his article, probably acquired through osmosis from reading other articles, without actually realizing that the rhetoric doesn't apply to his situation.
This same issue exists on many VoIP networks as they share the same broken parsing ideas (in SIP).
1: HTTP allows you to line wrap headers and add comments. 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.