search

globaleaks / whistleblowing-software

GlobaLeaks is free, open-source whistleblowing software enabling anyone to easily set up and maintain a secure reporting platform.
https://www.globaleaks.org
Other
1.22k stars 267 forks source link

Debug cookies detection malfuncion on third party integration using iframes. #1233

Closed evilaliv3 closed 9 years ago

evilaliv3 commented 9 years ago

While testing with @vecna the iframe integration on http://ytre.me/test.html we found that the cookies configug (enabled/disabled) seems to be not rightly detected.

the integration code used is:

<html>
<body>

<h1>xx</h1>

<div width="33%">
    <iframe width="100%" height="100%" frameborder="0" src="https://experiment.globaleaks.org/#/embedded/submission?lang=en">
    </iframe>
</div>

</body>
</html>

the result of the probable bug is the following: screenshot from 2015-04-15 17 25 12

hellais commented 9 years ago

A quick search seems to indicate this is a problem with third party cookies being disabled: http://stackoverflow.com/questions/2117248/setting-cookie-in-iframe-different-domain.

Can you check to see if your browser has third party cookies disabled and if enabling them fixes the issue?

I realise this is no good and a workaround needs to be found.

evilaliv3 commented 9 years ago

I'm not sure the problem is this.

Try to open this URL in chromium and you will get the same result: http://ytre.me/test.html

vecna commented 9 years ago

I guess is the same problem, and Tor Browser by default keep them disabled. We've just to say that integration in iframe can be done only as part of the same domain, like OCCRP has done.

fpietrosanti commented 9 years ago

@vecna @evilaliv3 We can workaround this problem by detecting the iframe inclusion + cookie issue and, rather than prompting for a cookie error, provide a nice looking button "Blow the Whistle" that will fire once clicked the submission page within a browser-bar-less-window with something like window.open('https://experiment.globaleaks.org/#/embedded/submission?lang=en&receiver=RECEIVERUID&context=CONTEXTUID', '_blank', 'toolbar=0,location=0,menubar=0');

evilaliv3 commented 9 years ago

yep i confirm. tested enabling and disabling third party cookies and the issue is exactly this.

@fpietrosanti how can we deal with this in relation to OCCRP partners?

my idea is to remove cookies entirely that currently are used only for the anti-csrf token.

this would solve two issues:

  1. we would be able to say: we are not using cookies both to privacy+security reasons (reducing possbile attack surfaces on that)
  2. we would be able to run whenever cookies are disabled, and for example to be integrated in third party website whenever globaleaks allows that (e.g. for the OCCRP use case)
fpietrosanti commented 9 years ago

@evilaliv3 Cookies are used as per https://docs.google.com/document/d/1SMSiAry7x5XY9nY8GAejJD75NWg7bp7M1PwXSiwy62U/pub in section "Session Management" that has ben audited

vecna commented 9 years ago

@evilaliv3 will be a huge thing remove that shit :) is easier just restrict the integration cases.

fpietrosanti commented 9 years ago

@vecna I'm against that kind of change because is part of a security requirement that we'v discussed a lot and has been audited.

vecna commented 9 years ago

@fpietrosanti yes, is the same thing I'm saying. will be an huge thing remove that shit = has not to be removed = is easier just restrict the integration cases.

we cannot get rid of the cookies, and by default cookies are treated (by Tor Browser, but also from other persons that configure their own browser), as a privacy issue. so cannot be solved like a software bug.

evilaliv3 commented 9 years ago

@fpietrosanti / @vecna / @hellais : the documentation is outdated and not maintained and we should overcome this. what you are saying @fpietrosanti does not reflect the decision we took by tickets and by developmenet decision while trying to shutting down the Cookie.

