Skip to main content

Redirecting to Protocol Handlers

April 10, 2015

On a recent client engagement (names/URLs changed to protect the innocent), we were given a web service that handles click tracking for high volume content (think: marketing emails and social advertisements).  This is certainly not new technology, but this click tracking service presented interesting behavior with URL protocol handlers.

Essentially, an html snippet full of marketing collateral would be presented to a customer, and any links on the page would be masked with the click tracker, similar to this:

<a href="">

Typically, since this is otherwise ripe for unvalidated URL redirects, trackers will implement this with the destination obfuscated or encrypted: 

<a href="">

However, this service left the destination visible in the URL, which means an attacker can directly manipulate the destination parameter.  First step, of course, is to see if the service allows redirects to any domain of our choosing.  On the example above, the service would present a 302 (object moved) response to redirect to the destination URL.  However, trying to inject "" into the destination parameter resulted in a 404 (not found) response.  After enumerating through the client’s domains, it became obvious that the service is clearly whitelisting the destination domains, as it should.

So the next step is to play with URL parser to see how well it can handle certain other scenarios.  We tried:

This is attempting to exploit the optional username:password@domain format that HTTP and HTTPS support.  Again, this is not a new technique and the service properly parsed the URL, resulting in a 404 if the domain didn’t belong to the client.

Next up, we decided to play with the protocol handlers. Immediately, we noticed the service would properly redirect to Even though most modern browsers will support FTP, this is boring since there just isn’t that much you can do with this besides redirecting a victim to a company’s FTP server (specifying the credentials, no less) using the company’s own click tracking service.  It’s possible you could put malicious content on the company’s FTP server, but then you could just direct people straight to the FTP server using an FTP:// protocol handler.  The only reason to launder the URL through the click tracking service would be if your victim cannot directly click on FTP:// links (e.g. if their email filter strips them) or if they’ve been taught not to.

But this is 2015 and everything is mobile-friendly these days, so lots of mobile apps like to register their own URL schemes and protocol handlers on the mobile device’s OS. 

So, the next step was to apply some of these to see if they’d get through the click tracking service’s filters.  First up:

<a href=">

This one bypassed the click trackers just fine, but besides the 1982 Tommy Tutone reference, this was fairly boring since it prompts you to call (Note: screenshots below are only the protocol handlers for the privacy of our client’s click tracking service):

Protocol Handlers 1
If you touch the call button on iOS, the call attempts to complete, but fails since the number is not well-formed:

Protocol Handlers 2
Sending an SMS message was similar, but it didn’t prompt to hit a button, which benefits the attacker:

Protocol Handlers 3
Unfortunately, the click tracking service wanted sms:// and did not like sms: (without the slashes) so the experience was less than perfect as well (besides the victim would have to type out their own message and hit “send”):

Protocol Handlers 4
Some of the more specific apps get much more interesting.  How about laundering a link to the LinkedIn app through the click tracking service?

Protocol Handlers 5
Which of course will launch the LinkedIn app and point to the profile page:

Protocol Handlers 6
Or how about getting the victim to open up the local movie listings in the IMDB app?

Protocol Handlers 7
Which breezed through the click tracking feature nicely:

Protocol Handlers 8
Or any of the myriad of Facebook URLs which could be finessed to pass through the click tracking filters:

  • fb://
  • fb://
  • fb://
  • fb://
  • fb://
  • fb://
  • fb://
  • fb://
  • fb://
  • fb://
  • fb://
  • fb://
  • fb://
  • fb://
  • fb://

At a minimum, this is a potential mobile app “rickrolling” attack vector.  This may also allow for attacks against potential flaws in mobile applications, since the body of the URL scheme may be used to pass data into the mobile app.  For example:

<a href=">

If a mobile app is vulnerable to injection flaws through its URL parser, this may be a simple way to attack that app while laundering the delivery of the attack through a trusted domain (“” in this case).  The victim user may see this as a targeted marketing campaign, click the link, the click tracking service would then issue a 302 redirect to the mobile app’s URL scheme, and the malicious payload would be delivered to the mobile app.

So, while it’s important to validate domains on URL redirects against a whitelist, it’s equally important to validate the protocol handlers, or else your redirect may become complicit in an attack against mobile apps.

Related Blogs

May 10, 2018

Observations on Smoke Tests – Part 3

While attending one of our technology partner’s security training courses, the instructor presented on their product’s various features and capabiliti...

See Details

May 03, 2018

Getting Started with Postman for API Security Testing: Part 1

Postman is a useful tool used by many developers to document, test and interact with Application Programming Interfaces (APIs). With the ubiquity of A...

See Details

September 25, 2014

"Shellshock" Vulnerability in Bash Allows Unauthorized, Remote Code Execution

On September 24, a critical vulnerability - CVE-2014-6271 - was made public. This vulnerability, dubbed “Shellshock,” exposes a weakness in which cert...

See Details

How Can We Help?

Let us know what you need, and we will have an Optiv professional contact you shortly.

Privacy Policy

Stay in the Know

For all the latest cybersecurity and Optiv news, subscribe to our blog and connect with us on Social.


Join our Email List

We take your privacy seriously and promise never to share your email with anyone.

Stay Connected

Find cyber security Events in your area.