Redact Dynatrace token in error logs

[arminru]

In the (legacy) Dynatrace exporter v1, if an invalid URL is passed, the exception thrown by the String->URL conversion can contain the API token, since it is specified as part of the URL. Upon error logging, this can lead to the token being written to the logs. This PR adds a method that scrubs the token from the thrown exception before printing it.

Co-authored-by: @pirgeo

[sonatype-lift]

⚠️ 10 God Classes were detected by Lift in this project. Visit the Lift web console for more details.

[jonatan-ivanov]

I need to check what is in the PR but if it is not changing the behavior other than hiding secrets in the logs, I think this could (/should) go to 1.8.x so that earlier versions will be safer too.

[pirgeo]

That is exactly what this PR is about. We split the sending of the request into a few more steps, so we have more control over the Exceptions that are thrown and redact the token in the Errors generated in such cases. I agree that it should go into the previous versions as well, do we need to do anything or are you merging it back into the other branches?

[jonatan-ivanov]

I rebased this against 1.8.x, polished it a bit and merged.
Thank you very much for the contribution.

There is an important thing I would like to call out: this does not fix the issue but hides it in some places but not everywhere. Since the HTTP clients have the freedom of logging out the request url, this change set will not guarantee that it will not be logged out since even if Micrometer won't, the underlying HTTP clients can (HttpURLConnection, okhttp, etc.), you have zero control over it.

Because of this, I would handle this as a critical security vulnerability in the Dynatrace API and add a possibility to send secrets in HTTP headers (there is at least one for this exact purpose). Once this is done, clients (like Micrometer) can migrate from query params to http headers. That would make the purpose of the field clear and it would eliminate issues around logging out the url.

[pirgeo]

Thanks! Since this is about the v1 exporter which should see little to no new users but only existing ones, we did not want to change the sending behavior at this time. Thus, simply redacting the token seemed like the easier solution here. The v2 exporter puts the token into the header, just as you described, and should be used instead