Secure certain endpoints with http basic auth or token

[christaikobo]

Is your feature request related to a problem? Please describe.
Yes, I am concerned about certain open endpoins like /image /version
They are not secured in any way.
I think for unauthenticated party there is no reason for them to be able to access these anyway.

Describe the solution you'd like
I wish they are secured using either token (preferred) or basic auth at least.

Describe alternatives you've considered
I can do MTLS, but that is site wide configuration, and I have other apps under other subpaths that I don't wish to enforce MTLS for.

[eternal-flame-AD]

Thank you for raising these considerations and here are my thoughts:

Regarding the image endpoint

• they have more than 100 bits of cryptographic level randomness, so I would argue they are not bruteforce-able over the network.
• I think the image capability of Gotify is pretty limited and pretty much the only thing stored there are icons of applications, I am not entirely sure why would they require confidentiality (or if it somehow does, just don't use an icon?).
• All images you upload on GitHub are public URLs too even if people without the authentication context to reach that image can just read it through the URL, and in my opinion it is not a security weakness in itself.
• not requiring auth on image makes it much easier to migrate to a separate storage backend in the future and keeps our options open.

That said, I sense maybe your concern is regarding the potential of leakage of URLs through server logs or intermediate proxies, if that was the concern, they can be turned off within your own machine. However, if you use an intermediate proxy not entirely in your control nothing is secure against their logging regardless of protections we can possibly implement, including your authentication. If you use observability products like OpenTelemetry they usually have flexible URL redaction options.

Regarding the version endpoint:

You can build your own gotify that reports UNKNOWN by patching out the Makefile or if you would like to a more granular control, do a proper authentication check.

I think it provides limited security benefit, since there are only one release every couple of months or so, even if you hide the version one can still just enumerate by probing for behavioral changes made between releases.

Future Step

Could you clarify the level of security you would want (for example an attack model/vector you would want to protect against so I understand more clearly what we could do)?

Additionally I can tag an RFC here to request other users to join in the discussion, just let me know if you would like me to do that.

[christaikobo]

My threat model is fairly generic, I am just selfhosting some apps including gotify and worries about generic threat like a vulnerability scanning bot. Nothing targeted or sophisticated.

1. For the version endpoint

Suppose there is a vulnerability that is patched by 2.0.0 version of gotify, it is possible that the bot can just simply scan version and try to exploit it once it is discovered that the server is running anything lower than 2.0.0.

One could argue that you should keep all your apps updated, but that is not the case for most people, even most software projects don't update all their dependency every time, right? A bot usually makes minimal effort so nobody is sitting there looking for behavioral changes. If it can't find something easy to exploit, it just moves on.

2. For the image endpoint

I was under the impression that gotify could send image as attachment of a message, and images sent would be hosted under that path. I have yet to test it myself, but I did find that the channel icon is definitely hosted there and that is how I discovered the endpoint not being secured.

I'd argue even the current state of the functionality is limited, it is possible that through future development it gets expanded.

Regarding the crypto randomness, I guess you are referring to the name of these image files? It just feels like securing resources using a long and random https URL path. I don't know much about crypto but I think there must be a reason that it's not a primary way to secure things. But I'm noob on this topic so forgive me if I'm wrong.

As for the github analogy, I honestly don't like the fact that people without the authentication context to reach that image can just read it through the URL, and I think if the fact is laid out for most people, they'd be unhappy about it too.

Of course keeping the storage option open for the future is reasonable and understandable.

If I have to sum it up, it is that I (maybe most people using gotify) am using it simply for myself and at most my close family. I don't intend to let any of it be public. But at the end of the day, you guys know these much much better than I do. I'm just trying to raise some concerns that I see through my amateur eyes. I respect you guys and the decision you make.

[eternal-flame-AD]

images

Random URLs are usually the defacto solution for supportive images (logos, attachments for support tickets, etc) AFAIK, and I did commercial security audits in the past our standards are unless they are predictable or low entropy they don't constitute a weakness unless insider threat or industry compliance is a concern (which I don't think it is here). If it were the most we would do as just an open source offering is sign the URL so it only works on the specific Auth header, but I think it is a little extreme for our use case.

versioning

Hiding version (which is a form of security through obscurity) is only useful in a narrow set of exploits that are known (not 0-day) AND does not require any form of prior knowledge or authentication AND require non trivial effort/complexity to exploit.

I know one probable vulnerability we had way way back (at least 5 years) that fits this criteria, it was before I joined and I think it is a one off situation and unlikely to happen again. And a side note about upgrading as you mentioned: I think for open source products we don't have a method nor responsibility to make effort in ensuring our clients upgrade more than RSS/notification (which GH releases already have). I think it is almost always futile, my personal take on this is acknowledge they exist but prioritize security for users on recent releases and only slow down for old deployments if it doesn't increase exposure for diligent deployments. Additionally even if you don't normally update, in the past couple of years there has been many advancements in the open source community in vulnerability reporting and mitigation methodology. If an issue like that happens today there will be a CVE published, and you can just search for any CVE alerting solutions to cover projects that align to industry disclosure guidelines.

Authentications are not much different from other things, a token is exactly the same regardless of where you put them (including in the URL), the primary tradeoff between using the Authorization/Cookie header and URL itself is simply standardization (most legitimate proxy servers and observability products redact these out of the box) and flexibility.

In general I think the most effective way to protect you from vulnerabilities from private use applications is a VPN (WireGuard, TailScale, Cloudflare Warp, etc). It is the defacto standard for almost all commercial setup too for sharing services between offside affiliates. There is no way anybody could guarantee they don't have vulnerabilities and without investing in custom audits the best way to protect against 0-days is reduced attack surface.

[christaikobo]

Thanks for the elaborated write up.

"a token is exactly the same regardless of where you put them (including in the URL)" makes perfect sense. I'm happy to know that my concerns are already addressed. Now I feel bad about raising some invalid questions. Sorry but I'm unfamiliar with some of these industry standard as I'm not part of it. (Just a hobbyists)

Your explanation is quite informational and made me rethink some of my setup and practices.

Thank you!