Topical was a daily email newsletter service that would send you “the most popular stories [to] your inbox daily”. To cut the description of Topical short, it fetch the top messages on whatever keyword you give them from the Twitter Search API and send you a daily email with the top links. The service also leaks your email address and the interest subscription list onto the public web.
Update (): The Topical website ceased operations in .
Topical clearly wanted to create a frictionless service. There’s no form of authentication required when signing up for a topic. Instead, you just enter your email address and you’ll receive your first email on the topic the next day.
Most large email list providers require what’s known as a double opt-in where they require users to click on a confirmation link before they deliver any further emails. This is done to maintain a good reputation for their domain within email systems and spam classification lists.
Each email address is assigned a unique account identifier. This identifier isn’t derived from the email address itself through a process like hashing (meaning it’s not guessable if you already know the email address), but is an arbitrary identifier of a format called UUID version 4.
Such an identifier contains 122 bits of randomness and is virtually impossible to guess. This identifier is the only thing required to see the email address and interests of a user. In security terms, the account identifier (“username”) is also the account secret (“password”).
It’s important for web services to keep the secrets we give them to keep. Unfortunately, Topical’s desire to create an easy-to use and frictionless service means that the secret isn’t very well protected at all. Every link in the emails Topical sends out points to their own website.
These links also contain the account identifier, enabling the user to modify their interest subscriptions without any extra steps. Topical’s website doesn’t use HTTPS, which means the account identifier is already vulnerable to a attacker-in-the-middle interception attack at this point.
The real problems begin when users share links sent to them by Topical with others. Since their unique account identity is included with the link, they inadvertently hand over the list of topics they’ve subscribed to and their email address.
Some web browsers like Google Chrome, Internet Explorer, and Microsoft Edge even collect the user’s browsing history for various purposes including extending their search indexes.
You can also find a large collection of links containing unique user identifiers and the email addresses of Topical users through regular web search engines.
The account identifier also leaks out when clicking on the links to other websites on the Topical website. As I’ve discussed previously, account secrets and private information can leak out through the HTTP Referer request header (sic.) Topical is a prime example of this problem.
What do you get with a compromised account?
Users can only subscribe to 5 topics with one email address on Topical. Though the service suggests working around their own arbitrary limitation by using different email addressees.
I’m not sure if this is a misguided effort to artificially increase their number of active users for investors, or if they do have a solid technical reason why users are limited to only 5 topics per email address. I suspect the former to be the case.
I can’t find any evidence that Topical have made any attempts at protecting the account identifier. It leaks out of the service through insecure cookies, referrer headers, and all over the place out of sheer negligence.
Account UUIDs are practically impossible to guess. However, you don’t even need to know an account holder’s identifier to get into their account information. All you need is a target’s email address. Given a registered email address, you can sign up for any topic – and in the process the service will lookup any existing account and log you in to it, or create a new account on the fly. So, simply by typing in someone’s email address into the service, you’ll know what topics — if any — they’ve already subscribed to.
An attacker is free to see the registered email address of the user, the list of topics they’ve subscribed to, and can also freely change the topics that the target will receive daily email updates about.
You could use such an attack to boost exposure to a product launch, drive people’s attention to a new piece of software — that’s a camouflaged malware — or other creative exploits of Topical.
What could have been done to reduce the risks?
The obvious solution is to require users to authenticate, but everyone hates passwords and it was clearly a design goal at Topical to avoid that — no matter the cost.
The risk of leaking out the account identifier could have been avoided in many ways. First by moving all website communication to HTTPS to close any monster-in-the-middle (MITM) attacks against the request address or the cookie containing the account identifier.
The email newsletters sent out by Topical should never have contained account tokens. (At the very least not a persistent account token.) Some people forward newsletters to their friends and peers.
There’s nothing to suggest that they shouldn’t forward emails from Topical just like they would any other newsletter. It’s just a newsletter, right?
Any email that did contain a time-limited login token should use redirects to remove the token from the URL. This could be as simple as loading /example?uid=token, setting the account cookie, and then immediately redirecting to /example.
By hiding the token, you reduce the risk of sharing it, either deliberately by posting it on Twitter or unwittingly throughout a click that contains a HTTP Referer (sic) request header.
Lastly, you should instruct search engines to never index pages containing tokens. This would have reduced the impact and ease of discovering accounts through “good” search engines. There are several well documented ways to exclude something from search engines, but Topical haven’t done any of them.
It’s not beyond the wit of men to create a service that fulfills Topical’s effortless authentication requirements. However, you do have to put in the work, and test to make sure that user data doesn’t leak out.
Topical was notified about this issue by email on but haven’t acknowledged it in any way. Topical is made by one of the many companies with the name CatchApp Ltd. The copyright footer on their website says , and their last message on Twitter was posted more than a year ago on . The service appears to have been abandoned by its creator.