This one will really make you laugh, and even if you ever have tried this to pay your house tax with the site of Lucknow Nagar Nigam, Lucknow, India, then I bet that you must have left this online payment system and think of to do this offline.
Try this at your end to test and let me know your thought on this in the comment.
I just posted here to know your thoughts about why this department is forcing to use only Internet Explorer and is there any security reason to use only IE? According to me, now most of the people forgotten about Internet Explorer, they are using mostly Google’s chrome, Mozilla Firefox, Safari, etc. And even most of us using our mobiles to pay online.
Security best practices for Online Payment System
I refer a few selected security practices that can result in possibly serious susceptibilities. Of course, this is not a complete list.
Merchant login page shouldn’t be in HTTP
Serving login pages over HTTP is insecure; it’d be trivial to redirect user to a fake login page, or modify the page in transit and give user a modified form to submit data to.
Use HSTS
Using the HTTP Strict Transport Security (HSTS) header a site can tell the browser to always use HTTPS for that domain in the future. None of the gateways I researched were using HSTS. Most of them are using 301 redirects which are stored in the browser cache. But 301 redirects are URL specific, while HSTS is domain specific. I.e. 301 redirects a single page, HSTS redirects a complete domain. With HSTS (after the first visit by a user) the browser will never contact the site using HTTP again on any of the site pages. If a site isn’t using HSTS, the user cookies can be stolen by directing the user to visit a non HTTPS page while logged in or by redirecting them to a modified login page.
Secure cookies
Cookies should be marked Secure, which tells the browser to transmit the cookie only when the request is HTTPS. So, even if a user opens an HTTP page (which shouldn’t exist), their cookie is never transmitted in clear text to the server. If the secure parameter doesn’t exist, an attacker could eavesdrop on a user’s session when an HTTP page is opened. Having access to the merchant’s cookie, the attacker could steal user data, reset keys or even worse.
Hash based authentication
The above-mentioned security practices involve a malicious third party, this one just involves a malicious user. If a gateway is using a weak MAC generation algorithm, a user could spoof a request with a “transaction succeeded” message that will tell the merchant that the user has paid.
Not relying on “security through obscurity”
Security through obscurity may work in some cases, but it does not work in case of payment gateways at all. Firstly, this information (handshake algorithm, for example) is available through other means (e.g.: through e-commerce software code) and secondly, merchants, both existing and past, using the gateway have that information already.
Have something to add to this story, share your thoughts in the comment.
A Damn Confusing Example of Online Payment System
No comments:
Post a Comment