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

Store two URLs on monitor (one public, one internal) #4254

Closed
1 task done
sevmonster opened this issue Dec 19, 2023 · 2 comments
Closed
1 task done

Store two URLs on monitor (one public, one internal) #4254

sevmonster opened this issue Dec 19, 2023 · 2 comments
Labels
area:status-page Everything related to the status page feature-request Request for new features to be added

Comments

@sevmonster
Copy link

sevmonster commented Dec 19, 2023

⚠️ Please verify that this feature request has NOT been suggested before.

  • I checked and didn't find similar feature request

🏷️ Feature Request Type

UI Feature, Other

🔖 Feature description

On HTTP, push, and any other monitor with a URL field—or on monitors that have previously had a URL field set and have had their type changed, so that the url field is set in the database—that URL (which may be internal) is used in a number of places, including status pages, Discord alerts, and as the action for Ntfy notifications.

In the case of status pages, you can elect to show or hide the URL. But for notifications and Discord, you cannot hide the URL; it will always be shown to the end user. There may be other places this can happen other than what I have listed.

The problem is that unless you protect your notification/integration endpoints so that only authorized users may utilize them, this can expose internal-only URLs to external users. And I imagine it would be common to use special URLs for Uptime Kuma, that bypass WAFs, authentication, or otherwise, so that they do not get in the way of monitoring the service.

If there is not a proxy sitting in front of the URL given to Uptime Kuma that can protect against external users accessing it, and if there is no network firewall that blocks sources other than Uptime Kuma and the frontend web proxy, then anyone could grab these URLs and access the underlying service, potentially without the usual protections for the public URL.

✔️ Solution

Add a public-facing URL field in addition to the existing internal URL field. This field could also point to documentation for monitors that don't have a web interface. In all cases where the internal URL field is used, the public one is shown instead. Database migrations for this change could copy over the internal URL to a new public URL column for forward-compatibility.

❓ Alternatives

Always make sure any URLs you put into Uptime Kuma are protected by a reverse proxy with basic auth/bearer tokens enabled.

📝 Additional Context

I am not sure how this is separate to #3991. It seems to me that we are talking about the same things, just in different ways.

#1793 is also relevant: It shows that a lot of potentially sensitive information is leaked out of Uptime Kuma, to anyone that is given access to notifications or potentially the status pages. This makes it difficult to use/recommend Uptime Kuma for public-facing service.

@sevmonster sevmonster added the feature-request Request for new features to be added label Dec 19, 2023
@CommanderStorm
Copy link
Collaborator

CommanderStorm commented Dec 19, 2023

I am not sure how this is separate to #3991

Currently the push url is bound to the primary base url of the instance. Said issue asks if it is possible to change this for push monitors.

Related #927

Closing as a duplicate of #2507

@CommanderStorm CommanderStorm closed this as not planned Won't fix, can't repro, duplicate, stale Dec 19, 2023
@CommanderStorm
Copy link
Collaborator

This makes it difficult to use/recommend Uptime Kuma for public-facing service.

Here is our contribution guide: https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md

@CommanderStorm CommanderStorm added the area:status-page Everything related to the status page label Apr 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:status-page Everything related to the status page feature-request Request for new features to be added
Projects
None yet
Development

No branches or pull requests

2 participants