The website for Mashable allows users to connect with their social media accounts to login and interact. On the surface, it seems good: no passwords being exchanged with Mashable.
However, the entirety of a user’s direct interaction with Mashable is over plaintext, unencrypted HTTP. While a logged-in user browses Mashable’s website on an open or masquerading wi-fi network, an attacker would be able to intercept their name, Mashable username and identifiers, social media identifiers (e.g. Facebook user ID and profile image), and email address – along with any content read or written.
As seen by Wireshark, and as could be seen by anyone on an open wi-fi network:
Also, “…comments sections, forums, and other similar areas of our services are public. Any information posted in those areas is viewable and usable by anyone that has access.” — “Similar areas?” Does that apply to date of birth and ZIP code? Well, it doesn’t matter if you’re sitting on a café’s open wi-fi network:
All pages after a user authenticates should be over HTTPS, with the ‘secure’ flag on any user cookies to ensure that the user’s session can’t be hijacked by an attacker on an unprotected network à la Firesheep. But, since authenticated users can access HTTP pages, users visiting Mashable could easily have their cookies intercepted and their sessions hijacked.
Now for the final issue comes something that a lot of sites could do better. It’s obscure and probably wouldn’t be worthy of shame on its own – but since we saw it…
Mashable’s login options are on their insecure HTTP homepage in the form of various social media icons which open up OAuth permission pop-ups. In the example of Twitter, a user already logged-in with Twitter would be asked if they want to grant Mashable permission – but if the user is not logged into Twitter, they will be asked to enter their Twitter credentials. That’s under normal operation.
That pop-up window is served by Twitter over HTTPS as it should be, but if an attacker on an open wi-fi network injected a false address on Mashable’s HTTP site’s Twitter login button, they could send the user to an alternate Twitter (or Facebook, LinkedIn, etc.) login form.
Most users probably wouldn’t notice if the ‘S’ dropped off the Twitter login pop-up, but they trust Mashable to bring them to the right place and handle their information securely. If Mashable was on HTTPS, that link couldn’t be modified.
Of course, that last issue comes close to scraping the bottom of the barrel of issues to shame — and Twitter shares some shame too. I know this sounds tacky and ineffective, but it might help if Twitter conditioned their users with a bright green “make sure you see HTTPS” banner. (Never talk about looking for ‘the lock’ because some malicious sites use a padlock icon as a favicon, tricking users into thinking it’s secure.)
That was quite a tangent, but in any case, Mashable should use HTTPS on all pages which touch user information, handle forms, or induce a user to authenticate. Which basically means their entire site.