Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable returning stateful plaintext passports #45

Closed
n1nj4888 opened this issue Apr 5, 2021 · 4 comments · Fixed by #57
Closed

Disable returning stateful plaintext passports #45

n1nj4888 opened this issue Apr 5, 2021 · 4 comments · Fixed by #57
Labels
question Further information is requested

Comments

@n1nj4888
Copy link

n1nj4888 commented Apr 5, 2021

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?

@n1nj4888 n1nj4888 added the question Further information is requested label Apr 5, 2021
@caronc
Copy link
Owner

caronc commented Apr 8, 2021

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
Copy link
Author

n1nj4888 commented Apr 8, 2021

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
Copy link
Owner

caronc commented Oct 31, 2021

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
Copy link
Owner

caronc commented Nov 6, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants