Email alerts include link to *my* alert preferences unauthenticated
(1) By anonymous on 2018-08-11 17:53:18 [link] [source]
If I ever decide to forward a message to someone it will include the link to my subscription preferences and consquently the recipient can unsubscribe me if he wants. A better approach would be to send a link that when clicked fires off another private email to the user which has a one-time use option to update the preferences.
(2) By Warren Young (wyoung) on 2018-08-11 19:20:07 in reply to 1 [link] [source]
Bug verified. The Fossil instance should check whether the user has a valid login and that the name matches the one it found by parsing the hash given in the /alerts URL. If there's a mismatch, give an error message instead of presenting the other user's subscription details.
As for changing the way notification messages are handled, I'm not sure about that. With the above fix, the URL will just be noise to someone else.
I'd just make it a point to edit that out of my forwarded message, simply out of courtesy to the recipient. No point sending them a URL they can't make use of.
(3) By anonymous on 2018-08-12 01:34:14 in reply to 2 [link] [source]
I often forward messages as an attachment intentionally so the recipient has a full mess822 copy, not a mangled version---that usually means that editing the message is not an option.
(4) By Warren Young (wyoung) on 2018-08-13 02:29:31 in reply to 3 [source]
My understanding of the email alert system in Fossil has improved since my prior post, so I can now say that my proposed fix will only work if you actually have a login on the Fossil repo that sent the email.
If you're subscribed to email alerts and don't have a Fossil repo login, that 32-character hex string is your identity, as far as Fossil's concerned. By including it in a forwarded message, you've basically given away part of your identity on that Fossil server to the recipient.
Quoting the email design document:
The link includes the random 32-byte subscriberCode in hex. If anyone visits the link, the email address is verified.
There is no password. Knowledge of the subscriberCode is sufficient to control the subscription. This is not a secure as a separate password, but on the other hand it is easier for the average subscriber to deal with in that they don't have to come up with yet another password. Also, even if the subscriberCode is stolen, the worst that can happens is that the thief can change your subscription settings. No PII (other than the subscriber's email address) is available to an attacker with the subscriberCode. Nor can knowledge of the subscriberCode lead to a email flood or other annoyance attack, as far as I can see.
The document then goes on to suggest periodically resetting these once a day, but I think that's only a good idea if all your subscribers are within a few time zones of the Fossil server, so that the new codes are effectively valid all day. The further you wrap around the planet, the shorter the window between the daily digest going out and the time when the code in the footer of that digest email becomes invalid.
I think to make such a solution practical, Fossil would have to remember at least one past code for each subscriber, so that the prior code(s) don't immediately become invalid when a new one is generated.