SP assistance needed for "Attempt to spoof header"

[Cantor, Scott]

> The only way I've been able to get the CREF elements to function is by
> modifying the SP configuration for HCM to set checkSpoofing="false" and the
> RequestMap to requireSession="false" for the few query string parameters
> I've identified that trigger the spoof prevention. However, this is not a
> configuration I feel comfortable moving to production.

You shouldn't, that's a really bad idea. The setting is only there for people who are deliberately proxying or who may have internal filters or extensions that are causing subrequests that are known to be safe, which is pretty much nobody. In all the years since the issues were fixed and the code changed, there have been almost no real complaints that it's firing when it shouldn't, so if it says you're spoofing, you're probably spoofing. (I'm told the official OWASP term for this is "smuggling", actually.)

> I've been unable to find details about the exact behavior of the
> checkSpoofing feature of the SP and what exactly causes it to trigger

It means the request contained headers that the SP is being told to set and control. The only way to get the error is to try and smuggle in an attribute header that shouldn't be there. The code even has some allowances for subrequests as it is, and generally can tell when IIS might be recursively invoking itself, and the error means it's not doing that.

> Setting REMOTE_ADDR="X-
> Forwarded-For" on both SPs and then on each of them independently does
> not appear to change the behavior of the problem, although I've confirmed
> the source IP is available to the SP in that configuration.

That is not a header the SP is controlling, but if your load balancer has the same flaws that the early SP code did, you cannot rely on proxy-forwarded IP addresses anyway. Doesn't really have anything to do with the issue, just noting it since I found it out very recently. Hard for me to throw stones since I botched it myself, though the difference is I actually cared enough to fix it.

> I need advice on how
> to troubleshoot the problem and determine exactly what causes the spoof
> protection to fire.

Traffic tracing is the only practical way to debug it, but it means what it says, so whatever you're doing, you really just can't do it.

-- Scott