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 ;)