Controlling the ‘referer’ header | Hacker News Reader

Controlling the ‘referer’ header

blog.fastmail.com

86 pointsnmjenkins30 comments

This article is about website owners. The best thing you can do as a user is enabling the 'Referer' for same-origin requests only. That way, you keep almost all the advantages of the 'Referer' but at the same time fix almost all the privacy issues.

In Firefox, you can do this by setting `network.http.referer.XOriginPolicy` to `1` in `about:config`. Or use a `user.js` file with other helpful privacy settings, e.g. https://github.com/delight-im/Secure-Firefox

Note to be sure to set to 1 (base domains match) and not to 2 (domains match). Otherwise you'll be blocked from many CDNs used by large domains (for example... example.com serves its images and static js from cdn.example.com). Many CDNs are configured to check the referrer to prevent hot-linking of images, javascript, etc.

Also note that setting it to 1 will still block you from loading CDN-served images and javascript for smaller sites that are not using their own custom subdomain for their 3rd party CDN service. So, a site using MaxCDN to serve their images and javascript from the default CDN-issued domain of zonename.companyname.netdna-cdn.com with "HTTP Referrer Whitelist" enabled for their example.com domain that you are visiting will block you from downloading images and static javascript hosted on the CDN.

You can also do this in Chrome although I'm not sure if the behavior is identical.

On chomre://flags search for reduced-referrer-granularity and enable it to get a similar effect. I believe it may only affect web sites that do not explicitly provide a referrer policy.

In Chrome I use Referer Control: https://chrome.google.com/webstore/detail/referer-control/hn...

This gives you the ability to whitelist websites, and also a lot of control over what kind of requests are blocked and what aren't. I have it set to block everything by default, and only a few websites cause problems.

Well I also use uMatrix which covers the cases where the built-in option does not. It can also be controlled on a per-site basis. I assume the functionality is pretty much the same.

This used to break virtually all paid webfont services and most likely it still does.

Also, if you use uMatrix, you can choose to spoof the referrer string of third-party requests. And you can optionally choose to allow referrers for certain domains:

referrer-spoof: * true

referrer-spoof: wsj.com false

This, for example, "allows" viewing of articles on wsj for google-referred links.

Similarly with Noscript.

The URL refresh thing can be done without JavaScript by having a little server side entrypoint that redirects to a destination URL with the same header.

I believe it should be widely supported.

If I understand you correctly you would still have a Referer header that said you came from fastmail.com, however it could be stripped of other sensitive information. So the URL would be something like "https://fastmail.com/redirect?u=https://example.com"

that was the first solution i thought of when i saw the article and i believe it to be quite common.

If you do that, though, you have to make sure you don't introduce an open redirect:

https://www.owasp.org/index.php/Open_redirect

It's not a huge issue, given the number of open redirects on the Internet, but it may put your site at risk of being used in phishing attacks.

I'm building a end to end encrypted chat platform in JS (I'm aware of the risks here it's a toy project) and I might have to use an open redirect to prevent urls from leaking out of messages before they are clicked. I was thinking of doing something like external-link.domain.io/redirect?url=https://www.google.com to make it obvious.

Yeah. The concept of an "untrusted" domain is commonly used for things like this.

IIRC Google uses googleusercontent.com

Sign them too

Facebook uses a method called LinkShim with a bit of JavaScript (to avoid garabling copy&pasted links) and a hash of the URL generated serverside to avoid open redirects.

I'm thinking on working on my own implementation for a project

https://www.facebook.com/notes/facebook-security/link-shim-p...

sorry I was on mobile when I first commented.

I meant to say that if your /redirect entrypoint returns a Header that looks like

    Refresh: 0; URL={url}

Your visitors' browsers will remove the referer header altogether when loading {url}.

This is in contrast to the more common Location: {url} header.

Does that entry point need to be protected in any way from people using it ... maliciously ... somehow? I recall people being upset about open redirects in the past, but I can't actually formulate a coherent security objection to it.

It looks like Slack's https://slack-redir.net/link?url=http://www.example.com/ isn't locked down, for instance.

It should be locked otherwise you can trick people into clicking on a link thinking it belongs to that company. Google, for instance, does protect against that, so you can't use http://www.google.com/url?http://www.example.com/

By controlling the referer header you can do all sorts of cool things like tamper with authenticated Google search histories in a way which makes it look like the person actually searched for a particular term:

http://thefutureisastephenkingnovel.com/badforensics/

How is it possible that this header is misspelled? Is there any interesting story behind it?

"The misspelling of referrer originated in the original proposal by computer scientist Phillip Hallam-Baker to incorporate the field into the HTTP specification.[3] The misspelling was set in stone by the time of its incorporation into the Request for Comments standards document RFC 1945; document co-author Roy Fielding has remarked that neither "referrer" nor the misspelling "referer" were recognized by the standard Unix spell checker of the period.[4] "Referer" has since become a widely used spelling in the industry when discussing HTTP referrers; usage of the misspelling is not universal, though, as the correct spelling "referrer" is used in some web specifications such as the Document Object Model."

https://en.wikipedia.org/wiki/HTTP_referer

Google and DuckDuckGo do this with a redirect system, right?

Before loading the page I thought this might be about hiding the client's ip (that connected to an SMTP server) in the mail headers. Is that possible at all?

Correction: s/<meta type="referrer">/<meta name="referrer">/g

Thanks, fixed (will be live in a minute or two). Should have double checked that rather than just writing it from memory!

What is the benefit to users of having folder names in the URL? Seems like it totally avoids the issue if a unique ID or encrypted name is used.

It makes the browser history more useful. And it’s nicer to look at (people do still see URLs in many browsers).

It actually doesn't totally avoid the issue, because you're still leaking information unless you use a different ID for every request. Someone looking at referer logs can see that you accessed two different things from the same folder.

There's also the u= parameter which tells which user you are. That _is_ obfuscated, but it has the same correlation issue, it's the same for forever for a single user, so you could tell that it's the same user looking at different URLs.

(we use the u= parameter both for supporting multiple concurrent logged in users on the same machine, and as an extra layer of CSRF protection)

Well if it was just an opaque identifier then it'd not need to leak anything other than the same item being used multiple times.

But point taken, thanks.

Reply on news.ycombinator.com