WTH secure access to www /local behind authentication

Month of "What the heck?!"
Tags: #<Tag:0x00007fc416e8acd8>
#1

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.

Unsolved: Securing access to local image on picture card
WTH you can't use files stored in new /media directory as local sources for picture cards
#2

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

#3

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.

#4

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
#5

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
#6

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/).

#7

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
#8

This is what Iā€™m going to push in a PR: Look OK?

image
image1236Ɨ748 92.7 KB

2 Likes
#9

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

#10

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
#11

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
#12

I agree. Iā€™ll edit that page and throw up another PR tonight.

#13

That was the location I suggested above. :wink:

1 Like
#14

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.

#15

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

#16

You can still handle that with for example a time limited url.