The only example that really comes to mind where actual secret information is sent over a URL like that is things like Dropbox OAuth tokens, which require the requesting app to have a URL scheme db-<app_key> that it uses to send the the token. But besides the fact that this isn't a new issue, it's hard to imagine this actually being a serious problem, because it's impossible for the malware app to hide the fact that it just intercepted the URL request. If I'm in some app and request access to Dropbox, it switches to the Dropbox app and asks for permission, and then switches to some other app, it's pretty obvious that other app is behaving badly. Especially since there's no way for that other app to then hand the token back to the original app, so you can't even man-in-the-middle and hope the user isn't paying attention.
It's less common with the major well-known applications, in part because almost all of those get some kind of security assessment done, and, like I said: this was for a long time the #1 action item on any mobile app assessment.
What you have to keep in mind is that for every major app you've heard of, there are 2000+ that you've never heard of but that are important to some niche of users.
Sure, I get that. I'm still just having a hard time imagining trying to exploit this, because it's impossible to hide that you did it from the user, and it completely breaks the app you're trying to take advantage of (since you took over its URL handler, it can never receive the expected information, so you can't even try to immediately pass the data to the real app and hope the user doesn't notice).
Assuming the model where you send a request to another app, which then sends the secret data (such as an OAuth token) back to you, it also seems rather trivial to defeat (if you're the app with the secret data). Just require the sending app synthesize a random binary string and send it to you, and use that as a one-time pad for the data. You know your URL handler is secure (because otherwise it can't have been invoked), and this way you know that even if some other app intercepts the reply, they can't understand it. Granted, this doesn't work for the model where you send secret data in your initial request to the other application, but I can't even think of any examples of apps that do that.
Why can't the "other app" just fake a Dropbox-looking display that says "Sorry, service unavailable. Click here to try again." while it does malicious stuff in the background? And then pass to the real Dropbox once it's finished being malicious?
1. You can't intercept the request to Dropbox itself, because that doesn't contain any secret data. You'd need to intercept the response, and you can't fake the UI for that app because it would be immediately apparent to even the most cursory inspection that your app is not in fact the app that made the request (even if you perfectly mirrored their UI, you wouldn't have any of their data so you couldn't replicate what their app is actually showing). And anyone who looks at the app switcher would see your app there so you can't possibly hide the fact that you launched at that time.
2. Even if you could be 100% convincing, you can't actually pass the data to the real app when you're done recording it because, by virtue of overriding their URL handler, you've made it impossible to invoke the real app's URL handler. There's no way on iOS to specify which app you're trying to open a URL in. All you can do is pass the URL to the system and it will open the app it thinks is correct. Since you overrode their URL handler, if you try and call it, you'll just be calling yourself again. And since you've now made their URL handler inaccessible, you've cut off the only possible way to pass that data to the real app (even if it has other URL handlers, they won't accept the same data).
So the end result is that if you do try and take over someone else's URL handler, it'll be blindingly obvious the moment you actually intercept a request.
The only approach that even seems semi-plausible would be attempting to phish the user by presenting a login UI as if you were Dropbox and hoping they enter their username/password, but the problem with that is the entire point of calling out to a separate app is that you're already logged-in to that app, so if the user is presented with a login form at all, they should instantly be suspicious. And of course as already mentioned you can't hide the fact that you intercepted the request, so you'll be caught the first time you ever do this.
On a related note, even if you can make a perfectly convincing UI, your launch image will still give you away as being the wrong app (since the user will see your launch image as the app is launched). Unless you make your launch image look like the app you're trying to pretend to be, but then you can't possibly pretend to be a legitimate app because the user has to actually install your app to begin with, which means they'll be looking at it. If they install some random app from the app store and it has a launch image that looks like, say, Dropbox, that's a dead giveaway that it's shady. There's not really any way to disguise an app like that.
