Private bug trackers disclose data about bug reports to any website that publishes information about security vulnerabilities or other issues that affect the organization.
It’s easy to picture the scene. A new security vulnerability has been discovered. Everyone scrambles to fix it before anyone manages to exploit it and damage their reputation. Issue trackers are being filled up with requests from managers linking to news stories telling horrifying tales of a new security exploit. The organization is definitely vulnerable and the overtime-pay clock is ticking.
The Heartbleed bug was a named issue in the OpenSSL library that started a new trend for security disclosures: It had a domain name, website, and even a logo. All designed to attract more media attention to the quite severe security vulnerability. Other important security issues that have been disclosed since has since copied this approach including Dirty Cow, Shellshock, and Stagefright. CVE numbers are so last year.
So, what changes now that the people who disclose security issues now run their own websites? They can start to collect direct information from responsible organizations that are trying their best to keep up with the latest security news. The vulnerabilities website can be an important resource, and everyone involved clicks through to read up on the implications of the vulnerability. It’s not only the individual or organization that disclosed the vulnerability that gets this data. All the forums, blogs, and news websites that cover the disclosure also get their share of links in internal bug trackers.
By default, browsers will transmit a Referer (sic) header field containing the referring website’s address. Sharing this information is usually not a problem as the use of it’s usually limited to marketing, analytics, or vanity purposes. Due to legacy standards, the header is freely shared between HTTPS websites cross-origins, but browsers may unset it when clicking through from HTTPS to a HTTP website. Since more and more websites now use HTTPS by default, this standard behavior no longer — if it ever did — protects privacy.
The Referer header contains more information than just accessing a page from an IP address allocated to an organization. You can tell what company an IP belongs to, but you can’t know who is visiting and why. Small and medium organizations also don’t own their own allocated blocks, making it difficult to identify them through an IP address alone.
I’ve written about my local banks’ TLS implementations and number formatting with HTML5 inputs in the past. These two texts alone have let me collect the URLs to the bug tracker of every local and many international banks and payment processors who’ve referenced these issues in their private bug trackers. A fair amount of other articles, which often covers various specific technical problems, have also ended up being linked from private bug trackers.
Another example I see in my server logs are from various popular public discussion board software. These often allow users to exchange private messages between each other. The links to these messages will include the user IDs of both the sender and recipient. In a private discussion that contain links, the Referer header will include the forum identities of both participants in addition to their topic of conversation (obviously, the referred website or its topic.)
Web app developers can to some extent control what Referer headers are sent when users click-away from their pages. The Referrer Policy is a Candidate Recommendation from the World Wide Web Consortium (W3C) that introduces several mechanisms for instructing browsers on how much data they should include in the Referer header if any. It’s not widely supported by browsers yet, but adoption interest is promising.
I believe the default behavior of web browsers today is good as-is. There’s value in being able to track what other public discussions are taking place about the subject of a webpage. However, measures should be taken to ensure that private discussions — like private forums, chat rooms, webmail apps, and bug trackers — opt-out of this relation data sharing.
Application developers should consider whether headers should be sent from their environment. A good rule of thumb is that if any page that has limited private distribution and require authentication to access, should not send Referer headers. Developers need to define and inform browsers of their Referrer Policy. Technically, this i achieved either by adding a small piece of metadata to the page or individual links, or by appending an extra HTTP header.
In summary: Referrer headers are normally harmless, but should be disabled in any non-public context. The existence of a link stored in a bug tracker or exchanged by email under a corporate domain may be more information than you’re willing to share.