You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 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:
Load in the browser
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.
The text was updated successfully, but these errors were encountered:
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
andpackage-lock.json
. That means both files are basically public.The load is due to
noVNC/app/ui.js
Line 93 in 68135be
The
package.json
contains the version number of the kasmvnc webclient and it's other components. Therefore it is a basicpackage.json
andpackage-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:
Expected behavior
By default the
package.json
orpackage-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.
The text was updated successfully, but these errors were encountered: