Only exposing necessary information #2671
Replies: 2 comments 4 replies
-
The response header's currently used as a check to ensure the client isn't doing weird things against the wrong version, and yes both that and the swagger docs could be used to infer the version... ... but so could hashing the WASM returned for the UI and a variety of other things? 🤔 |
Beta Was this translation helpful? Give feedback.
-
I'm going to challenge this notion. Similar to Kerckhoffs principle, knowledge of a system should not weaken the system. Knowing the version of Kanidm does not improve the situation for an attacker. Inversely, even if they didn't know the version, there are still ways to fingerprint the version based on feature availability. And finally, you don't need to know the version to attempt exploits (if they existed) against the server. As a result, the version does not change anything for an attacker IMO. |
Beta Was this translation helpful? Give feedback.
-
I'd argue it would make sense to, by default, not expose the running kani version (currently sent as response header). I don't see how this helps anyone (but developers or someone actively debugging) and in that case it should be something you deliberately activate. You might just as well execute
kanidmd version
in the running container. If you want to monitor what version was running at a certain point in time, I think this should be part of your (internal) metrics endpoint.Actually it's the same question about the swagger endpoint being active by default, however, that seems less critical. Curious to hear your opinions about it.
Basic principle is that you only expose as much information as necessary to not make it easier for attackers (especially automated information gathering).
Beta Was this translation helpful? Give feedback.
All reactions