Bookmarked:
Summarizing this classic oversight by a major newsletter service provider, as responsibly disclosed by Terence Eden:
- The referrer (or:
referer, as it is falsely spelled in the HTTP protocol) string of a browser coming from a newsletter contains the ID of the subscriber - Website admin can open the “Manage subscription” page using the ID, but is only presented the obfuscated email address (still able to change the subscription, so this is problematic in itself)
- Clicking on “Unsubscribe” leads to a screen that now contains the unobfuscated email address
Hence, until Mailchimp fixed this vulnerability a good month later, the consequence was:
If you visit a link from a MailChimp newsletter, you risk having your email address and your reading habits broadcast to a site owner.
What can we learn from this?
- Whenever publishing anything on the web, always make a privacy impact assessment of sending any form of referrer URL (and, when in doubt, do not send a
refererheader) - Even if a user ID is known to an outsider, they should not be able to modify a user’s data or to determine who is the person behind that pseudonym
These are really two very basic safety steps when designing for privacy. Yet, as the example shows, even big companies whose business is chiefly built upon dealing with personal data sometimes miss these two crucial checks.
