Invite token leak in referers #830

Open
opened 2020-04-26 00:56:57 +00:00 by wowaname · 9 comments
Member

Saw this in access logs (the invite token is expired so please don't think you're clever to try it):

79.218.187.123 - - [20/Apr/2020:19:51:58 +0000] "GET /media/125aac9d4876ae2cb4e8b19d039094ab8ff65124409cf39390f09270fab45129.jpg?name=blob.jpg HTTP/2.0" 200 42000 "https://netzsphaere.xyz/registration/JvJdL1NdH8u8a6tZMf9PJxTeSGR6rfYrhwc_fO3k2Bs%3D" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362"
79.218.187.123 - - [20/Apr/2020:19:57:39 +0000] "GET /media/3746c23bdb89b767f2c5c9c20d84e1da89c44269f8790a15a4cd87121fe7d5dd.gif?name=mastodonpyupload_1587409214.7849407_ZICNPQ13Y1.gif HTTP/2.0" 200 14608487 "https://netzsphaere.xyz/registration/JvJdL1NdH8u8a6tZMf9PJxTeSGR6rfYrhwc_fO3k2Bs%3D" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362"

I don't know what is prompting requests to remote servers' media on the registration page, but I'm pretty certain an invite token is somewhat sensitive information (for the duration in which it is extant) and remote requests should not have Referer headers that include this information.

Saw this in access logs (the invite token is expired so please don't think you're clever to try it): ``` 79.218.187.123 - - [20/Apr/2020:19:51:58 +0000] "GET /media/125aac9d4876ae2cb4e8b19d039094ab8ff65124409cf39390f09270fab45129.jpg?name=blob.jpg HTTP/2.0" 200 42000 "https://netzsphaere.xyz/registration/JvJdL1NdH8u8a6tZMf9PJxTeSGR6rfYrhwc_fO3k2Bs%3D" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362" 79.218.187.123 - - [20/Apr/2020:19:57:39 +0000] "GET /media/3746c23bdb89b767f2c5c9c20d84e1da89c44269f8790a15a4cd87121fe7d5dd.gif?name=mastodonpyupload_1587409214.7849407_ZICNPQ13Y1.gif HTTP/2.0" 200 14608487 "https://netzsphaere.xyz/registration/JvJdL1NdH8u8a6tZMf9PJxTeSGR6rfYrhwc_fO3k2Bs%3D" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362" ``` I don't know what is prompting requests to remote servers' media on the registration page, but I'm pretty certain an invite token is somewhat sensitive information (for the duration in which it is extant) and remote requests should not have Referer headers that include this information.
Owner

Access logs of what, exactly? A proxy server?

Access logs of what, exactly? A proxy server?
Owner

ah, i think i understand it now. refers in access logs for other servers since media fetching goes directly there

ah, i think i understand it now. refers in access logs for other servers since media fetching goes directly there
Owner

I think we can disable referrer headers completely.

I think we can disable referrer headers completely.
Member

I thought Referrer-Policy: same-origin was supposed to prevent that?

I thought `Referrer-Policy: same-origin` was supposed to prevent that?
Member

It does and we add it in default config, but netzphaere doesn't send it. Needs clarification from their admin

It does and we add it in default config, but netzphaere doesn't send it. Needs clarification from their admin
Member

Shouldn't it be just be set at Phoenix level?

Shouldn't it be just be set at Phoenix level?
Author
Member

If only the issue was public so the admin could reply

If only the issue was public so the admin could reply
Author
Member

If this is the case then it's really not Pleroma's bug. It's expected behaviour. I know barely anything about all the HTTP headers to have a clue about how these issues are usually mitigated.

But in any case it's probably best that, because sensitive information must be included in the URI (to make it easier for people to click an invite link and register, rather than having to copy and paste any codes into the right textboxes), pleroma-fe should avoid making remote requests from the registration page in the first place. (There's nothing that can be done about someone including remote media in the terms-of-service.html, but other than that it seems possible to mitigate.)

If this is the case then it's really not Pleroma's bug. It's expected behaviour. I know barely anything about all the HTTP headers to have a clue about how these issues are usually mitigated. But in any case it's probably best that, because sensitive information must be included in the URI (to make it easier for people to click an invite link and register, rather than having to copy and paste any codes into the right textboxes), pleroma-fe should avoid making remote requests from the registration page in the first place. (There's nothing that can be done about someone including remote media in the terms-of-service.html, but other than that it seems possible to mitigate.)
Owner

we should test if default/recommended setup is affected, and if it's not then we can remove confidentiality

we should test if default/recommended setup is affected, and if it's not then we can remove confidentiality
Sign in to join this conversation.
No milestone
No project
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
pleroma/pleroma-fe#830
No description provided.