pad url is leaked whenever a link is clicked #1603

Closed
elijh opened this Issue Mar 11, 2013 · 33 comments

Comments

Projects
None yet
@elijh
Contributor

elijh commented Mar 11, 2013

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

This comment has been minimized.

Show comment Hide comment
@Wikinaut

Wikinaut Mar 11, 2013

Contributor

+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>

Contributor

Wikinaut commented Mar 11, 2013

+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

This comment has been minimized.

Show comment Hide comment
@JohnMcLear

JohnMcLear Mar 11, 2013

Member

Welcome to see proposals and their relevant patches for this issue

Member

JohnMcLear commented Mar 11, 2013

Welcome to see proposals and their relevant patches for this issue

@elijh

This comment has been minimized.

Show comment Hide comment
@elijh

elijh Mar 11, 2013

Contributor

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.

Contributor

elijh commented Mar 11, 2013

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

This comment has been minimized.

Show comment Hide comment
@Wikinaut

Wikinaut Mar 11, 2013

Contributor

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."

Contributor

Wikinaut commented Mar 11, 2013

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

This comment has been minimized.

Show comment Hide comment
@micah

micah Mar 11, 2013

Contributor

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.

Contributor

micah commented Mar 11, 2013

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

This comment has been minimized.

Show comment Hide comment
@azul

azul Mar 12, 2013

Contributor

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.

Contributor

azul commented Mar 12, 2013

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

This comment has been minimized.

Show comment Hide comment
@tamaskan

tamaskan Apr 6, 2013

@marcelklehr

This comment has been minimized.

Show comment Hide comment
@marcelklehr

marcelklehr Apr 6, 2013

Member

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

Member

marcelklehr commented Apr 6, 2013

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

@JohnMcLear

This comment has been minimized.

Show comment Hide comment
@JohnMcLear

JohnMcLear Apr 6, 2013

Member

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

Member

JohnMcLear commented Apr 6, 2013

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

@JohnMcLear

This comment has been minimized.

Show comment Hide comment
@JohnMcLear

JohnMcLear Apr 6, 2013

Member

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

Member

JohnMcLear commented Apr 6, 2013

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

This comment has been minimized.

Show comment Hide comment
@JohnMcLear

JohnMcLear Jun 6, 2013

Member

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

Member

JohnMcLear commented Jun 6, 2013

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

@elijh

This comment has been minimized.

Show comment Hide comment
@elijh

elijh Jun 6, 2013

Contributor

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:

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.

Contributor

elijh commented Jun 6, 2013

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:

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

This comment has been minimized.

Show comment Hide comment
@JohnMcLear

JohnMcLear Jun 6, 2013

Member

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

Member

JohnMcLear commented Jun 6, 2013

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

@JohnMcLear

This comment has been minimized.

Show comment Hide comment
@JohnMcLear

JohnMcLear Jun 6, 2013

Member

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

Member

JohnMcLear commented Jun 6, 2013

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

@marcelklehr

This comment has been minimized.

Show comment Hide comment
@marcelklehr

marcelklehr Jun 6, 2013

Member

+1 ;)

Member

marcelklehr commented Jun 6, 2013

+1 ;)

@anarcat

This comment has been minimized.

Show comment Hide comment
@anarcat

anarcat Jun 6, 2013

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)

anarcat commented Jun 6, 2013

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

This comment has been minimized.

Show comment Hide comment
@JohnMcLear

JohnMcLear Jun 6, 2013

Member

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

Member

JohnMcLear commented Jun 6, 2013

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

@elijh

This comment has been minimized.

Show comment Hide comment
@elijh

elijh Jun 6, 2013

Contributor

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.

Contributor

elijh commented Jun 6, 2013

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

This comment has been minimized.

Show comment Hide comment
@JohnMcLear

JohnMcLear Jun 9, 2013

Member

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?

Member

JohnMcLear commented Jun 9, 2013

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

This comment has been minimized.

Show comment Hide comment
@JohnMcLear

JohnMcLear Mar 17, 2014

Member

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

Member

JohnMcLear commented Mar 17, 2014

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

@JohnMcLear JohnMcLear closed this Mar 17, 2014

@joelpurra

This comment has been minimized.

Show comment Hide comment
@joelpurra

joelpurra Jan 27, 2015

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

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

@JohnMcLear

This comment has been minimized.

Show comment Hide comment
@JohnMcLear

JohnMcLear Jan 27, 2015

Member

@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!

Member

JohnMcLear commented Jan 27, 2015

@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

This comment has been minimized.

Show comment Hide comment
@joelpurra

joelpurra Jan 27, 2015

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

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

@joelpurra

This comment has been minimized.

Show comment Hide comment
@joelpurra

joelpurra Jan 27, 2015

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

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

@JohnMcLear

This comment has been minimized.

Show comment Hide comment
@JohnMcLear

JohnMcLear Jan 27, 2015

Member

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

Member

JohnMcLear commented Jan 27, 2015

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

@joelpurra

This comment has been minimized.

Show comment Hide comment
@joelpurra

joelpurra Jan 27, 2015

@joelpurra

This comment has been minimized.

Show comment Hide comment
@joelpurra

joelpurra Jan 27, 2015

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

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

@joelpurra

This comment has been minimized.

Show comment Hide comment
@joelpurra

joelpurra Jan 27, 2015

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

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

@JohnMcLear

This comment has been minimized.

Show comment Hide comment
@JohnMcLear

JohnMcLear Jan 27, 2015

Member

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

Member

JohnMcLear commented Jan 27, 2015

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

@xshadow

This comment has been minimized.

Show comment Hide comment
@xshadow

xshadow Jul 25, 2015

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

xshadow commented Jul 25, 2015

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

This comment has been minimized.

Show comment Hide comment
@rugk

rugk May 5, 2016

Contributor

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.

Contributor

rugk commented May 5, 2016

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

This comment has been minimized.

Show comment Hide comment
@dkg

dkg Sep 7, 2017

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

dkg commented Sep 7, 2017

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

@rugk

This comment has been minimized.

Show comment Hide comment
@rugk

rugk Sep 7, 2017

Contributor

Yes, in #3044, I added this.

Contributor

rugk commented Sep 7, 2017

Yes, in #3044, I added this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment