I recently signed up for an account with Superfeedr (a WebSub Hub provider). I noticed a security issue in the sign-up process, and thought it would make an excellent case study for HTTP Strict Transport Security (HSTS). Here’s what Superfeedr did wrong, why they probably didn’t realize it, and how you can avoid making the same mistake in the future.
The Superfeedr website is served over an unencrypted/unsecured connection, and it asked me to submit my desired username, password, and email address to the server over an unencrypted connection. After submitting the login, the website redirects you from the unencrypted to an encrypted/secure connection. The damage has already happened, though. A monster-in-the-middle (MITM) may have observed the authentication credential data and can use them to log in to your account.
This is a serious oversight, but HSTS (RFC 6797) — an internet standard intended to increase security — may have hidden the problem from the Superfeedr developers. HSTS is a server response header that instructs web browsers to always upgrade to a secure connection for all future connections. Superfeedr sends this header, and it should in theory have prevented the problem I ran into at the website.
The problem that Superfeedr ran afoul of is that they hadn’t created a redirect from the unencrypted to an encrypted connection. Web browsers only act on the HSTS response header when it’s delivered over an encrypted connection. Superfeedr sent it over an unencrypted connection so web browsers don’t act on it. After logging in once, the website redirects to an encrypted connection, and the browser will then act on the instructions it receives in the HSTS response header for future connections.
This last detail may have hidden the problem from Superfeedr’s developers. They haven’t adequately verified that their website is served over a secure connection. HSTS can make this more difficult to verify because the web browser will automatically upgrade the connection. You need to use a clean browser profile and not just private browsing mode. HSTS connection upgrades can even persist into private browsing modes!
The Superfeedr website also isn’t included on the HSTS Preload List. Website owners can register their domains on the list to have web browsers enforce the connection upgrade redirect without first having to visit the website over an unencrypted connection. The list currently contains over 134 500 domains. The Superfeedr web server configuration doesn’t meet the relatively simple criteria for inclusion on the list.
This lapse in security over at Superfeedr doesn’t appear to be a recent regression. Historical data from the Internet Archive’s Wayback Machine suggest the website has never implemented a redirect to a secure connection. (I could be misinterpreting the data because the Wayback Machine is a bit vague when it comes to URL normalization.)
In happier news, web browsers are actively trying to deprecate unencrypted connections. Firefox version 83 introduced an optional HTTPS-Only Mode. Google Chrome version 90 uses HTTPS by default for navigations initiated from the address field.
I contacted Superfeedr about my findings seven weeks ago, but I haven’t heard back. I’ve contacted them separately because their service has frequent but intermittent network connectivity issues. I haven’t heard back regarding that problem either.
Update (): Superfeedr has gotten in touch to let me know that they’ve fixed HSTS by implementing the missing redirect. They’re looking into the other problems.
The Superfeedr website appears to run Nginx server version 1.7.1. This was released over six years ago (). This version is considered ancient in internet terms, and has multiple known security issues. Not keeping up with software updates is s sure sign that system security isn’t a company’s number one priority. The lights may be on at Superfeedr but it doesn’t appear like anyone’s home.