XBOW-025-016 - SSRF via HTTP Attachment Addressed #232
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description:
Related issue (if applicable): refs #230
This code merge ONLY impacts situations where a HTTP web request is provided as an Attachment Source. The Apprise API will retrive the contents and forward it along with the notification.
This solution adds 2 new variable system parameters that can be over-ridden using their respected environment variable (same name)
APPRISE_ATTACH_DENY_URLS
: Defaults to:'127.0.* localhost*
APPRISE_ATTACH_ALLOW_URLS
: Defaults to*
The idea is to grant the system owner hosting Apprise API a means of having control over what attachments can be retrieved by their server.
Deny list is always processed first, and thne the Allow list. If no match is found on the Allow list, then the URL specified is rejected.
Both lists support all sorts of combinations:
localhost
,localhost*
,127.0.0.*
,192.168.0.*
,localhost:8000
https://localhost
,http://localhost:3000
https://localhost/attach
,https:/myserver/path/to/*/dir
localhost/attach
,my.server:3000/incoming/
when no schema is defined, it is implied that you are accepting both
http
andhttps
. When a schema is defined, it is implict. If you definehttps
and only pass inhttp
, it will not match.You can use the
*
wildcard which behaves slightly different in the hostname and/or path. The path is the most notable as the*
can not pass through paths (separated by/
).You also do not need to specify a
*
a the end of a path as it is implied. Consider the definitionhttps://localhost:8000/my-files/
. This translates under the hood ashttps://localhost:8000/my-files/.*
. Thus the following is accepted:https://localhost:8000/my-files/path1/
https://localhost:8000/my-files/path1/path2/
The other character you can define in your string is
?
which can subsitute for any single character. e.g:http://my-server??/static/??
could accept valid entries such ashttp://my-server12/static/ab/test.jpg
for example.Checklist
flake8
)