SpoofChecking

Background

The SP includes a feature called "spoof checking". The purpose of this feature is to actively scan/police the HTTP headers in each client request and attempt to detect if any of them map to a header variable under the SP's "control". The SP maintains a list of all the possible header names that it might be expected to create in response to a user session, including all of the mappings based on attributes. If the client attempts to supply its own value for one of these headers, this feature tries to detect that and block the request with an error message (and log the attempt).

In general, and this is noted below, you should always favor server variables to request headers. Server variables cannot be influenced by the client and are much safer. This feature is ignored in such cases.

The following provides more detail on how to ensure the feature is active and how to avoid false alarms without compromising the feature.

Note that this feature is NOT the only measure taken by the SP to prevent spoofing. The SP still clears or removes any headers that it controls using a variety of algorithms. This feature is an additional measure of protection, because those algorithms are complex and have a history of not proving to be foolproof.

General Settings

There are two settings that control the operation of this feature, both found in the <InProcess> configuration element.

The checkSpoofing property is a flag that is enabled when omitted, and is set only to explicitly disable the feature.

The other property is called spoofKey, and is now supported across all the relevant module implementations as a way of preventing false alarms triggered by server-side behavior. There are specific notes in the platform-specific sections below, but in general, all the implementations support the use of an explicit value in this setting.

The spoofKey value is intended to be a long, random string of alphanumerics that is hidden from clients. The SP uses this value to distinguish between requests from a client and requests to which the SP has already added headers. It explicitly creates an extra header containing this key, and the theory is that if the client can't guess it, it can't fool the SP into bypassing detection. The SP assumes if the header and value is present, the request has already passed the detection step.

Platform Notes

IIS

The (old) ISAPI filter API does not support the creation of server variables, so request headers are used out of necessity as a portable communication channel to applications. As a result, the detection feature should be enabled in all cases. To facilitate this, the ISAPI filter module will automatically generate a random spoofKey value if one is not set for it, and if it can't do so it will refuse to run.

NSAPI

The information described for IIS applies to the NSAPI module as well.

Apache

The Apache modules support request headers for backward compatibility. This should not be enabled.

Under no circumstances should you rely on the request header option other than as a temporary measure while adjusting applications to use the environment option. There are no known scenarios in which environment variables can't be used, including with Java containers, though sometimes extra effort or Apache settings may be needed. Do NOT take shortcuts with this. Do the work and use them.

If for some inexplicable reason you choose not to do this, then you may need to manually add a random spoofKey setting to the configuration yourself to avoid false alarms from the spoof detection feature. Because Apache is a multi-process web server, automatically generating a key to use isn't currently supported. Ideally, we suggest running without it for a while and only adding the setting if you have problems.

FastCGI

The FastCGI mechanism for adding information to the request is somewhat convoluted, but it relies on server variables, so this feature does not apply.