Version Info on GUI #1762
Labels
No Label
dependencies
duplicate
help wanted
invalid
kind/bug
kind/feature
needs reproduction
question
security
wontfix
No Milestone
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/vikunja#1762
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Is there a reason that you do not show version info on the GUI?
I would submit a PR but only if there are no arguments against showning the version ...
No, not a real reason. Just haven't gotten around in doing this yet.
I think a popup like the keyboard shortcuts, but accesible from the user menu on the top left would be a good way to do this.
I'd happily accept a PR :)
@Bouni are you still interested in creating the PR?
To be honest, I totally forgot about this 😅
If you want to submit a PR for this, go on, if not let me know and I'll see if I can find some spare time to do it ...
I suggest we make this configurable, wether it is shown or not. A common attack vector can be finding an old version of software that contains a security bug. Allowing this to be disabled, if enabled by default, would allow for us to be a little less parinoid ;)
Or only show versions on pages that are behind authentication, aka disallow version to be shown or transmitted from the api if not authenticated.
Currently you get the frontend version in the console when accessing the frontend and the api version when accessing
/api/v1/info
. While we could protect the api version endpoint to only allow access for logged in users I don't see how we reasonably could hide it for the frontend as it has to be embedded in the final js bundle. A scanner could find that.I thought about showing the info in the settings or in a new popup accessible from the user menu so it wouldn't really be too accessible without being logged in.
A frontend version isnt really the issue, it is the backend version that needs to be protected in my opinion. Do the frontend versions differ from the backend version at any given time? If so then it is mute to worry about the bundles js version number that is already there (since that is designating the frontend version).
If the versions always match then ultimately there would need to be modification to this feature in order to make the version something that is loaded from the backend (therefore no longer bundled in the js).
I think it may be overkill to try to obscure the version number to that extent. If there was such a vulnerability, it would not at all be difficult to find the source code for the frontend that was released around the same time as the vulnerable backend and programatically check if an app is serving that same source code.
If you scroll down on this page a little you will see that Gitea has its version number printed at the bottom of the screen. Ultimately, the only way to ensure security is to keep the application up to date regularly.
While somewhat independent the api and frontend should be roughly the same version to function properly. So if you have the version of one of them, you can guess the version of the other.
I definitely agree. "Security by obscurity" never works out great.
I agree that keeping it up to date is the best way, but exposing information such as a version can "aid an attacker to craft targeted attacks against the service"
Refer to here. I worked with Grafana extensively to resolve their version of this. In fact, the main reason why I mentioned this is because it is a valid security concern in my opinion. Totally upto yall though, since I dont really have time to make any PR's at the moment.
https://github.com/grafana/grafana/issues/12925
If I get it this reight, the prefered way would be to have the /api/v1/info a protected endpoint so that only logged in users can use it and have a popup like for the keyboard shortcuts that shows the version info, right?
That would prevent the problem with exposing the info to the world and on the other hand give the logged in user a way to see the versin info.
I'll not start working on a PR unless we come to an agreement about what way to go 😉
/api/v1/info
has to be public because that also exposes other information required for unauthenticated purposes. We could remove the version from it and add a new endpoind/api/v1/version
behind authentication though.Implemented in
f3715c7900