pad url is leaked whenever a link is clicked

[elijh]

The problem: if a user clicks on a link in the main body or in the chat, the referrer is sent by the browser to the new website showing the full url of the pad, thus revealing the pad's content and history. Typically, this referrer information information is logged and stored by the target website.

Why this is bad: most users probably do not realized that clicking on a link in a pad automatically shares the pad with the website they clicked on (!).

Solutions:

(A) HTML5 has a noreferrer option for links, but is is not widely supported. Move along.

(B) One option would be to disable the auto-links in etherpad. As far as I can tell, these can be disabled in ace2_inner.js handleClick() and pad_utils.js escapeHtmlWithClickableLinks().

(C) Another option would be to change the way pad names are encoded in the URL to use the location hash instead of the path. For example, instead of https://pad.riseup.net/p/0Jr0e etherpad could use https://pad.riseup.net/#0Jr0e. The location hash (anchor) is not sent as part of the referrer.

(D) A final option is to create an interstitial page as part of etherpad. For example, every link would really go to /redirect/, where it would then get auto redirected on to the target website. The final target website could be sent to the request to /redirect either as a POST or in the location hash. For example, `/redirect#https%3A%2F%2Friseup.net%2Fwhat-is-my-referrer' would redirect to https://riseup.net/what-is-my-referrer.

Option D seems to me that it is probably the best for the moment: it would be easy to implement and it retains the usability of clickable links. On the downside, interstitial pages are slightly annoying because they make it a bit slower to get to the site you want.

Notes:

https -- If the pad is loaded via https, then the referrer is only sent to other https websites. This is small comfort, but important to know if you are trying this at home.

chrome -- Chrome is not able to figure out what the referrer should be of the inner ace iframe. I suspect this is because it is dynamically generated. The result is that if you click on a link in a pad body using chrome, no referrer is sent. Firefox has no such confusion, and links from the chat always send referrer in all browsers.

testing -- You can use https://riseup.net/what-is-my-referrer as a link to test if the referrer is being sent by the browser. Make sure to specify https and not http because the plain http link will redirect and erase the referrer.

[Wikinaut]

+1 for your analyis, which was on top of my list for a similar publication.

use method (C):

pad address as anchor part of the URL (#…) which is never sent to server.

is perfect and fully analysed for example in links mentioned here owncloud/core#106 (comment) and other articles related to client-side encryption, which often uses this property.

But how shall our entitled pad server know our pad url, it needs that ?

Look here to understand: a "hidden" encryption is perhaps to be used to enable that:

from https://github.com/sebsauvage/ZeroBin

<img src=http://sebsauvage.net/wiki/lib/exe/fetch.php?media=php:zerobin:zerobin_figure_encryption.png>

[JohnMcLear]

Welcome to see proposals and their relevant patches for this issue

[elijh]

Yeah, I prefer (C) precisely because it is what will be needed eventually to support client-encrypted pads. But it is not a minor change.

[Wikinaut]

see https://github.com/toberndo/mailvelope project which solves a similar (if not, the same) issue.

"Mailvelope is a browser extension for Google Chrome and Firefox that allows secure email communication based on the OpenPGP standard. It can be configured to work with arbitrary Webmail provider."

[micah]

Ouch, I was counting on the links not being sent as referrers when https was being used. I should have tested this! Option C, as Wikinaut has described would be the more complete solution and would enable a lot more for the future, but could take a long time to get there. It seems to me that option D is the easiest to implement and would resolve this security issue fast, in terms of not letting the perfect be the enemy of the good. A fast resolution to this issue seems more important at this point.

[azul]

My understanding of the etherpad lite architecture - which might be outdated - is that option (c) would actually not be that hard. From what i remember the initial page loaded by etherpad is always the same. Then the js parses the url and makes ajax requests to retrieve the pad specific content. These requests contain the pad id. But for the initial request the server does not make use of the pad id anyway.

[tamaskan]

Option E: Rewrite the URLs with a Dereferer-Service like http://www.dereferer.org

http://www.google.de -> http://www.dereferer.org/?http%3A%2F%2Fwww%2Egoogle%2Ede

[marcelklehr]

mh. could be an option, but I daresay a third-party service might not be
a desired solution for a privacy problem... ;)

[JohnMcLear]

Btw C would be quick/easy to solve/implement should anyone be interested in sponsoring me to dev it.

[JohnMcLear]

Another option is to place this feature request on http://etherpad.idea.informer.com/ and get enough votes for the community to fund the dev

[JohnMcLear]

Some NFPs are sponsoring 2 hours of my dev time on option D, will see where that gets us to

[elijh]

Holy shit, there was just a glitch in the matrix. It appears that Chrome has started to send the location.hash in the referer header.

Steps to reproduce:

• click on this link to pull up a comment on this page: pad url is leaked whenever a link is clicked #1603 (comment) (with location hash to jump to the comment)
• click on this link https://riseup.net/what-is-my-referrer (from this page)
• check what headers are sent by the browser.

Sure enough, just as the what-is-my-referrer page says, the referer header is being sent with the location hash:

Referer:https://github.com/ether/etherpad-lite/issues/1603#issuecomment-19043686

This is new behavior, and violates the RFC. Lets review the RFC 2616 language on referers:

The URI MUST NOT include a fragment

What is a fragment? "The fragment identifier introduced by a hash mark # is the optional last part of a URL for a document. It is typically used to identify a portion of that document." (src).

This is not the first time Chrome has violated an important aspect of the HTTP RFCs, won't be the last. This change must certainly be deliberate.

Sadly, I think that (D) "interstitial page" is the only option that makes sense at the moment.

[JohnMcLear]

Doing a prompt and an interstitial page as a fix anyway, I don't trust browsers.

[JohnMcLear]

Btw accepting donations if anyone wants this to move faster / spend more time on it. :)

[marcelklehr]

+1 ;)

[anarcat]

i can't reproduce the problem described by elijh here, i get this as a referer:

#1603

this is Chromium Version 27.0.1453.93 Debian 7.0 (200836)

[JohnMcLear]

Either way I don't trust the browser so don't worry about it. Will make the server do the heavy lifting.

[elijh]

Really weird, I am no longer able to reproduce fragment in the referrer. So, it must have been a non-deterministic bug in my version of Chromium. I will try to reproduce.

[JohnMcLear]

So I took a alternative route to fixing this problem in my latest commit. I basically store the url to a cookie and read that out when redirecting..

https://github.com/JohnMcLear/ep_hide_referrer

The url that is exposed to the third party is /redirect

Can anyone think of a weakness in storing the url in a cookie and referring to it during redirect?

[JohnMcLear]

Guess this way was strong enough.. Enjoy, closing..

[joelpurra]

Here's a test page, showing leaking pad URL to external links through HTTP referer.
https://etherpad.mozilla.org/eFJXwtxPJu

[JohnMcLear]

@joelpurra lulwut. MoPad is not running Etherpad. It's running an old abomination of Etherpad we don't even support any more. Tell MoPad to update or even better DONT USE MOPAD!

[joelpurra]

@JohnMcLear: is the problem fixed in the latest etherpad then?

[joelpurra]

@JohnMcLear: and where is a more recent public version I can test this on?

[JohnMcLear]

http://etherpad.org -- Download and test it -- Read this issue.

[joelpurra]

@JohnMcLear: guess it's not fixed:
https://beta.etherpad.org/p/http-referer

[joelpurra]

@JohnMcLear: so the problem is money time? I see.

[joelpurra]

Applied rel="noreferrer" in #2498. It's better than nothing and is a very simple patch, as you can see.

[JohnMcLear]

Some people might not want this though.. We can't change default behaviour under people..

[xshadow]

Could there be an option as described in #2731 ?
There won't be many changes to do:

It would be great to set two options in settings.json

/* Privacy: enable dereferring */
"enableDerefering" : True,
"derefererUrl": "https://dereferrer.foobar.org/"

and an adjustment in the link constructor accordingly.

At the moment I use @JohnMcLear ep_hide_referrer but that requires a user interaction ( a click ) - if you could use your own refererrer that would not be necessary and the users weren't bothered with it :)

[rugk]

Recent news about this issue for webadmins (or a possible inclusion into Etherpad): You can fix the referrer issue by using a CSP header (a relatively new security feature of major browsers). Just set the referrer value. E.g. in this way: Content-Security-Policy: referrer no-referrer;

FYI you can do much more with a CSP. Create your CSP here.

[dkg]

Ther'es also Referrer-Policy, https://www.w3.org/TR/referrer-policy/

[rugk]

Yes, in #3044, I added this.

[muxator]

Etherpad 1.8.0 changed its referrer policy and started sending Referrer-Policy: same-origin HTTP header.

Discussion & PR: #3636

Note to self about CSP: the use of CSP for configuring referrer policies has been deprecated. The current standard prescribes the use of Referrer-Policy.