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

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

Open
ksaadDE opened this issue Sep 16, 2023 · 0 comments
Open

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

ksaadDE opened this issue Sep 16, 2023 · 0 comments

Comments

@ksaadDE
Copy link

ksaadDE commented Sep 16, 2023

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

fetch('./package.json')

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.

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

1 participant