Repository: freedomofpress/securedrop

Issue:
redirect-to-external-link broken in live SD instances
The links at http://y6xjgkgwj47us5ca.onion/howto-disable-js#how and other live SD instances return "Redirect not allowed", whereas they seem to work properly in local dev environments (http://localhost:8080/howto-disable-js). 

What's even weirder is that if you replace the redirect URL parameter with its URL-encoded value (ex: https%3A%2F%2Ftails.boum.org%2F), the live instances return 404, whereas the local instances will still redirect properly.

External links on SecureDrop static sites leak Referrer
The SecureDrop static pages contain links pointing to external HTTP websites. This can be considered an information leak as this might help de-anonymizing a user via the HTTP referrer and the DOM property `document.referer`.

Examples:
- http://[redacted].onion/tor2web-warning
- http://[redacted].onion/howto-disable-js

Clicking this link will open the tor2web website in the very same window. This will leak the referrer to this website and allow those parties having control over the log files and website markup to know, that the user visited the TOR hidden service right before visiting their website. Another link is pointing to the website of the TOP project - again as plain HTTP URL.

Using HTML links or any other external resources or pointers in the markup of the SecureDrop application should be avoided at any cost. Users should be encouraged to simply copy and paste a HTTP URL shown in plaintext. It could also be considered to use Data URI s to create a referrer-less link to avoid the data leakage to the outside world.

Note that the HTML specification also mentions the “noreferrer” attribute for links. This might be used as well to attempt provision of non-leaky links - yet not all modern browsers support this attribute fully yet. It is thus not recommended to fully rely on this attribute to work as expected.

**Reported as part of the cure53 audit of 0.2 as: SD-01-008**



Discussion:
I wonder if this is due to some special URL parsing rules that Tor browser includes for .onion URLs.

Also, redirects are working correctly on develop in Tor Browser (using localhost:8080 and adding an exception so TBB doesn't attempt to actually reach localhost through Tor).

I'll check the apparmor logs too but if it was the apparmor profile don't
think you'd get the 'redirect not allowed' error but just a 404.

Also, redirects are working correctly on develop in Tor Browser (using
localhost:8080 and adding an exception so TBB doesn't attempt to actually
reach localhost through Tor).

—
Reply to this email directly or view it on GitHub
https://github.com/freedomofpress/securedrop/issues/453#issuecomment-46131638
.

The status is `200` for the redirect URLs as well, not `302`.  Reproducing all the security headers present on the redirect url does not cause the issue to recur.  I'm willing to bet this is an apparmor protection.

FYI this was my tester:

<pre>&lt;?php
header("X-Download-Options: noopen");
header("X-content-security-policy: default-src 'self'");
header("X-content-type-options: nosniff");
header("content-security-policy: default-src 'self'");
header("x-frame-options: deny");
header("x-xss-protection: 1; mode=block");
header("Location: http://www.example.com");
</pre>

Confirmed that setting the headers to be as they are in production creates neither the 404 error nor "redirect not allowed".

I'm guessing something in apparmor or apache filters/transforms the URL path somehow such that it no longer matches the redirect whitelist. 

I've not made progress on reproducing this issue locally. For 0.3, I can revert the links to ugly-looking URL text in parentheses. 

Luckily the upstream issue (https://trac.torproject.org/projects/tor/ticket/9623#comment:7) should be easy to fix, and I can try to get a patch into the next TBB release (unfortunately just missed the last one).

BTW, this Firefox noreferrer issue **finally** got fixed but will probably not be ending up in TBB's version of Firefox anytime soon: https://bugzilla.mozilla.org/show_bug.cgi?id=530396

Ok I made a quick upstream patch for TorButton to clear cross-origin referer when going from a .onion to another domain, or vice versa: https://github.com/diracdeltas/torbutton/pull/1

I will poke Mike Perry to review it but it may take a while.

The rel="noreferrer" attribute is not yet respected as of FF 25, which means that even the new TBB will not respect this, when released (it will be based on FF 24 ESR).  Removing the external links completely (https://github.com/pemulis/securedrop/commit/44a04a22a32cd5df84476dd6afdc7aa74464f730) seems like the way to go here.

Closed by @pemulis https://github.com/freedomofpress/securedrop/commit/896401b110b45352514557fbc3c2d6da7ab3cb54

This fix looks good. Re-opening so I can merge into master as well.


Resolving patch:
diff --git a/securedrop/source.py b/securedrop/source.py
--- a/securedrop/source.py
+++ b/securedrop/source.py
@@ -310,26 +310,6 @@ def why_download_journalist_pubkey():
     return render_template("why-journalist-key.html")
 
 
-_REDIRECT_URL_WHITELIST = ["http://tor2web.org/",
-        "https://www.torproject.org/download.html.en",
-        "https://tails.boum.org/",
-        "http://www.wired.com/threatlevel/2013/09/freedom-hosting-fbi/",
-        "http://www.theguardian.com/world/interactive/2013/oct/04/egotistical-giraffe-nsa-tor-document",
-        "https://addons.mozilla.org/en-US/firefox/addon/noscript/",
-        "http://noscript.net"]
-
-
-@app.route('/redirect/<path:redirect_url>')
-def redirect_hack(redirect_url):
-    # A hack to avoid referer leakage when a user clicks on an external link.
-    # TODO: Most likely will want to share this between source.py and
-    # journalist.py in the future.
-    if redirect_url not in _REDIRECT_URL_WHITELIST:
-        return 'Redirect not allowed'
-    else:
-        return render_template("redirect.html", redirect_url=redirect_url)
-
-
 @app.errorhandler(404)
 def page_not_found(error):
     return render_template('notfound.html'), 404


Test patch: