35

There are a lot of mobile apps nowadays with payment gateways support. However, unlike desktop browsers, these mobile apps do not show us an 'Address bar' by which we can identify a HTTPS connection. How can I make sure I am making a payment on a mobile app with a HTTPS connection?

Adarsh Konchady
  • 453
  • 4
  • 5
  • 3
    Mobile devices come with an official app store. Proper applications should direct you to the app store either directly in app or with an overlay to make purchases because the average person can reasonably expect these to be secure. If they don't do this, you absolutely shouldn't be putting do any purchases or put any personal information into them. –  Mar 14 '16 at 21:52
  • 4
    Using apps from reputable developers is the best you can do, or use the browser if possible. And no, your local bank *isn't* always a reputable developer, as I've personally saw a banking app which used HTTPS but failed to correctly verify the certificate, accepting any MITM's cert. – André Borie Mar 15 '16 at 00:00

4 Answers4

26

Unfortunately, unless you sniff and inspect your own traffic, you can not... My advice is not to use built-in browsers that do not indicate the protocol being used to handle sensitive information

Stef Heylen
  • 1,726
  • 1
  • 14
  • 16
  • 2
    By that argument, shouldn't you avoid native apps entirely since they don't show whether your data is encrypted in transit or not either? – Ajedi32 Mar 15 '16 at 18:49
  • 1
    @Ajedi32 I would say "Yes". There's Google Wallet and the Play store to handle those transactions. Why would an app setup it's own payment method? – Ismael Miguel Mar 15 '16 at 18:56
  • The problem is many apps do setup 3rd party payment gateways which we can never say for sure are authentic. – Adarsh Konchady Mar 16 '16 at 14:51
  • Plenty of things are sensitive other than payment info, too - like session data that would allow a MitM to assume your identity, a la firesheep. – Xiong Chiamiov Mar 30 '16 at 21:09
11

As @StefHeylen says, you can't, generally. And as @d1str0 says, Burp is one way to see if the traffic is encrypted, if you can proxy the app through it.

It's actually worse than that though - mobile apps don't always only make a single connection to a server. It's not uncommon for them to use HTTP for some parts, and HTTPS for others. They can also do some other tricks which normal browsers don't generally touch. For example, they can certificate pin and refuse to run if they can't make a secure connection to a specific server.

Therefore, it's perfectly possible to have mobile applications that refuse to run when proxied (because they connect to a specific HTTPS server with a specific certificate, which means Burp fails), but which then send payment data through unencrypted means to a different server. The only way to observe this is through packet inspection using something like Wireshark - you'll see a bunch of encrypted data, then some unencrypted data (often JSON or XML) being sent to a different server.

It's also possible for payment data to be sent correctly, then for third party scripts for statistics monitoring (seeing how far users get through forms within the app, for example) to send the same details over unencrypted channels because the app developer hasn't excluded payment fields.

The whole mobile application system is a mess - I'd second Stef's advice to avoid making payments using apps if possible. If you can't, consider using a specific card for those payments, which you monitor regularly for unusual transactions.

Matthew
  • 27,263
  • 7
  • 89
  • 101
6

Using a proxy tool like BurpSuite will allow you to test whether or not that specific app is allowing or disallowing bad HTTPS connections.

d1str0
  • 2,348
  • 14
  • 24
  • although this will be a definitive indiction, it is not a process for the lay-person – schroeder Mar 14 '16 at 16:55
  • 3
    @schroeder maybe someone should make an easy-to-use tool for this ? "CheckMyHTTPS: configure the proxy settings of your device to 1.2.3.4, open your app and we'll tell you if it's safe!" – André Borie Mar 15 '16 at 00:02
3

In iOS 9 HTTPS in apps is enabled for any network call. You can temporarily bypass it but it is soon to be only HTTPS for all network calls always.

Starting in iOS 9.0 and OS X v10.11, a new security feature called App Transport Security (ATS) is available to apps and is enabled by default. It improves the privacy and data integrity of connections between an app and web services by enforcing additional security requirements for HTTP-based networking requests. Specifically, with ATS enabled, HTTP connections must use HTTPS (RFC 2818). Attempts to connect using insecure HTTP fail. Furthermore, HTTPS requests must use best practices for secure communications.

NSAppTransportSecurity

lostAtSeaJoshua
  • 131
  • 3
  • 2
    Apps can still opt out from ATS and I guess more did opt out than turn to HTTPS when ATS was added in iOS9. Searching for ATS in StackOverflow will also show you how little knowledge some developers have about both HTTPS and ATS (For one thing, you can *partially* disable ATS but most disabled it completely). Apple does not enforce the use of ATS yet. – Thibault D. Mar 15 '16 at 12:04