5

I have a mobile app (iOS) that sends server requests with GET variables in the URL.

Now All the requests are SSL secured, meaning we only use HTTPS for all the requests.

Now it's not in a browser so there isn't a history and no one actually sees the URL, and we Disable all access to the server logs on the server (those 2 facts differ this question from all other similar questions).

With that said, is it safe to presume that the GET variables passed are secured and can't be hacked by a 'Man in the Middle' attack?

Iddo Gino
  • 342
  • 2
  • 11

3 Answers3

5

Strictly speaking, a "man in the middle" attack could still be executed. The big question is whether or not it would be transparent to the end user or not.

A man in the middle could still hijack the initial SSL handshake and return its own SSL certificate. The certificate could be for the correct domain name, etc., but the distinguishing feature would be that it would (hopefully) not be signed by a trusted source, i.e. a Certificate Authority (CA). If your application recognizes this and stops communication, then you would be OK. If, on the other hand, your application does not check for authenticity by a trusted CA then you would negotiate a session with the hacker who could then see your traffic, inspect it, and subsequently send it along to the real server for processing. All responses from the real server would also be visible to the hacker.

If the hacker is somehow able to sign their fraudulent certificate with a trusted CA's key, then there's no stopping them. This is rare, but CAs can be compromised.

In the case of a web browser, such an attack would present the user with the "Stop, something fishy is going on" message that has become much more obvious in later browser versions. Still, the end user could plow ahead and accept the non-trusted certificate, effectively allowing the hacker to eavesdrop. If you application (or iOS itself) allows this, there's little you can do other than educate the user as much as possible.

In summary, if your application negotiates an SSL channel with the target server and ensures that the certificate returned is signed by a trusted authority (and doesn't ask the user), then you should be OK. All HTTP traffic, including the GET/POST verb and headers afterward, will be encrypted. Two more words of warning are warranted.

  • This is why the device (iOS in this case) must be very careful to protect its trusted authorities file ("root CAs")
  • You need to be using a secure cipher for the underlying communication. For non-critical data (i.e. not personal information), RC4 is probably fine and potentially faster. For anything personal (i.e. banking), go with the strongest you can. I'd recommend AES-256 if it's not the default.
hall.stephenk
  • 1,175
  • 7
  • 10
1

SSL provides an encrypted channel for your requests to travel in however as you are aware once the request reaches its destination the plain text variables will be logged by your access logs.

If the information you are sending is in any ways sensitive then you should be using a POST. This will prevent variables being logged by the web server. It will also prevent your secured requests from being called from other domains (same origin policy) if thats something which concerns you

cdugga
  • 3,849
  • 17
  • 81
  • 127
0

Don't forget that your request may pass through a proxy and those also log messages.

user1864034
  • 74
  • 2