Information leak in OAuth2 plugin

[Dibble]

Summary

Information about the underlying technology (Kong) is leaked when a bad request is made to the OAuth2 plugin.

Incorrect POST requests to the /oauth2/authorize endpoint return this error message:

HTTP/1.1 400 Bad Request
Date: Mon, 12 Sep 2016 13:44:10 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
pragma: no-cache
cache-control: no-store

{"error_description":"Invalid Kong provision_key","error":"invalid_provision_key"}

Steps To Reproduce

1. create an API with the oauth2 plugin enabled
2. make an invalid POST to /oauth2/authorize curl -i -X POST https://<kong>/<api>/oauth2/authorize

Additional Details & Logs

• Kong version ($ kong version): 0.8.3 (and 0.9.1)
• Kong debug-level startup logs ($ kong start --vv): N/A
• Kong error logs (<KONG_PREFIX>/logs/error.log): N/A
• Kong configuration (registered APIs/Plugins & configuration file): Any API with OAuth2 plugin
• Operating System: N/A

[subnetmarco]

@Dibble what message would you suggest returning?

[Dibble]

@thefosk I think the easiest change would be to simply remove Kong from the response.

However given that this endpoint is only designed to be accessed by a third-party backend, rather than any clients, I think it might make more sense to return a 401 or a 403 if the provision_key is incorrect or missing.

Even better might be enabling IP whitelisting for that endpoint, returning 404s for blocked requests.

[subnetmarco]

@Dibble the PR above ^ removes "Kong" from the error message.

[thibaultcha]

Wouldn't a simple googling of the error message lead to this repository anyways?

Also, isn't the Server header set (Server: kong/x.x.x.) in those responses anyways too?

[markyjones]

As you say, anyone could Google the msg and end up here, this is largely aimed at not showing up in opportunistic/automatic scans. This change isn't going to be much help in a focused/manual probe but it has some merit.

We have also stripped the 'kong/x.x.x' headers too and would suggest it as a configurable option as a feature.

We have both internal and professional penetration tests carried out periodically which would fail us with an explicit technology name like this leaking out.

My main preference for this specific endpoint is to send back a fairly unhelpful 401 given it should never be invoked legitimately by anything other than the owner of the gateways identiy provider; however, that would be more invasive API change.

[thibaultcha]

That's fine with me. I just merged #1633 and we'll include it in the upcoming 0.9.2 patch release. Even tho it changes some behavior I believe this should be fine. Thanks!

[thibaultcha]

(BTW, configuring the Server and Via headers to be something else/stripped is in our plans, see #1009. I believe this should be a per-API setting, someday.)