Improve query sanitization to prevent a password leak in the logs

[jsternberg]

Sanitizing is now done through pattern matching rather than parsing the
query and replacing the password in the query. This prevents
accidentally redacting the wrong part of a query and revealing what the
password is through association.

Fixes #3883.

[mark-rushakoff]

Seems a little strange to compile the regexp on every call to Sanitize. Any reason for not pulling it up to a package-level, unexported var?

[jsternberg]

It should be. Let me move it. This was just easier while I was writing the code.

[gunnaraasen]

I like the regex approach, but will running two regexes against every query add significant overhead?

[gunnaraasen]

Since query.Statements is no longer used, I think sanitize can be called in the response logger.

https://github.com/influxdata/influxdb/blob/master/services/httpd/response_logger.go#L94

[jsternberg]

I don't think we want to run the sanitizer for non-query requests. The response logger doesn't seem to be limited to just serveQuery.

[gunnaraasen]

The response logger feels like a more natural fit for this code than the query handler. Other requests won't have a q query parameter but it could also be skipped with an if r.URL.EscapedPath() == "/query" check.

[jsternberg]

I'm not sure. The golang regex library is based off of re2 rather than perl regular expressions so it's generally much more efficient.

The advantage of this approach is that the query doesn't have to parse correctly. I made mistakes while testing and did this:

CREATE USER "admin" WITH PASSWORD "admin"

This wouldn't get redacted because it resulted in a parse error and the password just got printed to the log.

[jsternberg]

Added a benchmark of the Sanitize function.

PASS
BenchmarkSanitize-8       200000             11789 ns/op            1360 B/op         11 allocs/op

[gunnaraasen]

I like the regex approach and that it covers mistyped queries. Just wanted to mention the potential performance impact since the regexes are run on every query and the number of queries containing a password is very small.

I ran some quick tests of 10,000 SELECT queries on an empty database using influx_stress and there was no noticeable difference in response times.

[jsternberg]

I tried a simple test using influx_stress and got this:

# Before this change
Total Requests: 2000
        Success: 2000
        Fail: 0
Average Response Time: 76.85802ms
Points Per Second: 437187

Total Queries: 250
Average Query Response Time: 23.803755ms

# With this change
Total Requests: 2000
        Success: 2000
        Fail: 0
Average Response Time: 80.204933ms
Points Per Second: 427885

Total Queries: 250
Average Query Response Time: 26.553812ms

It seems like the average query response time gets slowed down by about 3ms. @jwilder thoughts?

[jwilder]

LGTM 👍

[e-dard]

Go's regex package is very slow, is increasing the mean query latency by 12% acceptable?

[jwilder]

@e-dard I notice that much variation w/ influx_stress stats it reports all the time... even without changes to the code.

[jsternberg]

I'll merge this then and we'll update sanitize if it turns out to be bad for performance.