Exposing httpOnly cookies and backend security headers
sammck opened this issue · comments
The httpOnly Set-Cookie option was introduced in 2002 to mitigate certain cross-site scripting attacks. It allows the server to store cookies at the client while at the same time preventing client-side javascript from being able to see the cookie.
whoami exposes the entire client Cookie header to the client, which effectively nullifies the httpOnly option on security cookies when client-side javascript is running in the same domain as the hosted whoami. Any browser javascript in the same domain as whoami can read their httpOnly cookies.
More rarely, whoami sits behind a reverse-proxy or API gateway that adds headers to the request that are sensitive and not intended to be seen by the client.
While it is true that whoami is primarily a development/debugging tool, it is so useful that it is often added to real service stacks. At a minimum there should be clear caveats in the documentation about the potential risks.
Even better, it would be really nice to have configuration options to suppress certain named client headers in the output, or in the case of cookies, to strip certain named cookies from the output.
If there is interest, I could propose a pull request.
Hello,
whoami has been built to be used inside the tests of Traefik, the target was not really to create a tool to use with production stuff or to be used outside of Traefik's context.
Playing with HttpOnly will impact how we can use it because we expected a neutral element and all the header values (ex: to test the Header middleware).
Maybe it can be an option but I am not sure.
I'd be happy enough if the risks were simply called out for anyone thinking of adding it to their stack. To a casual observer, it might appear harmless enough to put anywhere.
One of the main goals of whoami is to display all the information of a request so it feels unexpected to remove information.
It's just a simple "WhoAmI" 😄
We also expect some performances, filtering headers and cookies will impact that.
And this can require a "complex" configuration and this doesn't really fit with our whoami.
After reflection, I think this is not something we want to handle inside whoami.
If you have a suggestion to improve our documentation about this topic, feel free to open a PR.