0

My main question is how to detect the application termination by the end user when it was in the background (Suspended) to be able to send logout request to the server ?

We already have a timeout interval in the server to kill the session, but assume that the interval is 5 minutes so this means that the session will be alive for 5 minutes after the user terminated the app and anyone can sniff on the data and reuse it.

Notes:

  • We use HTTPS connection and SSL Certificate Pining.

  • We also implemented a heartbeat web service to be called by client app every fixed interval to tell the server to keep the session alive for this interval, if this web service didn't call for specific session, the server will kill this session.

Mohamed Amer
  • 429
  • 1
  • 4
  • 18
  • what sniffing and reuse are you imagining, and how is this mitigated by logging the user out immediately when the app is terminated ? – Wain May 31 '16 at 11:02
  • If i send logout to the server, the server will kill this session and no one else can use it. unlike if the user didn't logout before closing the app, the session will be alive and anyone can catch the request/response on the network and reuse this session id. – Mohamed Amer May 31 '16 at 11:43
  • 'anyone can catch the request/response' - how? you said you're using HTTPS and pinning, so what attach vector are you trying to protect against with the logout? – Wain May 31 '16 at 11:57
  • There are many bypass ways for HTTPS and SSL Pinning like:http://blog.dewhurstsecurity.com/2015/11/10/mobile-security-certificate-pining.html – Mohamed Amer May 31 '16 at 12:01
  • that is far from the capability of `anyone`, it's also about disabling that protection on your own device, not snooping the details of someone else's device... – Wain May 31 '16 at 12:04
  • Yes you are right that bypassing the HTTPS and SSL not easy for everyone but it possible. Also there are many bypass ways by sniffing the request/response not only the one i mentioned. – Mohamed Amer May 31 '16 at 12:11
  • are you working on a banking app, or subject to banking levels of security? if not then you're doing a lot more work than could be required, and if you are you should realise that anyone who downloads your app can reverse engineer it and work around any protections you add given enough time... – Wain May 31 '16 at 13:03

2 Answers2

1

Once your app is suspended you don't get any further notice before you are terminated. There is no way to do what you want.

Plus, the user could suspend your app to do something else (like play a game) and then not go back to your app for DAYS.

If you want to log out when the user leaves your app, do it on the willBeSuspended message. Ask for more background time and send a logout right then and there.

Duncan C
  • 128,072
  • 22
  • 173
  • 272
  • I don't want to logout once the app went the background. – Mohamed Amer May 31 '16 at 11:46
  • 1
    There is no way to know that your app is terminated once it's suspended. The system does not give you any additional notice when you're terminated from the suspended state, so you can't do what you're asking. – Duncan C May 31 '16 at 13:12
1

Mohamed Amer,

Here is an approach used by Quickblox Server and I feel its pretty much solid though it involves a little overhead.

Once the client application (either iOS android) establishes the session with quickblox server, quickblox server expects the client application to send the presence information to server after a regular interval continuously.

Sending the presense information is pretty much simple. They have written a api which we keep hitting after a interval of 5 mins with session id that we have. They validate the session id and once found valid they will extend the expiration time for the user ascociated with that id for 5 mins more.

What they will do I believe is that,

Approach 1 : they maintain the last hit time and for all the subsequesnt request they check if the request time is within the the time frame of 5 min if yes simply process it. If the request comes after 5 min they will delete the session id for the user and respond saying you have timeout the session.

Approach 2 : Because they provide online and offline info as well they cant simply depend on the incoming request to delete the session id from server so they probably create a background thread which swipes over the db to find the entry with last hit time greater then 5 min and removes it from DB. and declares the user session expired.

Though this involves client apps continously hitting the server and increases the burden on the server for the app like chat application in which presense information is so vital this overhead is still fine i believe.

Hope I have provided you with some idea at least :)

Sandeep Bhandari
  • 19,999
  • 5
  • 45
  • 78
  • We already have this approach also (i forgotten to mention it :( ). we have a web service called every for example 5 minutes to tell the server to keep this session id alive for another 5 minutes. But the problem here is when the user close the app and someone got this session id he can use it and also he call this web service to tell the server to keep this session id alive. – Mohamed Amer May 31 '16 at 11:53
  • @mohamed-amer : How can anybody get the session id ???? You mean your sessionID is plain random text and might be same for someother person ??? Then you should deal with your session id generator. SessionId should be unique for each user no matter whether app is in foreground or background on the otherhand if you are concerned someone else hacks or gets the sessionId of somebody who is logged in this issue exists in every system but hacking and getting somebody's session ID is not that easy either isnt it :) – Sandeep Bhandari May 31 '16 at 13:29