Protecting credentials from untrusted applications with HTTPD
Why?
Sometimes you just want to deploy a tool and protect it from unauthorized access. This is easy if the tool comes with built-in access control. Especially if there’s support for LDAP authentication or SAML. But sometimes, that’s just not the case. In which case you can just Apache HTTPD’s built-in mod_auth to enforce authentication with Basic Authentication. This works really well if the tool is something like a static HTML page, or even a PHP application. It gets a bit trickier if the tool requires running in its own process, like maybe a Java application running in an embedded Jetty instance. In which case you can use mod_proxy and mod_auth together. And hey presto, you’re done, right? Wrong.
Unfortunately, in both of these examples, HTTPD will now be publishing your credentials to the application it’s protecting. I don’t know why this happens, as this seems like a particularly silly default, but that’s nevertheless what happens on CentOS with the latest HTTPD version. Maybe I’m just being paranoid, but as a general rule, I don’t want to send credentials to where they don’t belong. Especially if it’s something like an LDAP login which is used in multiple places within an organization. Especially not if I’m sending it to something like a Wordpress website. Yikes.
Not everyone agrees that this is a problem. Here’s a particularly obtuse example..
How?
Thankfully, the solution ended up being pretty straightforward. Simply add this one line to the Location you’re protecting in your httpd.conf.
RequestHeader unset Authorization
This was one of those cases where finding the solution took a lot longer than implementing it.
— Elric