UPDATE (December 5, 2016)
So I thought I would revisit this issue today by having a look at Superbalist’s website.
I can happily confirm that Superbalist’s website now defaults to SSL-enabled HTTP connections. YAY!
Out of interest, I thought I’d take a look at their mobile apps…
I fired up my local web proxy and had a look at the traffic generated by the Android app.
Long story short, Superbalist’s Android app does not encrypt any customer authentication data sent to their servers.
Here’s a screenshot of my web proxy inspecting the user authentication request:
So it would seem that lightning CAN strike the same place twice.
Maybe I can make it a hat-trick by having a look at their iOS app…
Following on from my previous post, I thought I’d have a look at one of Takealot’s subsidiaries, Superbalist.
I tried accessing https://superbalist.com but I got 302 redirected to http://superbalist.com – so much for browsing securely…
I then turned my attention to their login modal (see Figure 1).
Figure 1. Superbalist login modal (popup)
I tried entering in a random email address (test@test.com) and password (test). I received a revealing response from their server (see Figure 2).
Figure 2. Revealing response from server
So what is so revealing about the server response? It’s telling me the password is incorrect. So what, right!? But look at what it’s not telling me. It made no reference to the validity of the email address. This suggested that the random email address I entered was valid. I needed to know if this was indeed the case, so I tried another very random email address (see Figure 3).
Figure 3. Email address validation
My suspicions were confirmed when the server responded with “The email address does not exist”. I re-entered the “test@test.com” email address and no error message was displayed. I knew then that I had unwittingly discovered a valid login email address. This could be used as a means to check if a given email address is registered on the website. This may not be a critical issue, but this is valuable data for a malicious user i.e. hacker.
Now for the really interesting part: form submission.
It is important to have all user authentication fields (in this case, email address and password) transferred over an encrypted connection. Since the internet is a public network, there’s no guarantee that your “in transit” information will be kept private. It is essential to keep sensitive information encrypted to ensure confidentiality and integrity. Generally speaking, encrypted connections will have URLs beginning with “https://”. Non-encrypted connections typically have URLs beginning with “http://”.
Looking at the source code of the login form revealed that Superbalist seem to be sending the login credentials over a non-encrypted connection. Looking at the blue highlighted line in Figure 4, it’s clear to see the destination URL of the form (http://superbalist.com/users/login) begins with “http://”.
Figure 4. Superbalist login form source code
Opening up the Developer Tools window in Chrome confirmed the request URL begins with “http://” (see Figure 5). The remote address also ends with “:80”, which means the connection is on port 80 of the web server, the default port for non-encrypted web traffic. The standard port for encrypted HTTP traffic is 443.
Figure 5. Chrome Developer Tools connection info for Superbalist login form
So if my observations are correct, Superbalist are not encrypting their customer’s login data. I would be more than happy to have someone at Superbalist challenge me on this observation.
Let the games begin…