SP assistance needed for "Attempt to spoof header"

[Doan, Tommy]

Thanks Scott. I've been tracing and comparing the headers but I'm afraid I need the explanation broken down even more so I can understand. Sorry to show so much naivety, but how can I tell what headers the SP has been told to set and control so I can determine what may have been smuggled in to set off the spoof alarm? 

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Monday, February 20, 2017 8:58 AM
To: Shib Users <users at shibboleth.net>
Subject: RE: SP assistance needed for "Attempt to spoof header"

> 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


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net