WTH secure access to www /local behind authentication

Tags: #<Tag:0x00007f32815fa3d8>

Came across an alarming feature the other day, my wifi QR code was publicly accessible online! (see my specific query here = tldr I use the duckdns method to connect remotely, image used in picture card for guests to log on via the wall-tablets).

It seems there is little reason to have the domain.tld:8123/local/ directory available to anyone with the file names and locations. As well as potentially sensitive floorplans (valuable items and cctv locations anyone?!), profile pics, qr codes in my case, etc. HACS stores its frontend files in the www directory, not sure if theres any risk there but I’d rather as little as possible was accessible without auth.

The only way the attacker could view your data is to pick the right name of your files or directories, he can brute force but it’s pretty hard to find them. You could implement ip ban too to minimize this issue

I would argue that obfuscation doesn’t provide any real online security. There is, as far as I can tell, no reason for www to be exposed to the public by default, unless you want something or some files to be publicly accessible. Tightening security of our installs is no bad thing.

eg if you could find someone’s domain (ie from Shodan), and try simple filenames, something like ‘/local/floorplan.png’ possibly, this could expose the layout of someone’s house, camera locations, exits etc, to bad actors… In the realms of a spy thriller perhaps, but possible! While some people may obfuscate our file names and subfolders etc, not everyone would! (I have since removed my guest wifi qr code from my lovelace to avoid any risk, until I find a better solution - or ha devs can fix this issue)

IP ban wouldn’t make any difference to this, www (or domain.tld:8123/local) is publicly accessible… so no auth requests will be made.

edit: what I’ve actually done on my own server.

I was really surprised by this as well. I stumbled on it when I realized nabu casa was serving it up to the world with no password protection.

I have no idea how this stuff works, but is there a reason these files need to be publicly available? Like when sending a snapshot attached to a push notification? At the very least it would be nice to come up with a way to make it more clear to the user that this stuff is all out there. I’m fairly sure it’s in the docs, but I think it is easy to miss. If I recall, a “www” folder is commonly used for serving up content to the world wide web, but what about those of us who lack this tribal knowledge?

1 Like

You mean like this big yellow warning?

If you are really worried about state actors stealing pictures of your backyard put them in a folder with a 24 random character name.

The www directory contents can’t be listed so it’s almost as good as a password.

2 Likes

To be fair, HTTP is part of default_config and because it is enabled by default, that means most people won’t ever go to the HTTP page to see the warning. Yes, it’s there, but unless someone is explicitly going to that section of the docs, they’ll never see it. Personally, I think it should be part of the onboarding docs or at least linked there and the same from the Nabu Casa docs (https://www.home-assistant.io/integrations/cloud/).

It could be added to the security check page too.

I thought the /media directory (protected by home assistant auth) would be a good alternative but it does not seem to be accessible externally.

1 Like

This is what I’m going to push in a PR: Look OK?

2 Likes

PR is up if anyone would like to comment on it: https://github.com/home-assistant/home-assistant.io/pull/14592

haha I knew I going to get shit for posting it, but whatever. I’m learning! While I completely accept my responsibility in all of this, I do think an engineer is compelled to consider users of all skill levels and abilities when designing a system that can do harm. In this case, it sounds like a consideration was made and risk ultimately deemed low - it is hard or impossible for anyone to find these files, but just in case there’s a warning. That works for me; consider me sufficiently no longer worried.

2 Likes

The PR was rejected because the additional warning was added in an irrelevant place (The Home Assistant Cloud integration).

A better place to make that addition would be somewhere like the Security Check Points documentation.

1 Like

I agree. I’ll edit that page and throw up another PR tonight.

That was the location I suggested above. :wink:

1 Like

Yeah, I figured get it into cloud and then I was going to go back and push a PR for security and onboarding. But, I’ll start with security and go from there.

Please leave the www folder open to public, it’s useful for creating camera snapshots and send it with push notifications