0

I have a legacy CGI application which I've convinced to run under plack (specifically, it runs in starman, but I don't think that's relevant to the question). The kinks around persistent vs. disposable request-handling processes have been worked out, but one significant issue remains: The application uses shibboleth for authentication.

For those unfamiliar, shibboleth runs as an apache module (mod_shib) which, in turn, communicates with an external daemon (shibd). After the user has danced the authentication dance with the shibboleth identity provider, mod_shib passes the authentication details to the back-end application using one of two methods: environment variables or HTTP headers.

With CGI, this is simple and straightforward, because apache can set whatever environment variables it wants when it fires up a child process to run the CGI code in.

Since we've now moved to a persistent out-of-process server, that doesn't work so easily and I've needed to set it up to use HTTP headers instead, which opens up the possibility that a malicious user could bypass shibboleth authentication by spoofing the relevant headers. mod_shib includes some automatic anti-spoofing techniques to mitigate this risk, but those can't be expected to be 100% effective in all circumstances, so I went to the shibboleth documentation to see what I can do to further harden my installation against such attacks.

At https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSpoofChecking I found the assertion that, with an apache server,

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.

However, I'm fairly certain that it is not possible for one process (apache) to modify the environment of another running process (the plack application), particularly when the target process is not a child and is running under a different uid/gid. The only way I could see that being even a remote possibility would be if apache were running as root, which would create its own set of (IMO, more serious) security issues.

Is there a way to configure apache/mod_shib such that it is able to pass shibboleth authentication results to an out-of-process application server without using HTTP headers to do so? Or is the shibboleth documentation incorrect in its assertion that "There are no known scenarios in which environment variables can't be used"?

If using HTTP headers is the only option with an out-of-process server, are there any best practices for securing such a deployment against header spoofing attacks?

migrated from superuser.com Aug 29 '18 at 13:50

This question came from our site for computer enthusiasts and power users.

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.