1

My logging is set up to log $request_body out to syslog, but it's including sensitive data in the logs.

For example, the password is coming through on the logs as \x22password\x22 when the user logs in. For the time being, I want to persist the surrounding data and obfuscate the password only.

For example, when a user logs in and POSTs to the authentication backend, it's logged as

body: "{\x22username\x22:\x22myname@mydomain.com\x22,\x22password\x22:\x22One2Three4!?\x22}"

but I want it to be logged instead as 

body: "{\x22username\x22:\x22myname@mydomain.com\x22,\x22password\x22:\x22********\x22}"

I've seen there's an ability to map out fields in typical query string parameter formatting, but I'm not particularly skilled at regex.

I've looked here NGINX: Obfuscate password in access_log but the question isn't answered. Hoping to get some regex guidance on this one, regardless of best practices and security concerns.

How can I obfuscate the password in the logging with this format of response body?

Jon Mitten
  • 1,965
  • 4
  • 25
  • 53

1 Answers1

2

Lets try some debugging first. Here are the regex that should work, but I'm not sure how it will behave if the password contains \x22} or \x22, substrings. Can you test it?

map $request_body $obfuscated_request_body {
    "~(.*[{,]\\x22password\\x22:\\x22).*?(\\x22[,}].*)" $1********$2;
    default $request_body;
}

Replace $request_body with $obfuscated_request_body in your log_format directive parameters. Note that the map block should be placed outside the server block.

Update 1

It seems that \x22 substring will be shown as \x5C\x5Cx22 in the log file, so regexp must be workable in any conditions.

Ivan Shatsky
  • 13,267
  • 2
  • 21
  • 37
  • With this map block in my appname.conf, I get the following errors: `2020/02/03 01:07:03 [emerg] 1#1: unexpected "{" in /etc/nginx/conf.d/appname.conf:5 nginx: [emerg] unexpected "{" in /etc/nginx/conf.d/appname.conf:5 `So I try to wrap the block in double quotes, but then I get: `2020/02/03 01:24:03 [emerg] 1#1: invalid number of the map parameters in /etc/nginx/conf.d/appname.conf:6 nginx: [emerg] invalid number of the map parameters in /etc/nginx/conf.d/appname.conf:6` – Jon Mitten Feb 03 '20 at 01:36
  • 1
    @JonMitten Curly backets inside regex body are cause of this error, I'm updated my answer, try this one. – Ivan Shatsky Feb 03 '20 at 02:21
  • That worked great. Tested with curly braces as part of the password, and that gets obfuscated as well. – Jon Mitten Feb 03 '20 at 19:34
  • 1
    Can you test it with password that contains `\x22}` substring and with password that contains `\x22,` substring? – Ivan Shatsky Feb 03 '20 at 19:35
  • I've tested with `StupidPassword\x22` and I do indeed get `body: "{\x22username\x22:\x22myname@mydomain.com\x22,\x22password\x22:\x22********\x22}", upstream_status: "200"`. This looks good! – Jon Mitten Feb 03 '20 at 20:57
  • That is not exactly what I mean. Two passwords I want to be tested, for example, are `Stupid\x22}Password` and `Stupid\x22,Password`. – Ivan Shatsky Feb 03 '20 at 21:02
  • `Stupid\x22}Password` passes, is properly logged out as `********`. `Stupid\x22,Password` passes as well, and is properly logged as `********`. Thanks for following up with those test criteria. – Jon Mitten Feb 03 '20 at 21:23