@hellais first in February 2013 shutted down the usage of the authentication based on Cookie (https://github.com/globaleaks/GLBackend-outdated/commit/078405b1460549213f56b3be5301a60d0a08bf3d). At least 1 year ago but i think more i shutted down the usage of the cookie for the language selector and for the download.

so now what we have to do is to simply accept that the doc should be updated based on all the penetration tests that have been implemented on the real implementation. in addition i will also provide a patch in a branch (to be audited ok) to shut down the usage of the cookies for anti-csrf.

evilaliv3 commented 9 years ago

and i would add that all the texts related to Session Management does not reflect the current implementation:

false:

A Session will expire accordingly to a default user idling timeout:
- whistleblower 10 hours
- receiver 10 minutes
- admin 3 minutes

false:

The Session ID is generated randomly by the server and is 256bits long (hex encoded) and is generated via Crypto.Random.random (hex(random.getrandbits(256))).

we removed Crypto.Random.random since a lot of time by using os.random() and sometime cryptography as suggested by the auditors.

evilaliv3 commented 9 years ago

This issue is not solvable. We should simply document that the integration mode can work only when 1) tor2web acts reverse proxy on the same domain of the app (like in OCCRP project) 2) the user has configured its browser to accept third parties cookies (this solution is not usable but anyway we can mention this issue in the doc

@fpietrosanti can you take care of this?

vecna commented 9 years ago

@evilaliv3 Issue not solvable because the cookies cannot get removed, or for which other reasons ?

point 1 = we've to specify that the costs in security exposure, is an attacker compromising the webserver and injecting javascript in to the same scope of globaleaks.

evilaliv3 commented 9 years ago

@vecna: we use cookies only for the anti-csrf protection that combine the usage of two different medias (cookies+headers); in order to be able to remove cookies we would need to study a different protection and get an audit of it, so it will take a lot of time. let's think about this problem when starting the new pentest in order to provide pentester this question and find a possible solution.

fpietrosanti commented 9 years ago

@evilaliv3 @vecna in the meantime we could detect the condition by using the integration method described at http://www.allannienhuis.com/archives/2013/11/03/blocked-3rd-party-session-cookies-in-iframes/ that require the user to click 1 button (that will open a new window on the iframed-window, store the first cookie, close the new window, reload the iframe that's now authorized for cookies)

isgroup commented 9 years ago

Foreword

The failure of the cookie is caused by a policy that does not all browsers have called "3rd party cookie", a kind of P3P IE, but automatic.

P3P existed for a long time (decades?) and pretty much no one respect it, thus it's virtually useless to the privacy-savy user.

Why? It's the browser to tell Facebook it has to be traced, imagine how many laughs they do the other side.

The "3rd party cookie" policy is present in Safari, FF, Chrome (and perhaps other browsers) has a default client-side behavior (do not let iframes to set cookies, think to "tracking cookie" for advertisement), bypassing any server-side protection. In modern Safari it's is enabled by default, disabled in FF but can be activated in "about: config", etc.

Technical summary

There are two separate issues that interact causing the you have observed:

Since the framing itself (I did not see X-Frame-Options) allows Clickjacking attacks, my professional advice is not to use framing as integration technique, for the following reasons:

Executive summary

The problem is not the cookie (although personally I prefer CSRF tokens in forms) but the frame. And cookies for sessions are still the preferred method to keep session IDs, since cookies enjoy special protections (Secure, HTTPOnly).

If however you decide to create a security risk for your "customers" there is a workaround: Using the sandbox policy you can break the same-origin-policy making the content of the iframe to be seen as belonging to the window.top domain.

<Iframe sandbox = "allow-scripts allow-same-origin">

More documentation on https://developer.mozilla.org/en/docs/Web/HTML/Element/iframe and support matrix on http://caniuse.com/#feat=iframe-sandbox

By doing so you will be able to interact fully with the DOM the main page. And you'll burn in hell.

Francesco ascii Ongaro ISGroup SRL - http://isgroup.biz/

PS: Do not use frames! Do not include JS!

fpietrosanti commented 9 years ago

After skype chat we come up with the solution to move XSRF from HTTPHEADER+COOKIE to HTTPHEADER+JSONPARAMETER, then iframe will work back, but pure JS integration with CORS is the way to go for the future

isgroup commented 9 years ago

Nice to see but has security disadvantages against a simple link. It was a pleasure to help GL!

evilaliv3 commented 9 years ago

as the session is based on Headers and no more on cookies no possibility of XSRF attacks exists on authenticated sessions.

so with @fpietrosanti we agreed to simplify the xsrf protection that is now simply relying on the fact that the attacker would not be able to trigger the usage of the session token given that it's handled in javascript and delivered by an HTTP header.

IuliiSe commented 8 years ago

I am still having a problem with iframe integration via onion.link It woks fine in Firefox, but not in Chrome.