mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2025-12-11 01:10:09 +03:00
Missing authentication for the /icons/ endpoint #1261
Reference in New Issue
Block a user
Delete Branch "%!s()"
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?
Originally created by @l4rm4nd on GitHub.
Subject of the issue
I would assume that the /icons endpoint of vaultwarden also requires user authentication. Currently, any external user is able to query the endpoint and identify valid icons without being authenticated to the webvault. This may allow someone to enumerate vault url entries or sites that have been stored. One can disable the icon download, but it is kinda handy as for visual aspects.
I don't know whether this is an issue at all. Not a security one from my perspective, but might introduce some privacy concerns if remote people can enumerate whether a vault has some adult or illegal sites stored. What do you think?
Deployment environment
Vaultwarden runs as Docker container on my RPi4 (ARM). Deployed within portainer and compose file. Exposed via an nginx reverse proxy.
vaultwarden version: Version 1.23.0
Install method: Portainer Docker Compose
Clients used: Any client with access to the web vault (http protocol)
Steps to reproduce
Browse your webvault and try an icon path like
/icons/www.google.de/icon.png. Choose a domain or url that you know is stored within the vault. If the icon successfully loads, the vault has likely stored that url and downloaded the icon of the website. If a blank icon occurs, the url might not be stored, does not have an icon or the icon download feature has been disabled.Expected behaviour
The web vault should redirect to the login area and require authentication to display the icons.
Actual behaviour
The web vault responds with the requested image icon if available or defaults to a blank icon. No authentication required.
@BlackDex commented on GitHub:
Your described expected behavior is not the way it works.
All clients do not send authentication to the server to fetch these icons and thus we can't use that.
Unless something is going to change on the client side we can't redirect or put any authenticating on this at the server side.
There is no easy solution to block access to the icon endpoint for authenticated clients only.