I tested Universal Links in iOS by turning on Airplane mode and saw that the correct application was opened (instead of a website)
This indicates some level of "caching" the apple-app-site-association.
I want to determine the extent to which this is cached, so I can determine
What UX edge cases are there (e.g. Offline for x days)
What security considerations are there (e.g. MITM / SSLStrip + .well-known/URL)
etc.
Ideally I would like to have details if additional logic is employed (conditional caching if HTTPS employed, DNSSec, etc)
The exact behavior here is (intentionally?) unclear from Apple. Here is my personal experience, gleaned partly from official documentation and partly from helping thousands of apps implement Universal Links at Branch.io.
The apple-app-site-association file is cached once when the app is first installed.
If this initial scrape fails, in almost all situations it will not be reattempted. The only exception to this is if the initial return is a 5xx error, in which case a limited number of retries may occur. This is not well-documented, and is not covered in Universal Links documentation at all. You can find a mention in the Shared Web Credentials docs.
The file is not checked at all when a Universal Link is opened. This is why you are able to get Universal Links behavior in airplane mode.
The file does not expire. Once it is cached, it sticks permanently for as long as the app is installed.
The file will be re-checked when installing an app update.
The file must be accessible via a valid SSL connection at either https://example.com/apple-app-site-association or https://example.com/.well-known/apple-app-site-association. If there are redirects of any kind, this will fail.
It is theoretically possible to MITM the request if you are able to install a new SSL certificate directly on the device in question. Charles Proxy for example uses this approach for debugging. I have never seen or heard of this being exploited, and the damage would be quite limited because the domain still has to be specified inside the app itself.
I found a way to get around the caching issue. The cache is bound to the domain name, so for every time you want iOS to request apple-app-site-association you can create a new subdomain, and configure iOS to use that subdomain as the universal link for your app.
Extremely hacky, but it is the only workaround that worked for me.
Related
I am working on mobile pentests currently. At first, using my home network I was able to intercept traffic on burpsuite for both iOS and Android versions of “Test App”. Then the next day, I still am able to intercept traffic but the behaviour of this “Test App” for both iOS and Android seem like it has certificate pinning as I was just stuck on the pre-auth page and getting errors when trying to log in. Without proxy though I am still able to login OK and proceed with the app normally so I don’t think my home network got blacklisted? (For context, the binaries does not have any certificate pinning).
But when I tried to change my network to my mobile hotspot, I could intercept the traffic and app behaves normally again.
Anyone encountered the same previously? Any ideas on what could be causing this? Thanks
This does seem odd. I would wager one of three things is happening here:
You accidentally left "Intercept" on in Burp Suite Proxy. This holds the response in Burp Suite until you click Forward, which would cause behavior very similar to what you are describing here. I have done this more times than I am willing to admit.
There was a temporary outage in the application's API. Not unheard of, especially if this is an unreleased app.
There is some sort of issue on your home network, but this is unlikely. Maybe two devices have the same static IP address?
It's hard to say exactly what the issue might be based on the information you provided, but hopefully this was helpful, or at least gives you a place to start!
There are lots of docs about ServiceWorkers, but a very important question remains unanswered:
If my app uses a ServiceWorker, does all data get proxied through Google (or, for non-Chrome, another browser vendor)
If so, what are the privacy implications and mitigations? True, it may be encrypted, but it lets the browser vendor track every time someone uses the app, installs it, etc.
Is there any way to use ServiceWorker without proxying through Google? A privacy mode?
Where is this documented? And why is it kept so secret? It's a major privacy issue and should be made very clear.
No, Service Worker does not send any data to Google or any other browser vendor. It also does not do anything by default or without you asking it to do something.
To put it another way, it does what you tell it to do. It runs code you've written just like the webpage.
I need to open my particular UIViewController when the following link is clicked on the Safari browser:
http://my.sampledomain.com/en/customer/account/resetpassword/?id=24&token=8fbf662617d14c10f4a11f716c1b2285
When this link is clicked on the browser, I need to open my application on a particular screen and retrieve the data from this url. For example:
id = 24
token = 8fbf662617d14c10f4a11f716c1b2285
...and pass it to that particular UIViewController.
How can i do that?
What you are describing is called Deep Linking. It's a very common app feature to implement — most apps have it — and conceptually, it seems like an easy thing to build. However, it's complicated to get right, and there are a lot of edge cases.
You basically need to accomplish two things:
If the app is installed: open the app and route users to the correct content inside it.
If the app is NOT installed: forward users to the App Store so they can download it. Ideally, also route users to the correct content inside the app after downloading (this is known as 'deferred deep linking').
While not required, you'll also probably want to track all of this activity so you can see what is working.
If the app is installed
Your existing custom URI scheme fits into this category. However, Apple has decided that custom URI schemes are not a good technology, and deprecated them with iOS 9 in favor of Universal Links.
Apple is right about this. Custom URI schemes have a number of problems, but these are the biggest:
There is no fallback if the app isn't installed. In fact, you get an error.
They often aren't recognized as links the user can click.
To work around these, it used to be possible to use a regular http:// link, and then insert a redirect on the destination page to forward the user to your custom URI scheme, thereby opening the app. If that redirect failed, you could then redirect users to the App Store instead, seamlessly. This is the part Apple broke in iOS 9 to drive adoption of Universal Links.
Universal Links are a better user experience, because they are http:// links by default and avoid nasty errors. However, they are hard to set up and still don't work everywhere.
To ensure your users end up inside the app when they have it installed, you need to support both Universal Links and a custom URI scheme, and even then there are a lot of edge cases like Facebook and Twitter which require special handling.
If the app is NOT installed
In this case, the user will end up on your http:// fallback URL. At this point, you have two options:
Immediately forward the user directly to the App Store.
Send the user to your mobile website (and then use something like a smart banner to give them the option of going to the App Store).
Most large brands prefer the second option. Smaller apps often go with the first approach, especially if they don't have a website.
To forward the user to the App Store, you can use a Javascript redirect like this:
<script type="text/javascript">
window.onload = function() {
window.location = "https://itunes.apple.com/app/id1121012049";
};
</script>
Until recently, it was possible to use a HTTP redirect for better speed, but Apple changed some behavior in Safari with iOS 10.3, so this no longer works as well.
Deferred deep linking
Unfortunately there's no native way to accomplish this last piece on either iOS or Android. To make this work, you need a remote server to close the loop. You can build this yourself, but you really shouldn't for a lot of reasons, not the least of which being you have more important things to do.
Bottom line
Deep linking is very complicated. Most apps today don't attempt to set it up by building an in-house system. Free hosted deep link services like Branch.io (full disclosure: they're so awesome I work with them) and Firebase Dynamic Links can handle all of this for you, and ensure you are always up to date with the latest standards and edge cases.
See here for a video overview an employee at Branch made of everything you need to know about this.
The use case is, essentially, this:
the user create some content and uploads it to our server.
our server responds with the URL.
the user sends the URL (eg via text message) to another user.
the other user clicks on the URL. If they have the app installed, they should be taken to the content in the app. If they don't have it, they should still be able to view the content on our site (eg in safari).
This is easy enough, and we have that working, except our URLs are long and we'd like to use shortened URLs. With shortened URLs, the problem is it always opens in Safari, instead of the app, unless we setup a custom domain. (This is described in many places, including here: iOS Universal Links and URL Shorteners).
The docs for google URL shortener indicate that they have overcome this somehow:
Even though App Indexing for iOS is available only in limited release, you can still enable iOS app deep links with goo.gl by implementing App Indexing for iOS. While these deep links may not begin appearing in Search results, they will start working with goo.gl links.
So I installed the app indexing for iOS into our app on a test device and ran it. Then I created a short link but it still opens in my browser, not my app.
Does this really work as advertised? Do I have to wait longer? Install the indexer on more apps? Will a created link open in the app right away, or does the content have to be indexed?
...Or am I missing something else?
Related:
Google app indexing for iOS and universal links
UPDATE:
The only way I can see this actually working without a custom domain is if Google added every app they indexed to their apple site association file. All I see is google apps there, so obviously that's not the case.
Stack overflow won't let me link it because it thinks it's a link shortener, but it's close to this:
https://goo. gl/apple-app-site-association
You are exactly right: for this to work, Google would need to add your app to their apple-app-site-association file. Unfortunately that would be impossible even if Google wanted to do so, because Apple puts a size limit of 128 kb on that file.
Integrating the App Indexing SDK was a good thought, but doesn't solve this issue either.
What you need is a (free) service like Branch.io (full disclosure: I'm on the Branch team). This is specifically designed for exactly what you're trying to accomplish, and takes care of all the housekeeping tasks you are running into. You'll be able to create branded short URLs that take you to your app (if installed) or website fallback (if not installed), and the AASA file will be generated automatically for the short URL domain.
I have already researched and tested a lot this new feature of iOS 9, where the "Transport Security Policy" states that all HTTP requests would be blocked and only HTTPS would be allowed.
During my tests, I could download and render an image from an http ONLY link. After that, I put a http link to redirect the image's click and the TSP blocked my request.
Anyone has had this issue before?? What does the TSP actually block??
OBS.: I was NOT using a webview of any kind, before anyone asks...
Thanks!
In your Info.plist you can add a section that lists exceptions for the TSP. You can put http domains in that section. Hopefully that helps.
I haven't run into the exact issue you're describing.
TSP, officially referred to as App Transport Security (ATS), when enabled, forces you to use HTTPS.
Apple has a great documentation page, which gets into a lot of details about what would and wouldn't get blocked.
If you're asking in order to get around it, you can include an NSAppTransportSecurity dictionary in your Info.plist. In it you can have specific domains for which you'd like an exception (NSExceptionDomains) or turn the whole thing off (NSAllowsArbitraryLoads : YES). Note that the spirit of the latter is for an app that allows the user to specify the connection info, not exactly to work around security best practices.