Config to allow 'https forward'

[acinader]

I ran into "Insecure use of middleware over HTTP denied by configuration." when I deployed and found this discussion of the issue in #12

I have worked around the problem by setting "secure" => "false".

However, I think that a better solution would be to allow HttpBasicAuthentication to be configured to permit forwarded https requests.

The use case is where a load balancer or cdn is terminating https requests which are then forwarded over http to slim.

An example implementation can be found here: https://github.com/oscarotero/psr7-middlewares/blob/master/src/Middleware/Https.php#L110

By implementing, testing and documenting this configuration capability, slim-basic-auth would help the end user to securely and quickly set up basic authentication in what I assume is a common deployment scenario.

[tuupola]

Technically there is no difference whether the unsafe operation is allowed via configuration or allowing it automatically by looking at headers. It is still unsafe because the unencrypted traffic between the load balancer (Cloudflare etc) and your webserver can be monitored. It is easy to pick up the passwords from there.

I rather have users who know what they are doing manually enable the unsecure operation. This way there are no hidden surprises.

[acinader]

In my case, I know that I want to allow for forwarded https but I'd love to be protected against an inadvertent actual http request vs. a 'valid' forwarded request. I lose that safeguard if I simply set secure to false.

In my case, the https is terminated at a load balancer. The various networks connected to the load balancer are not publicly addressable and are configured to prevent snooping. I believe that this is a pretty common ops setup which is why allowing for the level of granularity to configure for it would allow users of the library to do so without losing the safeguard of recognizing and erroring on a public http request.

Another typical case where this feature would be beneficial would be for container deployments where php code is contained in one container and a nginx or apache container is used for ssl termination.

I'm assuming that the general usefulness is why it ended up the middleware\https package I linked.

Thanks for the consideration.

[tuupola]

Hmmh, I see your point. Trusting X-Forwarded-Proto: header should probably be a config flag though, and not enable by default. I will think about this a bit.

[tuupola]

Playing with the idea, one could enable trusting the headers by adding a new option to relaxed setting. This way no need to add new config options.

$app->add(new Tuupola\Middleware\HttpBasicAuthentication([
    "path" => "/admin",
    "secure" => true,
    "relaxed" => ["localhost", "headers"],
    "users" => [
        "root" => "t00r",
        "somebody" => "passw0rd"
    ]
]));

Other option is to introduce new setting which is more implicit.

$app->add(new Tuupola\Middleware\HttpBasicAuthentication([
    "path" => "/admin",
    "secure" => true,
    "trust_headers" => true,
    "relaxed" => ["localhost"],
    "users" => [
        "root" => "t00r",
        "somebody" => "passw0rd"
    ]
]));

[tuupola]

Thanks, looks good! I am pondering between the relaxed and trust_headers at the moment. Will need to think about it for a while and let you know.

[acinader]

I'm going to take another pass at the documentation today.

[acinader]

k. I re-organized the Security section of the README rather than just gloming on more instructions.

[manzowa]

Is it possible to use Tuupola\Middleware\HttpBasicAuthentication in private mode? I ask you that because I use it locally HTTP works but when I go online with HTTPS it doesn't work anymore.