architecture icon indicating copy to clipboard operation
architecture copied to clipboard

Restrict access to the /local/ directory and any other unsecured content

Open Santobert opened this issue 6 years ago • 7 comments

Context

I would like to make HA accessible from the Internet, but at the moment everything in /conf/www is accessible via https://my.ha.com/local. This means, for example, that any profile picture can be viewed by anyone without authentication (see instructions at https://www.home-assistant.io/integrations/person/#customizing-the-picture-for-a-person). I see no reason why content should be available without authentication. The /api endpoint is accessible, which is fine since some apps require access to it. But /local only becomes relevant after someone has logged in.

Proposal

Access to any content should be restricted as far as possible. Especially everything accessible via /local should be restricted to logged in users. Every sensitive content under /api should be restricted as well. I know that camera stream, which are available at http://my.ha.com/api/camera_proxy_stream/ are secured by a token. This is completely fine, I think. Maybe this can serve as an example for other content that should be secured. However, we should be aware that there is a problem with outdated but cached tokens that causes users to be blocked by fail2ban (https://github.com/home-assistant/home-assistant/issues/23055).

Consequences

Most content is only available to logged in users. Only content that needs to be freely accessible is so. Sensitive content cannot be seen by third parties. It is easier for the end user to decide whether HA could be accessible via the Internet or not.

Santobert avatar Nov 12 '19 08:11 Santobert

/local should only be used for static files. We also set aggressive cache headers on it. Securing get is going to be impossible because you can't attach auth to an img tag etc.

If something needs to be secured, we should serve it via an integration under /api and have it be secured.

balloob avatar Nov 12 '19 10:11 balloob

Hm, that makes sense. I don't want to make my family's profile pictures or floorplans available on the internet. But I understand your point.

I also use some custom maps via a git submodule, which makes some other things (.git for example) unnecessarily accessible, but this may be a special case.

Santobert avatar Nov 12 '19 11:11 Santobert

We have an attempt several months ago, see: https://github.com/home-assistant/home-assistant/pull/21104

awarecan avatar Nov 22 '19 01:11 awarecan

Why is it HA isn't using standard authentication fields for it's bearer token. Then it would work right?

elupus avatar Nov 22 '19 06:11 elupus

I think this issue should attract a little more interest. Especially in light of the current situation. In my opinion, without a long-lived access token, a bearer token, or username and password, someone shouldn't be able to see much more than a login screen.

I understand the problem with caching, but in this case our privacy should be more important than loading time. Unfortunately, I'm not an expert on this type of problem, so I don't have a solution ready. But we should definitely discuss possible solutions...

Santobert avatar Jan 23 '21 08:01 Santobert

/local aka /www can be a easy target for dirbuster. People are storing ie. QR codes for their WiFi there and showing it in lovelace. Finding one's location via nabucasa URL may be hard, but if someone is hosting HA on their own domain and there's an neighbour with Kali installed... ;-)

andriej avatar Jan 23 '21 10:01 andriej

/local aka /www can be a easy target for dirbuster. People are storing ie. QR codes for their WiFi there and showing it in lovelace. Finding one's location via nabucasa URL may be hard, but if someone is hosting HA on their own domain and there's an neighbour with Kali installed... ;-)

  1. Do not open ports to Home Assistant
  2. Phone--(VPN secure connection)--(Your router)--(HA)

PricelessToolkit avatar Aug 09 '21 19:08 PricelessToolkit

This architecture issue is old, stale, and possibly obsolete. Things changed a lot over the years. Additionally, we have been moving to discussions for these architectural discussions.

For that reason, I'm going to close this issue.

../Frenck

frenck avatar May 11 '23 13:05 frenck

@frenck Issue is still pretty much present and there is no alternative to set custom pictures that should not be accessible for unauthenticated users.

As an example try to set a image on a "Picture Glance Card" or to attach a picture to a notification. All these pictures can be accessed for unauthenticated users, and the best one can currently do is to scramble the file name.

If you put private pictures from your home in these cards, these pictures are all publicly accessible with the right URL..

Is this issue being ignored now? Or is there some place this is being further discussed and where is that.

rkkoszewski avatar May 11 '23 13:05 rkkoszewski