FlipKart.com is referred to by many, as India’s Amazon. While performing a quick search on FlipKart for a book I could not find elsewhere in India, I saw a link to their mobile website.
The single search form tempted me to test XSS through it (I thought it to be a long shot, but what the heck!), and bingo! it was working. It was very trivial to exploit. A classic “<script>alert(‘xss’)</script>” was all that was needed. No fancy escapes or encodings needed.
This simple flaw had two implications:
- The form was submitted through GET method (as most of the search forms), making it easier for the attacker to trick the user into executing a malicious javascript payload (which could include an ajax-keylogger, session stealer, phishing etc.) by simply sending out the URL. in POST scenario, a POST request from attacker controlled page would have to be issued, making it a little more trickier.
- The mobile site is not hosted on a different domain or a sub-domain. This would make the cookie-stealing effective for the main website as well. Also the javascript payload did not have the restrictions of same-origin policy.
This flaw was too easy for anyone to miss, and considering that FlipKart has thousands of users doing e-commerce daily, it was very important to notify them of this trivial vulnerability.
An email was sent to them on January 25th to notify them of the flaw. Till now, we did not get any reply. Today, while checking for the issue again, it seemed fixed. I dropped a reminder email. It was followed up by an email stating the flaw had been fixed.
Although the flaw in question was very trivial, it is definitely encouraging for security researchers when a companies acknowledge vulnerabilities, and fix them while keeping the informers in loop. Anyways, it is fortunate that this problem got their attention, and got fixed in due time. This is something which you see seldom happening.
Another problem I faced (also faced in different cases like this and this) is the non-listing of contact information to report security issues or generic bugs on the contact pages. It is a nightmare to find only a contact-us form, without any email listing. In these cases, we use (and recommend using) the whois email information or RFC 2142 addresses.
