-
-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Environment variables prefixed with CONTENT_
may overwrite HTTP-Headers provided by the client
#63
Comments
If my understanding of https://tools.ietf.org/html/rfc3875#section-4.1.2 is correct only Edit: |
I agree we should make these changes. Primary issue is... the I'm going to ask the TSC if the change can be done in next minor (2.6.0) as I'd call the current behavior incorrect, or if we absolutely need to do a new major (3.0.0). |
One suggestion by @boesing is to potentially add a feature flag that is toggled via an ENV variable, and have it default to existing behavior when not present. This would allow you to opt-in to the new behavior, while keeping it backwards compatible by default. Next major version would remove the bad behavior of the current version. I'll start work on that shortly. |
Previously, we would check any key starting with `CONTENT_` in the `$_SERVER` array, and treat it as a header. However, per laminas#63, this is incorrect, and we should only look for `CONTENT_TYPE`, `CONTENT_LENGTH`, and `CONTENT_MD5`. To keep backwards compatibility, this patch implements a switch, using the ENV variable LAMINAS_DIACTOROS_STRICT_CONTENT_HEADER_LOOKUP. When this value is found in `$_SERVER` (which aggregates ENV variables as well), the logic for identifying headers in the `$_SERVER` array will become strict. For version 3.0, we will make the strict lookup the default. Signed-off-by: Matthew Weier O'Phinney <matthew@weierophinney.net>
Bug Report
Summary
Environment variables prefixed with
CONTENT_
may overwrite HTTP-Headers provided by the clientCurrent behavior
This may be entirely expected behavior but I have not found a spec or warning in the documentation.
It's a least surprising to find unrelated environment variables as request header and potentially a security problem when comparing the env-variable against the header during authentication.
Environment variables prefixed with
CONTENT_
will be populated as http-headers:I stumbled about this behavior in a project with the following
.env
-file:The
.env
file is loaded into the $_SERVER superglobal viaDotenv\Dotenv::createImmutable()
.The request object is created via
\Laminas\Diactoros\ServerRequestFactory::fromGlobals
.The request object now contains
content-api-password
as request-header$request->getHeader('content-api-password')
.Environment variables prefixed with
CONTENT_
max overwrite client provided HTTP-Headers:If the same header name is provided by an http-client the
$_SERVER
superglobal contains aHTTP_CONTENT_API_PASSWORD
key.In the current implementation the order is relevant. Whatever key is defined later in
$_SERVER
will be used to populate the HTTP-Header.How to reproduce
Expected behavior
The text was updated successfully, but these errors were encountered: