Superbalist’s Not So “Super” Security

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 but I got 302 redirected to – 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 ( 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 “” 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 ( 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…


Takealot Security Issue

So I decided (this morning) to do some more research on SSL encryption and it’s effect on website security and performance.

I tend to use as my default website for checking security compliance and performance. If any South African website should be up-to-date in regards to international security standards, it should be South Africa’s largest e-commerce retailer, Takealot.

I invite you to click on this link ( to view the Takealot home page over an encrypted connection.

If you’re using Firefox, you should be presented with a screen looking something like this:


Not only has the SSL certificate expired (June 13th, 2015), it is only valid for the “” domain.

To be fair, the Takealot login link on the home page redirects to which does have a valid SSL certificate. This does not help people like me who would like to browse the website over a secure connection without being signed in.

This may not be a security catastrophe, but it’s an unnecessary blemish on what is most likely a secure shopping platform.

If you have a connection with someone at Takealot, why not send them to this post – maybe they’ll do something about it. 😛