I have authorization in my app that happens through POST-request to the server. In response I receive json file and cookie.
I want prevent user to enter credentials every time. So the question is how to store cookies (session only cookie) between app launches. I concern here 3 cases:
User pressed "Home" and returned to the app before app was terminated by iOS
User pressed "Home" and returned to the app after app was terminated by iOS
User forced quit from app by swiping-out it from multitasking
It seems that i can use something like this:
NSHTTPCookieStorage.sharedHTTPCookieStorage().cookiesForURL(NSURL(string: "url")!)
But is it secure and will it persist in case 2 and case 3?
I've been working on similar iOS issues for the past few weeks.
Depending upon just how secure the credentials need to be, I'd suggest looking into using the browser's localStorage functionality to resolve this, rather than using cookies.
localStorage and sessionStorage are far easier to manipulate than cookies, and cross domain protections help avoid both user manipulation and 3rd party attempts.
If one was dealing with almost any other browser, one would generally use sessionStorage, since the values are preserved per log on session. But, iOS on mobile devices wil purge session storage far too frequently, rendering it useless.
The danger of using localStorage is that values persist between browser sessions. Where this becomes an issue is if a legit user logs in from a 3rd party device, the credentials are retained on that device unless the user has a way purging them (which is easy to accomplish using javascript).
The advantages of using sessionStorage and localStorage are:
1. ease of manipulation compared to cookies
2. no need to keep posting back cookies values to the server
3. less server overhead
note that on iOS in particular, if Private Browsing is enabled, both session and local storage are disabled.
Related
My app was recently rejected for App Store release with the following reason:
We noticed your app accesses web content you own where you collect cookies. Cookies may be used to track users, but you do not use App Tracking Transparency to request the user's permission before collecting data used to track.
The last part is correct: I do not apply App Tracking Transparency.
The first part is surprising:
I do not explicitly access cookies by HTTPCookieStorage
I show a terms-of-use webpage which is included in the app. It does not access any cookies. It has links to external sites that do, but I only navigate to these by switching to safari (using UIApplication.shared.open(...))
So: How do I figure out how/when cookies are accessed by my app, which makes apple require App Tracking Transparency?
I ended up asking Apple about the haps, and the reply stated the following:
we still find that your app indicates the collection of cookies on launch
After a bit back-and-forth, I removed some text in the bundled terms-of-use webpage - something copy-pasted from the website supporting the app, that indeed indicated collection of cookies... Completely irrelevant for the app.
That did the trick, and the app is approved.
I am having a problem tracking conversions on Apple devices. This is the simplified scenario:
After login. User lands on page 1, behind the scenes, we push-piece of information into local storage specifying the original subscription date.
A GTM variable is created to hold this value, and when the conversion happens we push the variable value (subscription date) into the custom GA dimension ( to understand conversion velocity ).
This works fine on other devices except on Apple (data is missing). Is there any other way to persist piece of data from page to page on apple devices besides cookies and (or) local storage?
Well, it would be best to debug the issue properly. Actually reproduce the misbehavior of apple devices. And narrow down the problem. Also, figure out if this behavior depends on a device or on Safari. It's likely that it's about the browser rather than device.
It may be connected to nuances of local/session storage management in Safari. I would suggest trying a different kind of client-side storage.
It may also be connected to Apple's old PR stunt with their ITP efforts: https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/
We normally solve this issue with a backend mirror that resets cookies that we need to be persistent. That way, cookies become first-party and the ITP limitations are relaxed. There's nuance to this approach, however. For example, having it universally resetting any cookie may be a security issue, so cookie names and their values should be validated on that backend mirror.
If you have to go this far to fix the issue, you may as well consider starting using the server-side GTM container altogether.
I'm currently hard at work developing my first Web application, and I have stumbled hard upon an issue on the iOS mobile-devices' Safari Browser.
If I create a cookie set to expire in x days (basically any cookie created, session-only or otherwise), and hard-reset the browser on the phone (as in closing the app entirely or restarting the phone), the cookie is destroyed.
Why is that? And how can I avoid it?
The same thing happens with objects stored in LocalStorage.
Also, if it can not be avoided, what other way of storing my app-data should I use? Server-side storage is last resort here.
The phone settings have been checked, nothing indicates that the browser is rejecting- or is set to clear cookies on session/app exit.
As Shivan Raptor said, important data should be stored server-side.
After some fiddling, I also found that localStorage apparently survives app hard-reset, whereas cookies do not.
Closing.
I have the following issue:
I've understood how to create a secure login between an iPhone app and a WebServer (SSL,Https).
My question is after creating the session token, how do I make sure that if a hacker intercepts it, in the subsequent POST requests I receive data from the same user?
I ask this because I would have to send the session token each time a request is made right? (to be able to identify the user).
I want to prevent multiple things:
Session hijacking where someone would sniff the users token and send data instead of him (like a highscore or something)
Data injection using data that would not be normally sent from my app like a 1.000.000.000 highscore (possible score but not easily attainable).
I have been looking at:
UDID
User Agent (if it's not from the app name of my app it's not good, the hacker would actually have to guess I do this check or download my php files somehow right?)
The app is from the AppStore. If the request comes from an app that hasn't been approved by Apple it's not ok. I'm not actually sure if you can test this or not. If this works a hacker would have to actually submit an AppStore and download it to insert faulty data into my database which I hope nobody has time for.
The MAC address. Not sure if allowed by Apple. The IP doesn't work because a valid user might change IP's.
Cookies from what I've seen can be easily traced and see what data is inside them.
Maybe I'm not asking the right question here so it could actually be how can I make sure the data I receive is from the correct user and the correct application?
The purpose of SSL around your POST requests is to prevent interception by a third-party in transit. If a hacker can get to it, it means the token was either leaked on the client (rooted device), server (insecure application logging/debugging) or they broke SSL. (unlikely)
You could perform some advanced checking by capturing device UDID (apple doesn't like this) or comparing to source IP, but it is going to be a lot of effort for questionable security improvement.
Just ensure everything sensitive is in SSL and you should be ok.
As I understand it, if I have code that creates a cookie without an explicit expiry time, it lasts for the duration of the browsing session (e.g. until the user closes their browser).
How does this apply to mobile devices, specifically iOS, where you never really quit Safari?
Cookies in Safari on the iPhone are stored in a property list file.
They stay there until the user manually clears their cookies on their device.
As I understand it, if I have code that creates a cookie without an explicit expiry time, it lasts for the duration of the browsing session (e.g. until the user closes their browser).