Shibboleth SP Server variables in IIS

[Cantor, Scott]

> > None of them have data unless I set (exactly) attributePrefix="HTTP_"

So....yeah. Do NOT do this. That is almost certainly going to be absolutely insecure. What that does through an odd combination of behavior is cause the API we use to set server variables to essentially create internally what IIS thinks are headers. They show up in ASP as part of the headers collection even though the useHeaders option is off, which is a very clear sign they're ending up as headers.

That's probably going to be vulnerable to header spoofing from the client because turning actual header support off in the SP is also telling it not to protect against that.

We will have to verify this, but we will almost certainly end up shipping a future patch that guards against somebody doing this by accident.

I wouldn't say it's a security exposure because it's totally deliberate on the part of somebody doing this, and I'm not going to rush a patch out, but it's an accident of configuration that should not be allowed to happen.

Having said all that, that's exactly why the data suddenly shows up when it otherwise had not, but once again...I have tested this *again* and the results were the same. ASP Classic only works with headers (and this trick fools it into doing exactly that) and ASP.NET absolutely works fine when the prefix is not used via Request["Variable-Name"] at least in C#.

And to be clear ALL_RAW is NOT going to include them, nor does looping because that probably loops over ALL_RAW.

I can't tell you you're not using ASP Classic...but it sure seems like you are because that fits exactly my observed results.

In any event, do NOT do this, and please nobody else follow this advice.

There's no reason to, because if you really want headers, just turn them on. That enables the protection logic that guards against the client feeding them, and the code on the server is the same.

-- Scott