Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cleanup the http header matching the jwt2header pattern #5

Open
epourail opened this issue Jan 18, 2021 · 3 comments
Open

cleanup the http header matching the jwt2header pattern #5

epourail opened this issue Jan 18, 2021 · 3 comments

Comments

@epourail
Copy link

epourail commented Jan 18, 2021

This improvement should fix the following issue:

Context:
In case my upstream performs operations on a custom HTTP header "x-kong-jwt-claim-dummy" (in theory, extracted from the bearer)

Scenario

  1. In the input request, I add a custom header "x-kong-jwt-claim-dummy" (matching the jwt2header pattern)
  2. In the input request, the bearer token used does not have the claim "dummy"

Result
The upstream will receive the "x-kong-jwt-claim-dummy" header and trigger the operations

Expected Result
The upstream should not receive the header

Solution
To improve the security, you should cleanup the HTTP headers of the input request matching the pattern "x-kong-jwt-claim"

@nikirago
Copy link
Contributor

Hi @epourail ! There is an option to strip_claims so that the headers are not sent to the upstream. By default it is set to false. Set to true and this should do what you want. Please confirm.

@epourail
Copy link
Author

I don't want to strip the claim once extracted.
I want to be sure the HTTP header comes from extracted claim (via the jwt2header plugin) and it is not a custom header set by the client.

@nikirago
Copy link
Contributor

Understood. Will update to strip any incoming x-kong-jwt-claim headers that are sent from consuming entity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants