Security data leak to logs #665
Description
Describe the bug
OAuthLib leaks users' passwords etc. to logs in case of errors.
We have e.g. an "authorize" route, that takes "username" + "password" in JSON body. However, if there's errors in parsing the request or validating some information, their username + password get leaked into the error logs.
OAuthLib should not make ANY assumptions about my request structure and it should NEVER leak the complete request body as part of an exception message or otherwise.
Example of leak when using a bottle application with bottle-oauthlib, exception generated by oauthlib contains request body and so the username and password when an error is caused by redirect URI mismatch.
172.17.0.9 - - [05/Apr/2019 08:16:03] "POST /authorize?response_type=code&client_id=2fcc9e52-b29e-412c-ad5b-a74734a35fc7&redirect_uri=http%3A%2F%2Fworld.local%3A32000%2Fapi%2FexchangeToken_&grant_type=authorization_code&state=123qwerasdf HTTP/1.0" 500 62
Traceback (most recent call last):
File "/.venv/auth-ALEBwC_u/lib/python3.6/site-packages/bottle.py", line 862, in _handle
return route.call(**args)
File "/.venv/auth-ALEBwC_u/lib/python3.6/site-packages/bottle.py", line 1740, in wrapper
rv = callback(*a, **ka)
File "/.venv/auth-ALEBwC_u/lib/python3.6/site-packages/webargs/core.py", line 450, in wrapper
return func(*new_args, **kwargs)
File "/.venv/auth-ALEBwC_u/lib/python3.6/site-packages/bottle_oauthlib/oauth2.py", line 237, in wrapper
raise e
File "/.venv/auth-ALEBwC_u/lib/python3.6/site-packages/bottle_oauthlib/oauth2.py", line 230, in wrapper
uri, http_method=http_method, body=body, headers=headers, scopes=scope
File "/.venv/auth-ALEBwC_u/lib/python3.6/site-packages/oauthlib/oauth2/rfc6749/endpoints/base.py", line 64, in wrapper
return f(endpoint, uri, *args, **kwargs)
File "/.venv/auth-ALEBwC_u/lib/python3.6/site-packages/oauthlib/oauth2/rfc6749/endpoints/authorization.py", line 104, in create_authorization_response
request, self.default_token_type)
File "/.venv/auth-ALEBwC_u/lib/python3.6/site-packages/oauthlib/oauth2/rfc6749/grant_types/openid_connect.py", line 73, in create_authorization_response
return self._handler_for_request(request).create_authorization_response(request, token_handler)
File "/.venv/auth-ALEBwC_u/lib/python3.6/site-packages/oauthlib/oauth2/rfc6749/grant_types/authorization_code.py", line 190, in create_authorization_response
self.validate_authorization_request(request)
File "/.venv/auth-ALEBwC_u/lib/python3.6/site-packages/oauthlib/oauth2/rfc6749/grant_types/authorization_code.py", line 307, in validate_authorization_request
raise errors.MismatchingRedirectURIError(request=request)
oauthlib.oauth2.rfc6749.errors.MismatchingRedirectURIError: (invalid_request) Mismatching redirect URI. <oauthlib.Request url="http://192.168.99.100:31000/authorize?response_type=code&client_id=2fcc9e52-b29e-412c-ad5b-a74734a35fc7&redirect_uri=http%3A%2F%2Fworld.local%3A32000%2Fapi%2FexchangeToken_&grant_type=authorization_code&state=123qwerasdf", http_method="POST", headers="{'Content-Length': '42', 'Content-Type': 'application/x-www-form-urlencoded', 'Host': '192.168.99.100:31000', 'User-Agent': 'insomnia/6.3.2', 'Accept': 'application/json', 'X-Forwarded-For': '172.17.0.1', 'Connection': 'close'}", body="{'email': 'username@domain.com', 'password': 'Password1'}">
How to reproduce
Cause any OAuth2Error in OAuthLib while it has access to your request object e.g. via bottle-oauthlib. As an example, have your validator for return_url return False.
Expected behavior
Complete request will NEVER get logged by oauthlib even after poor attempts to guess what names of fields should be "sanitized" and guessing the request body format.
Additional context
The bug is caused by:
- https://github.com/oauthlib/oauthlib/blob/v2.1.0/oauthlib/oauth2/rfc6749/errors.py#L46-L47
- https://github.com/oauthlib/oauthlib/blob/master/oauthlib/common.py#L437-L445
We encountered it in OAuth2, but considering the issue comes from common.py it likely affects other uses as well.
Writing server code, using bottle-oauthlib, but it seems to be irrelevant since it's oauthlib doing the leak.