How-NOT-To: The eThekwini eServices Website Leak.

It sure has been an interesting week for website security with a considerable number of high profile website leaks.

When it comes to the eThekwini eServices ‘leak’ I use the word ‘leak’ as a generalisation, in my option, this was not a classical ‘leak’. The blaring obvious security vulnerabilities of this site were not the usual weak point in an all round well-structured system that a person with malicious intent hammered till it broke. This site was a wide open faucet with an invite to drink as much as you wished. I hope my analogy comes across and helps intensify how frightening it is that this went live.

Mini rant done. Now I want to get into some detail as to what was soo wrong with this side and some simple guidelines if followed would have mitigated this whole mess.

Some of the first responders Taylor Gibb(Link) and Matt Cavanaugh(Link) have blog posts explaining the timeline of events and shortcomings of eServices

On the day of events, I did some investigating of the site (being an eThekwini client). Very quickly I realised that this was a site built using ASP.NET which has de facto security measures built in which means the developers of this site navigated around all these in place security measures and tried to reinvent the wheel.


Mistake 1


I got an email announcing eServices² and there was my password in plain text! This should never happen.
Even if I am the developer of a system like this I should never know any users passwords.

Identity, this a built in membership system to handle all user-related actions. Passwords need to be encrypted with no easy decryption path. If a user forgets their password there should be no reminder email, only a method to reset it through a verified source like to a verified email address.


Mistake 2

Above is the URL for a user’s profile page. This is the page with the most concern and with the most sensitive user data. This page contained:

  • Email
  • ID Number
  • Deceased Status
  • Gender
  • Account Number
  • Cellphone Number

1. URL parameter should be used sparing and never used for any sensitive data.
2. CustomerId is an integer. Downsides of integers as ids is that they are sequential with a relatively small range which makes them easily guessable. Incrementing customerId=123456 to customerId=123457 would return another users profile page.
3. The fact that I can view another user’s profile means that the user token generated after login is being ignored leaving the pages unauthenticated.

*Generating a bill is also subjectable to similar design flaws.


The page with the most mistakes has the simplest solution. Use the user token as intended, to authorise the user.
From a user token, you can retrieve the customerId which mitigates the need for the URL parameter and pages can be authorised if you are the viewing your own profile.



eServices is a fantastic initiative by the municipality and I don’t want to see this project killed off because of this. I want to see this work so I will put it out there that I am willing to help. Whoever is developing this site feel free to contact me and I will happily test free of charge.