mirror of
https://github.com/binwiederhier/ntfy.git
synced 2026-05-09 16:35:53 +02:00
[GH-ISSUE #487] Android app not sending username/password for attachments #372
Labels
No labels
ai-generated
android-app
android-app
android-app
🪲 bug
build
build
dependencies
docs
enhancement
enhancement
🔥 HOT
in-progress 🏃
ios
prio:low
prio:low
pull-request
question
🔒 security
server
server
unified-push
web-app
website
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ntfy#372
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jakobdalsgaard on GitHub (Nov 11, 2022).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/487
When sending a message with an attachment, picture for example, and this attachment is served from the ntfy server itself, then the request from the app to fetch the image is not sent with the credentials specified in the app for said host.
I run my own ntfy server behind nginx, with TLS and basic authentication; but I need to disable auth for the '/file/' path in the nginx for the android app to be able to fetch the attached image -- I would prefer preventing serving this content to the world by requiring the same password for these files as for any other access to the ntfy server.
I've tried to see if anyone else has seen this behaviour, but I could not find any issues submitted to github.
My ntfy server install is the amd64 debian package version 1.28.0 and the Android app reports 1.14.0 (play)
@binwiederhier commented on GitHub (Nov 11, 2022):
The filename of the attachment is the message ID, which is 12 random characters (a-zA-Z0-9), which is (26+26+10)^12 = 62^12 possible file IDs. So unless you know the message ID (which you don't, because that implies that you know the message), you cannot guess the attachment URL. And that's why the username and password is not required for attachments.
I hope that explains it.
@jakobdalsgaard commented on GitHub (Nov 11, 2022):
Unless you intercept a message, say an email -- then you don't have to guess - and you don't need username/password to get the image. A few comments:
I do understand, from your explanation, that is works as designed, and I'm thus questioning the design :-)
@Ali2731 commented on GitHub (Nov 11, 2022):
thanks
@binwiederhier commented on GitHub (Nov 12, 2022):
Thank you for your feedback. I appreciate you taking the time to investigate and comment.
However, I do not agree with your assessment. A secret URL with a long randomly generated identifier is not security through obscurity. In fact, it is common practice in the industry: Google Photos, GitHub, Discord, Slack, ... Everyone uses this method to serve user content such as images and other media. Here's an example from Google Photos from my personal photo collection. It's not a "shared link".
Security through obscurity implies that you can access a resource or component without knowing a secret, because you've discovered a way around it. The file ID is a secret (as mentioned above), and you cannot access the file without it.
@binwiederhier commented on GitHub (Nov 13, 2022):
Closing this for now. But I'm happy to keep discussing.
@jakobdalsgaard commented on GitHub (Nov 13, 2022):
:-) you have some fair points; and this is definitely something that you have thought of - I'm good with that; though I do not fully agree with you. We don't have to.