Mitigate client vulnerabilities by storing in Kong the plain password of api upstream server

Questions
1

If the client is compromised, the attacker doesn’t have the full plain api password from upstream server and he could run only the set of commands allowed via Kong, under rate limiting.

Of course, there should be further ip restrictions ( the upstream server to receive api requests only via kong, not directly from client or attacker server. Kong should receive commands only from client ip). Also authentication plugin should be applied to the route above ( to avoid requests to kong, with dummy passwords, from unauthorized sources).

Proof of concept:

curl -X POST http://localhost:8001/routes/RouteID/plugins \
--data "name=request-transformer" \
--data "config.append.querystring=password:PlainUpstreamPassword"

curl --silent --insecure --data "username=root@pam&password=dummy"  \
http://kong:8000/api2/json/access/ticket \
| jq --raw-output '.data.ticket' | sed 's/^/PVEAuthCookie=/' > cookie

My initial use case is client: whmcs, proxy api gateway: kong, upstream server: proxmox. See further details https://forum.proxmox.com/threads/securing-third-party-application-proxmox-integration-with-proxy-api-gateway.47091/

Are you aware of similar forum posts or use cases? Thx!

2

Right, this is certainly one way to do it. I do something similar when calling old vendor APIs that need a key in the header, just use the request transformation plugin to drop that special header in and poof, Kong handles the crappy key auth as a header and I let clients connect securely with a better pattern like OAuth or JWT.

1 Like