• Posted by Sergei Frankoff 12 Mar

Safari To App Store Redirect From Ad On iOS 8.2

So back when iOS 8 beta 2 was released there was a lot of hype over the fact that Apple had finally blocked automatic redirects to the App Store from ads in Safari . So much hype, in fact, that noted security-talking-head Dan Kaminsky decided to offer up a $5,000 bounty for a bypass.

Now that iOS 8 is well out of beta and on version 8.2 it is not clear if this feature even made it into the full release. We couldn’t find anything in the release notes but there do seem to be less annoying redirects… less, not none. Maybe this is a result of some new restrictions in Safari on calling the app store via the “itmss” (or “itms-appss”) handler from inside an iframe or maybe it’s just ad-exchanges restricting these types of calls in the creatives (ads) they distribute. Either way there seem to have been some controls introduced to manage this problem.

Here at Sentrant we are continuously monitoring ad delivery as part of our real-time fraud detection platform. In addition to deterministic fraud detection signatures we also have the capability of deploying behavioural correlation signatures. We generally use the behavioural signatures when we want to research an emerging trend in ad-fraud as they have the added benefit of recording the full end-to-end ad transaction. Recently we were researching an (unrelated) case of mobile app fraud where one of the behaviours we wanted to identify was the infamous automatic App Store redirect. We developed a proof of concept (POC) of how we would implement the redirect (based on iframe busting) and then developed a behaviour signature based on the POC. Within a short period of deploying our signature, we detected the following automatic redirect.

We dug into the data and quickly identified the culprit; we were even lucky enough to be able to re-target an iPad, visit the site that was serving the ads, and capture the whole thing on video.While this is not ad-fraud, it is an interesting example of advertisers circumventing ad controls and we think it is useful to expose how this was accomplished. The details of how the ad eventually delivered the App Store redirect are complicated and obscure how the redirect was accomplished. In order to clarify, we have pulled out the relevant parts and described them below. If you are interested in the full details of the redirect we observed in the wild please contact us and we will be happy to share.

Components of the Redirect

Protocol handler for itmss (or “itms-appss”)

The itmss:// protocol is used to indicate the protocol handler required in the iTunes app. What this means is when Safari encounters a link with the protocol itmss:// it knows to open the link using the iTunes app (this also redirects to the App Store on iOS). Traditionally if you wanted to add a link on your website that would take the user to your app in the App Store you could use this protocol. Unfortunately since Safari automatically loaded these links in the App Store and there were no iframe restrictions on the protocol, advertisers began adding these links into their ads so when the ad loaded in Safari (on iOS) the user would be automatically redirected to the App Store. The itms-appss:// protocol operates in a similar way, the distinctions between these protocols are not relevant for this article. By restricting the use of these protocols inside an iframe, either with Safari or at the ad-exchange, this frustrating experience can be minimized.

Loading itmss Protocol From Iframe (Frame Busting)

Now that we know a way to get the itmss protocol handler instantiated and redirect the user to the App Store, we just need a way to do this from within an iframe (ads are loaded in iframes). Instead of trying to load the protocol inside the iframe let’s try loading it from the parent window.

The javascript window.top.location is a well understood way to “pop” out of an iframe and redirect the top parent window; this is akin to a javascript redirect executing on the page that has loaded the iframe. This is commonly known as “frame busting” and there is a good post on stack exchange describing it. This so well understood that some advertising platforms blacklist calls like these.

Redirect Delivery Chain

When we load the Slate.com page there is an iframe at the top of the page that loads an ad for a Zynga app called “Wizard of Oz Slots Free Casino”.

MjSUkauY0EiDHJrqSc5p (2)

Ad Responsible for Redirect

As the ad is loading in the iframe the following sequence occurs; Slate.com loads an iframe from AppNexus.


The AppNexus iframe loads a second iframe from Clove Network:


The Clove Network iframe loads the following html document:

        <META HTTP-EQUIV="EXPIRES" CONTENT="Mon, 22 Jul 2002 11:12:01 GMT">
        <meta name="ROBOTS" content="NOINDEX" />
        <meta name="ROBOTS" content="NOFOLLOW" />
        <meta name="ROBOTS" content="NOARCHIVE" />
        <meta name="ROBOTS" content="NOSNIPPET" />
        <meta name="ROBOTS" content="NOODP " />
        <script type='text/javascript'>
        setTimeout(function(){window.top.location ="http://ads.glispa.com/sw/87377/CD35861/2659___511794___CA";}, 5000);
        <meta http-equiv="content-type" content="text/html; charset=UTF-8">
        <!-- Start of StatCounter Code for Default Guide -->
<script type="text/javascript">
var sc_project=10073324; 
var sc_invisible=1; 
var sc_security="cb6381ba"; 
var sc_https=1; 
var sc_remove_link=1; 
var scJsHost = (("https:" == document.location.protocol) ?
"https://secure." : "http://www.");
document.write("<sc"+"ript type='text/javascript' src='" +

<noscript><div class="statcounter"><img class="statcounter"
alt="create counter"></div></noscript>

<!-- End of StatCounter Code for Default Guide -->        <style> #banner {position: absolute;left: 0px;top: 0px;}</style>
        <title>_Ads Platform v0.3</title>
      <div class='ZZC21_'><a id='lwVAIo8N' href='http://ads.glispa.com/sw/87377/CD35861/2659___511794___CA' target='_blank'><img src='http://s3.amazonaws.com/cpmobilead/MjSUkauY0EiDHJrqSc5p.jpg'></a></div>    

In the document loaded in the Clove network iframe, we can see the frame busting javascript window.top.location call to the URL http://ads.glispa.com/sw/87377/CD35861/2659___511794___CA.  This will redirect the Slate.com page to the URL.

The ads.glispa.com URL follows a series of 302 redirects (not shown here) and finally redirects to itms-appss://itunes.apple.com/app/wizard-of-oz-slots-free-casino/id916869395 using the protocol handler for iTunes which will automatically open the App Store and display the Zynga app (id916869395).

Summing it All Up

It is a novel effort on Apple’s part and the ad-exchanges to try and put an end to this unpleasant experience but given the nature of the problem this is going to continue to be a cat-and-mouse game where advertisers find new ways to circumvent the restrictions. This particular redirect is currently being used in the wild by Zynga to redirect users to their apps in the App Store from their ads.

As mentioned above one of the publishers hosting this ad is Slate and the exchange that is serving this ad is hosted on the AppNexus platform. The advertisers involved in the redirect are Clove Network who host the frame buster javascript, and Glispa who host the redirect to the itms-appss protocol handler with the link to the Zynga app.

Because this redirect just takes advantage of standard functionality in iOS (protocol handler) and javascript (frame buster) we are not sure this is technically even a bug, however we have contacted both AppNexus and Apple and alerted them of the issue.

We notified AppNexus and they have pulled the offending ad and are looking into permanently preventing this.