Unsolved: Securing access to local image on picture card

Configuration Frontend
,
1

I can’t find out how, or if, I can have a locally-hosted image in a picture card. Problem:

Placing images in the www directory, while I have ssl and mfa auth remote access, keeping files in this directory allows anyone to access them at mydomain.tld:8123/local/image.jpg

**Can I point picture (or glance/entity) cards to a local file WITHOUT putting that file in the publicly accessible /www directory? ie keep them somewhere else on the system and reference that in the card instead of ‘/local/image.jpg’ **

–
A further question: I use a few custom cards via hacs. These are stored in /www/community/, which means they are ALSO publicly accessible. Though the .js and associated files are all publicly available from the components’ repositories, I still feel uneasy having anything accessible to view without auth… Any pointers how to prevent this happening without killing the custom cards?

2

AFAIK, there is currently no way to secure the /www endpoint. For a workaround, you could put a reverse proxy with auth in front of HA using something like Nginx, Apache or other type of webserver.

It would look something like:
[external] <-> [Nigix/Apache /w auth] <-> [HA]

That way, there’s an auth challenge from any external traffic trying to access your HA instance.

1 Like
3

Thank you! OK It might come to that if I can’t find another way…

I’ve actually only got ONE image I want to serve on a picture card: a QR code for my guest wifi network that sits in a panel-mode picture card on the tablet on the wall of my lounge - I’d rather the credentials weren’t publicly accessible even if the guest VLAN is firewalled… Its a shame it doesn’t seem possible to put images into a different folder and have a different url than /local?

4

Files served from /media are protected by Home Assistant authentication unlike those served from /www . Maybe use that instead?

1 Like
5

I believe /local is hard-coded. I’m not 100% sure.

The easiest solution is to host any images you don’t want shown externally on a local webserver and point the image url to that. What’ll happen is that when your instance is viewed externally, it won’t show the image because HA won’t be able to access that internal url remotely.

And, the new media source feature that @tom_l just posted works as well.

1 Like
6

Thanks @tom_l it doesnt appear to work though, I added the qr.png, to (a subfolder in) the media folder and it’s not showing as a valid photo in the card. this is the yaml:

hold_action:
  action: none
image: /media/images/guest_qr.png
tap_action:
  action: none
type: picture

Shows the broken link icon in the frontend. Am I missing something, none of the documentation indicates it should work but i thought I’d give it a go…?

1 Like
7

Also FYI, people from outside can only access the image if they know the exact name and folder it’s stored in ,they can’t browse the folder. So giving the QR code picture a really obscure name should help mitigate the risks.

1 Like
8

Thanks… OK, feels like, another slightly overkill solution. Maybe if I establish /local is hardcoded for these things I can submit a WTH (is it too late?!) or a normal issue on this - seems too obvious to me to be a common issue though!?

9

I’ve brought this up in a bug report before and I know people are still posting WTH posts.

It absolutely is, 100%. However, given that the frontend isn’t 100% secured, it kinda has to be, if that makes sense. As @Burningstone said though, an attacker needs to know the exact path to a file to request it, but in my mind, that’s not really “security”, that’s security by obfuscation that is easily defeated.

1 Like
10

I know it’s not really security, but how would an attacker “easily” find the exact name and folder of the file? If I call my file 81tvfoe6f5d6sbr7qr.png and put it in the directory www/dhdve6d58/, I doubt anyone is able to get to this file, as he needs to have my domain, the obscure name and the obscure path.

In addition, this QR code only allows access to a guest network, which I assume is secured as well. So this means in addition to all of the above, the attacker also needs to be in WiFi range to make use of the QR code.

2 Likes
11

Easily would be a man in the middle attack. WAY too common now-a-days. Couple that with war-driving and the fact that way too many people still use things like password as a password and there’s a recipe for disaster.

I was afraid it would come across like I was discounting what you were saying and I want to clarify that is absolutely not the case at all. You are right that for most cases, an obscure file name and directory is adequate. My point was more towards the open /www directory still being an active and available attack vector.

3 Likes
12

No worries, I didn’t feel this way at all :slight_smile:

2 Likes
13

Following this conversation: yes I think it’s very unlikely if I use a couple of long random file names that someone would also find my address, and get within range of the WiFi and THEN find a way through my guest vlan firewall (I’m no hotshot, but hoping it’s fairly secure: I followed a guide for pfsense firewall rules I found online!)… unless of course they were targeting me! I still can’t help feeling quite uncomfortable about having it out there.

I’ll look to raise it as an issue and see if there’s any traction for the devs to look at it?!

14

I made the WTH @code-in-progress!

1 Like
15

Oh and while I’m at it, I realised this is infact two different issues now we have the media source integration in 0.115, so I created a new WTH here:

1 Like