Low-risk Security issue, leaked package-lock.json package.json

[ksaadDE]

Describe the bug (or vulnerability) First of all I'm not sure if the package.json is really needed by the client.

If you use e.g. a yet unmentioned container application, which uses KasmVNC and KasmVNC webclient, and press F12 to open the browser console and click on network traffic, there is a load of the package.json and package-lock.json. That means both files are basically public.

The load is due to https://github.com/kasmtech/noVNC/blob/68135beedd40c2654f2d41bba821165ddf0d09d7/app/ui.js#L93

The package.json contains the version number of the kasmvnc webclient and it's other components. Therefore it is a basic package.json and package-lock.json"leak". It allows attackers more easily to enumerate (gathering information) the components versions.

Yes, hiding version numbers is "security" through obscurity. Though it reduces the likely-hood of a successful penetration by skids. There is a strong point for restricting access to those files, if they are not actually needed by another component.

To Reproduce Steps to reproduce the behavior:

1. Load in the browser
2. Investigate through Network Inspection, filter for main.bundle.js or ui.js

Expected behavior By default the package.json or package-lock.json should be restricted and not publicly accessible.

There should be the possibility to put that request behind a API or to entirely disable / restrict that access by default. Though it could be also restricted via reverse proxy, like in nginx or a web firewall, if kasmvnc webclient does not really need it, which I did not further investigate.

It should be also added to the configuration hints and details, so people are warned in case of any implementation of your work, that they should restrict the access to these files / routes via reverse proxy or web server configuration.

Screenshots

Client (please complete the following information): latest

Server (please complete the following information): latest

Additional context Further I would like to mention it was not possible in a appropriate time manner to find a responsible disclosure E-Mail address or any other form to secretly report vulnerabilities. This should be improved.