[Koha-bugs] [Bug 17776] Shibboleth Authentication is broken in plack

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17776

Marvin Addison <serac at vt.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |serac at vt.edu

--- Comment #27 from Marvin Addison <serac at vt.edu> ---
CAUTION. The proposed fix for this issue, enabling request headers to convey
Shibboelth attributes, opens a gaping security hole unless other compensating
controls are applied. From
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeAccess:

----------
Unfortunately, not all web servers currently expose a mechanism to create
custom variables from within server extensions. This is a bug; all web servers
should support this in some way, but IIS and Sun/iPlanet do not.

On these platforms, the SP is forced to substitute the use of custom HTTP
request headers. This is convenient, in that the CGI requires custom headers to
be passed along to applications, but is also dangerous and difficult to secure.
The SP has had at least two separate major security patches resulting from this
mechanism. This is because the header mechanism is really about passing
information from the client to the application; any browser can be manipulated
to supply arbitrary headers quite easily with little skill.

To defend against this, the SP has a number of protections designed to clear
out any data supplied by the client that might overlap with the headers it
creates. But this is very difficult to get right in practice, and recent
versions include a much-enhanced NativeSPSpoofChecking mechanism for actually
detecting and blocking requests that carry such headers.

When using headers, the main difference is that instead of using the names
defined via the mapping process, the application must prefix them with "HTTP_",
and in most tools upcase the rest of the name as well. The specifics vary by
tool, and in the case of IIS and ASP.NET are even more bizarre because of
serious flaws in IIS' CGI implementation.

A fair amount of detail on this can be found in the secadv_20090615 topic. The
most particular point about ASP.NET is that it provides access to both the
transformed headers (all caps, with the HTTP_ prefix) via the ServerVariables
collection, and the untransformed input headers via the Headers collection. The
latter is much safer to use.
----------

Thus enabling ShibUseHeaders without any other controls allows clients to spoof
shibboleth attributes, thereby allowing them to completely bypass
authentication and defeat any authorization controls in the worst case.

One adequate compensating control is the header spoof prevention facility
described at
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSpoofChecking.

-- 
You are receiving this mail because:
You are watching all bug changes.