Skip to content
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

Prevent 'p' parameter of OPTIONS requests being logged. #3686

Merged
merged 4 commits into from
Aug 19, 2015

Conversation

jonseymour
Copy link
Contributor

Previously, OPTIONS requests were logged without passwords being redacted.

This occurred because password redaction is performed by the authentication
handler and a) the serveOptions handler did not have the parameter
that forces the authentication handler to be put on the request path and b)
the CORS handler returns early for OPTIONS requests
before the authentication handler is invoked.

With this commit, OPTIONS requests are also subject to the authentication handler
and the responsibility for the early return on OPTIONS request is moved from
the CORS handler to the authentication handler.

Signed-off-by: Jon Seymour jon@wildducktheories.com

@jonseymour
Copy link
Contributor Author

[X] CHANGELOG.md updated
[X] Rebased/mergable
[X] Tests pass *
[X] Sign CLA (if not already signed)

AFAICT the tests do pass. I did see what looked to be spurious failures of the circle-ci tests initiated by the PR, but these failures appeared unrelated to my changes and appear to have been fixed subsequently by mechanisms unknown.

@otoolep
Copy link
Contributor

otoolep commented Aug 17, 2015

@gunnaraasen

@gunnaraasen
Copy link
Member

The big downside of this approach is that OPTIONS requests will be authenticated. Anyone using Basic Auth will receive an "unauthorized" response unless the Access-Control-Allow-Credentials response header is set, which seems unsafe.

@jonseymour I think it would make sense to keep the OPTIONS check in the CORS handler and sanitize the p parameter in serveOptions. E.g.

func (h *Handler) serveOptions(w http.ResponseWriter, r *http.Request) {
    q := r.URL.Query()
    if p := q.Get("p"); p != "" {
        q.Set("p", "[REDACTED]")
        r.URL.RawQuery = q.Encode()
    }
    w.WriteHeader(http.StatusNoContent)
}

@jonseymour
Copy link
Contributor Author

@gunnaraasen If I keep the OPTIONS check in the CORS handler, the serveOptions method won't get invoked (because of the early return) and hence redaction won't occur.

Would it make more sense to move the redaction logic into the logging handler so that redaction is independent of whether authentication is enabled or not and also which path the request took to get to the logging path?

Previously password redaction only occurred inside the
authentication handler and the authentication handler is not on
the request path for OPTIONS requests and, in any case, would
not be invoked because of an early return on OPTIONS
requests by the CORS handler.

Now, we change the response logger to explictly replace any
occurrence of the 'p' parameter from the query string with
'[REDACTED]' prior to logging the response.

Signed-off-by: Jon Seymour <jon@wildducktheories.com>
@gunnaraasen
Copy link
Member

Thanks @jonseymour. I agree, moving the redaction code to the logger is a better approach.

Can you also remove the old sanitizing code in parseCredentials now that it's redundant?

We now redact the credentials in the logger, so the function implemented
by the deleted lines now seems redudndant.

Signed-off-by: Jon Seymour <jon@wildducktheories.com>
Signed-off-by: Jon Seymour <jon@wildducktheories.com>
@jonseymour
Copy link
Contributor Author

@gunnaraasen Sure. See 1d5ff55.

@gunnaraasen
Copy link
Member

+1

@otoolep @toddboom this needs another plus one.

@toddboom
Copy link
Contributor

👍

gunnaraasen added a commit that referenced this pull request Aug 19, 2015
Prevent 'p' parameter of OPTIONS requests being logged.
@gunnaraasen gunnaraasen merged commit 409fe0a into influxdata:master Aug 19, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants