Friday, November 25, 2016

Native apps don't have a way to signal trust

The one thing the web has gotten right to some extent (thanks to the beauty of REST/HTTP) at least compared to desktop and native apps, is how it can uniformly show users if they are using a secure connection to a trusted source. The browser does this by clearly and consistently giving various hints (see Fig 1 and Fig 2 below):

Fig 1. Firefox indicating that you are securely connected to GitHub.

Fig 2. Chrome indicating that you are securely connected to GitHub.

There is no reliable, trustworthy and consistent way for non-technical users to do this for desktop and native apps.

This is how you add funds to your Paytm wallet from within the Uber app (see Fig 3 below):

Fig 3. Page to add funds to your Paytm wallet from within the Uber app.


Notice the following in Fig 3:
  1. Since I opened this from within the Uber app and this "page" is running "inside" the Uber app, I have no way to verify if what I'm seeing is in fact a page severed by Paytm or a spoofed page that Uber is presenting to me.
  2. Even if I were to trust Uber here, there is no way for me to tell if this is happening over a secure connection.
  3. Say I'm willing to accept that this is in fact a page served securely by Paytm, I have no way to know if Uber has injected their own code to intercept everything I enter on that page.
  4. And now the really ridiculous bits (circled in red in Fig 3 above): The text that reads "Your payment details are secured via 128 Bit encryption by Verisign" and the various logos that are displayed at the bottom of the page are something I have to take at face value. These are also app-specific and not consistent.
Also, note that I (as a non-technical end-user) have no way of knowing if all communication the Uber app is doing with it's servers is over a secure channel. I just have to "trust" that they are doing the right thing. Of course, as a technical user I could intercept the traffic on my phone and see how it's been sent, but that is exactly the point: You have to jump through a lot of hoops to "verify" what is happening.   

The current state of affairs for security on native apps is absolutely ridiculous and it's crazy that we all put up with it.

Full Disclosure: I work at Zeta (at the time of writing this blog post), but the views expressed here are my own and not of my employer.

Native apps can't be trusted

The one thing the web has gotten right to some extent (thanks to the beauty of REST/HTTP) at least compared to desktop and native apps, is how it can uniformly show users if they are using a secure connection to a trusted source. The browser does this by clearly and consistently giving various hints (see Fig 1 and Fig 2 below):

Fig 1. Firefox indicating that you are securely connected to GitHub.

Fig 2. Chrome indicating that you are securely connected to GitHub.

There is no reliable, trustworthy and consistent way for non-technical users to do this on desktop and native apps.

This is how you add funds to your Paytm wallet from within the Uber app (see Fig 3 below):

Fig 3. Page to add funds to your Paytm wallet from within the Uber app.


Notice the following in Fig 3:
  1. Since I opened this from within the Uber app and this "page" is running "inside" the Uber app, I have no way to verify if what I'm seeing is in fact a page severed by Paytm or a spoofed page that Uber is presenting to me.
  2. Even if I were to trust Uber here, there is no way for me to tell if this is happening over a secure connection.
  3. Say I'm willing to accept that this is in fact a page served securely by Paytm, I have no way to know if Uber has injected their own code to intercept everything I enter on that page.
  4. And now the really ridiculous bits (circled in red in Fig 3 above): The text that reads "Your payment details are secured via 128 Bit encryption by Verisign" and the various logos that are displayed at the bottom of the page are something I have to take at face value. These are also app-specific and not consistent.
Also, note that I (as a non-technical end-user) have no way of knowing if all communication the Uber app is doing with it's servers is over a secure channel. I just have to "trust" that they are doing the right thing. Of course, as a technical user I could intercept the traffic on my phone and see how it's been sent, but that is exactly the point: You have to jump through a lot of hoops to "verify" what is happening.   

The current state of affairs for security on native apps is absolutely ridiculous and it's crazy that we all put up with it.

Full Disclosure: I work at Zeta (at the time of writing this blog post), but the views expressed here are my own and not of my employer.

What native apps get wrong over web apps

  1. They need to be installed. This in itself is a big drawback.
  2. They need to be separately developed for each target platform. Unlike the desktop app days where Windows was almost ubiquitous, with mobile you have to support 2 platforms.
  3. They can get outdated if users don't upgrade. We are doomed to repeat the same mistakes we made with desktop apps.
  4. Deployment is blocked on an black box not in your control (aka the app store approval process). Kiss continuous deployment goodbye.
  5. They have no trustworthy way to indicate to users that secure channels are being used to communicate secure information (unlike the address bar in web apps that clearly shows if the connection is secure and to the right place). If you think about it, there is a beauty to REST/HTTP that makes this possible.
  6. Each app needs to reinvent the wheel and ship infra that could have been shared, e.g., local data store, caching, etc.

Saturday, December 07, 2013

Security breach at Myntra.com exposes customer's personal information, order history and more

Update (added on 3 Dec 2013): Based on my feedback Myntra.com has now setup security@myntra.com for reporting security issues and a Responsible Disclosure Policy page. Kudos to them for taking the first step towards a better responsible disclosure process and setting an example for other Indian companies.

Last week a bug on Myntra.com let anyone with an account take over random customer accounts and highlighted the lack of responsible disclosure processes among Indian companies.

On 28th November (2013), Myntra.com held a 3-hour (8-11pm) invite only Winter Sale event where a few select customers got an additional 31% off on all orders above a certain amount.

I was one of those customers and decide to login to my Myntra account to see the coupon, except I had forgotten my Myntra account password. So I went ahead and put in my email address and clicked on the forgot password link. As expected I got an email with instructions, to click on a link to set a new password. What happened next was very scary.




I clicked on the link and landed on the page on Myntra.com to set a new password but instead of my email address I saw someone else's email address pre-filled in the form. Curious to see what would happen, I went ahead and put in a new password and lo and behold, Myntra.com had let me take over another customer's account. 




To see if this was repeatable, I went through the forgot password flow again and just like before it had another random customer's email address pre-filled in the form and let me take over that customer's account.




HOLY SHIT. Myntra.com just let me take over two customer accounts. No fancy hacks, just a scary little bug that presented other Myntra customer accounts to me on a platter.

So the first thing I did was see if I could find anything on Myntra.com about responsible disclosure or a security contact but found nothing. So I sent an email to security@myntra.com and it promptly bounced with the message "The email account that you tried to reach is over quota".

Next I got in touch with them on Twitter and 13 hours later someone got in touch with me, 16 hours later I was speaking to a Tech Lead from Myntra.com and 9 days later I have confirmation from them that they have fixed the bug and put measures into place to ensure this doesn't happen again.

Note (added on 8 Dec 2013): The bug was fixed on the same day I reported it and the 9 days mentioned above includes time they took to monitor the fix and the Tech Lead at Myntra.com and me having issues around coordinating the final confirmation phone call.

I don't know how long this bug was live and how many customers accounts were affected but if your account was one of the affected ones, it means someone had COMPLETE access to your account, your personal details like your address and phone number, your order history, your myntra credit points, your saved payment details, your wishlist and your shopping cart.

Apart from the privacy concerns, the biggest threat that you need to protect yourself from, with a security breach like this is that it opens you up to Social Engineering Attacks where anyone with this privileged information can pretend to be from Myntra.com and use it for malicious purposes.

While a lot of people reading this will focus on Myntra, I think it's important to focus on what this incident can teach us about the lack of Responsible Disclosure processes among Indian companies.

If you run an online service (and especially an ecommerce one) you MUST have a responsible disclosure process in place. The Open Web Application Security Project (OWASP) has a good primer on managing your security issue disclosure process. At a very basic level you should atleast have a security@ email address configured. Having a dedicated page for responsible disclosure on your website is an added bonus.

Here are some examples of good responsible disclosure pages to get you started:



Lastly, I think it's important for companies to be transparent and honest about security/data breaches. Hiding details about breaches from your customers makes them vulnerable to all kinds of attacks. Security/Data breaches happen all the time. The only way customers can protect themselves is by being informed.