How NOT to design a secure website – case study

Update: As of 28/02/2013 freecharge have enabled SSL in their website thereby increasing site’s security.It should be safe to use credit card as long you don’t leave the cookies behind if working on a public system. is a convenient site for pre-paid mobile phone/DTH/datacard recharge, and no doubt, my go-to website for the same. The site has a decent visitor base too, but apparently they don’t give any importance to user’s security. Casual browsing revealed seriously security flaws. My conclusion is that can be the best example of how NOT to do website security.

I have listed a few below:

No SSL for Login Page!

Login page is not protected by SSL, which essentially means anyone in your network, with right set of tools will know your user name and password.And for guys who uses same password for all sites, nothing to say!

Freecharge Login page with no SSL protection

Freecharge Login page with no SSL protection

Sending Credit card details as plain text!

Recently they have added the facility to enter credit card details in the confirmation page itself rather than on payment gateway’s page.Here again no SSL, and uses GET method to send credit card details rather than POST. Which means even if they had SSL,card details will be send as plain text.

Freecharge's insecure credit card page

Freecharge’s insecure credit card page

Insecure GET method used by

Storing user-name and password as cookies!

User-name and password are stored as plain text in the form of cookies. An added problem is that since cookies will be sent for each request made to the server, username and password will be sent in plain text everytime!. So if you have used on a public computer, your username and password have been stored too, waiting to be read by a malicious person. stores username and password as cookies stores username and password as cookies

Some tricks to keep you safe

Immediately change password of all other sites if you are reusing password.

Don’t use credit card for transactions, uses net-banking instead.

Avoid using the site in public computers, or at-least remember to delete the cookies after use.

Raise concern to team (I have raised it already and they have replied saying it isn’t possible for them to do anything on this regard as of now. If only something comes out of a large user-base complaining).

This entry was posted in Security and tagged , , , . Bookmark the permalink.

One Response to How NOT to design a secure website – case study

  1. Mohammed Zuber says:

    Old News … now PCI Compliant

Comments are closed.