Missing authentication for the /icons/ endpoint

[l4rm4nd]

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]

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.

[BlackDex]

Regarding the other points. Checking if you have adult sites in your vault would be difficult. You would need to know the time difference between a cached item or non-cached/expired-cached icon to really tell if that is the case. And then only if it takes a long time to retrieve it from the site it self.

There are security risks of course. You could enumerate a private ip range if you want to check the servers local environment. But by default private ip ranges are blocked from icon fetching on the server side.

There are maybe some nifty tricks you can do with some reverse proxy software, to only allow IP x if there has been a 200 response for URL Y. But the clients do not always login or sync the vault, but could still try to fetch icons because the vault is cached locally. So it will be tricky to really create something which is failsafe.

[jjlin]

Assuming the Bitwarden clients respect HTTP redirects, I think it would make sense to just add a Vaultwarden option to redirect icon requests to Bitwarden, DuckDuckGo, Google, or whatever other icon providers there are, if the user prefers that. Maybe something like ICON_PROVIDER=none|internal|bitwarden|duckduckgo|google.

Users could of course configure redirects via their reverse proxy, but it's a lot more work to document how to do that than to have something built in that just works.

[BlackDex]

So, no caching then, just a redirect to an other services?
I'm not really seeing the actual benefits here besides not storing the icons then locally and always redirect.

In any case, everybody can still use there server to let it trigger three redirect, still no authentication, and that was the main item of this topic. Redirecting to to an other services will not fix that.

[jjlin]

I think maintaining icon privacy was the main point of this topic. Authentication is one way to approach that, though as you mentioned already, it ultimately wouldn't work since the clients don't support it.

If the user is comfortable with redirecting all icon requests to a third-party icon service that they trust, then it is not feasible for an attacker to learn anything about the sites in a self-hosted user's vault since that third-party service presumably has so many users that the attacker would not be able to pick out any particular user.

[BlackDex]

That i agree, and will be the only corner case i think. Besides if someone has fully isolated there Vaultwarden server to not being able to access the internet, then this could be a solution also.

But still, someone would really need to make a big effort into figuring out the time delay between a cached item and a non cached item when using the built-in fetcher. But it could be possible.