caronc / apprise-api

A lightweight REST framework that wraps the Apprise Notification Library
https://hub.docker.com/r/caronc/apprise
MIT License
638 stars 56 forks source link

Disable returning stateful plaintext passports #45

Closed n1nj4888 closed 2 years ago

n1nj4888 commented 3 years ago

:question: Question The main apprise API webpage (https://github.com/caronc/apprise-api) contain the following text:

You can pass in attributes to the /json/urls/{KEY} such as privacy=1 which hides the passwords and secret tokens when returning the response.

The above does seem to hide the passwords returned but I couldn't find a way of actually stopping a user from calling /json/urls/{KEY} without the privacy=1 attribute? For example, is there a way in the apprise API {KEY} config to specify that passwords should always be returned to a GET /json/urls/{KEY} regardless of whether the privacy attribute is added or not?

caronc commented 3 years ago

Hmm... One thing you could do is park an NginX server in-front of your webpage and strip off any kwargs passed in?

Alternatively do you think it would be better to have 2 separate URLS... or maybe a global system variable you can specify that turns this off when set (like an ALWAYS_PRIVACY_MODE=1)?

There is also the /get/{key} which returns the URLs so they can be used by the external apprise CLI (remotely). So setting this suggested flag would have to disable this too...

Thoughts?

n1nj4888 commented 3 years ago

Hi @caronc - The use of a global variable such as ALWAYS_PRIVACY_MODE=1 forcing all passwords to be obscured in GET calls / any response data sounds like a good idea

caronc commented 2 years ago

I know it's been a very long time since I've looked at this, but I've finally had time to. But while doing it, i saw that there were quite a few flaws with the request and I wanted to bounce them off you to see if it was still worth changing up how we could handle this.

First off; i think the problem here is the fact that anyone can change the URL http://localhost:8000/json/urls/{token}?privacy=1 to http://localhost:8000/json/urls/{token}?privacy=0. I get this. But if I were to force the privacy to always be 1 the same attacker could also just extract your configuration from http://localhost:8000/cfg/{token} (which is your Configuration Screen itself in the API); it's also the location referenced by the CLI tool --config option (if you're using it). So this PRIVACY_MODE would also have to disable the these 2 features when set. Was this kind of what you're going for?

  1. Someone would set up their Apprise Configuration in the API and then shut it down.
  2. They would then set an agreed upon Environment Variable; This setting would then disable:
    • The --config= option from the Apprise CLI (disabling it); but you can still use the apprise:// plugin recently added as an alternative (coming out in the 0.9.6 release).
    • The Configuration tab from the GUI
    • The /json/urls/{token}/ would continue to operate (but enforcing privacy mode always

This would probably resolve #46 as well since you would no longer be able to update your configuration anymore with this shared global variable.

Does this make sense? What are your thoughts?

caronc commented 2 years ago

Just letting you know the last PR should solve all of your very valid issues you pointed out! :+1: