Am I leaking my secret internal company URLs?

December 16 2015

Probably, but you can make it stop.

Something that I notice every now and then is that Google Analytics is downright creepy. This isn’t about GA though, the mechanism by which these leaks happen is simple and obvious: the Referrer header.

Collaboration has moved online. Just review a semi-popular Github repo’s traffic data, or Google Analytics data from a product website, or access logs with the right logging format, we reveal the location of various corporate resources that aren’t publically known:

  • Collaboration portals, both well-known (Slack, Jira, Confluence) and bespoke solutions
    • also topic and channel names and descriptions[1]
  • Support agent backends
    • also ticket IDs, ticket titles[1]
  • Internal documentation[1]
  • Build systems (this one gave me a chuckle).

Big deal, they’re authenticated …

That’s fair, but it does not make the location info useless. For one, some common internal packages suffer from chronic unauthenticated RCE (cheap shot alert).

IP (network) controls would probably be an effective mitigation for direct attacks, both because they conceal what the target website is running (unless the leaked URL reveals that info), and then also creates a requirement for an unrelated XSS for an indirect attack.

However, even despite network controls, your internal customers are vulnerable to social engineering attacks. Knowledge of [the existence of] an ostensibly secret system would very likely be an effective persuasion tool in a phishing email or phone call to the sysadmin.

So, given the choice, you’d rather the location info remained secret, right?

How to make it stop

It would be great if we could tell the browser to zark off and not send a Referrer, right? Good news everyone! Behold, the (correctly spelt): Referrer policy.

The gist of the draft is that the webpage author may choose to include a meta tag (or send a CSP header) that indicates to the browser what policy it would prefer for the Referer header for outgoing requests and navigations.

The options are None, None When Downgrade, Origin Only, Origin When Cross-Origin and Unsafe URL. You can read about them here, but you’ll probably be safe choosing None/never.

Does it even work?

Not in Internet Explorer or old Android. So, to some extent you would still need to focus on endpoint security to prevent use of these browsers, to be totally effective.

<My collaboration tool> isn’t going to implement this ..

My thorough testing (in one version of Firefox) leads me conclude that you can alter the Referrer Policy after the page has loaded (uhhhh….) with a little JS:

$('head').append('<meta name="referrer" content="never">'); // worksforme

Hopefully your theming system allows for arbitrary JS inclusion.

1. A corollary to this entire post, is that it is very potentially not a great idea to encode a bunch of sensitive information in URLs, despite the SEO benefit to your internal secret portal.