search

segahm / wire

Wire for Business with Guest Accounts (fork of https://github.com/wireapp/wire-webapp)
https://wire.caura.co
GNU General Public License v3.0
0 stars 0 forks source link

Wire Chat App's SAME ORIGIN POLICY restrictions do not allow 3rd parties to build on top of its open source code #10

Open segahm opened 6 years ago

segahm commented 6 years ago

Documenting here Wire's restrictions on CORS(Cross-Origin Resource Sharing). Without this change, building on top of Wire's open source project is not an option.

This is a continuation of github.com/wireapp/wire-webapp/issues/1134 (from Apr 26 2017 Wire Team issue). Posting this outside of the wire team, so that the ticket remains open until the issue is resolved.

Foreword

Wire is made up:

The web client is loaded in user's web browser (think Facebook messenger) and interacts with the server (think api services). Both are supposedly available independently for forking and custom implementations (under GPL).

Issue Summary

Wire's open sourced App client cannot be hosted anywhere other than on app.wire.com domain because:

  1. Wire-hosted server has domain restrictions against non-wire domains, and
  2. Wire's server code is not fully open sourced for us to rely on self-hosted servers

Specifically, when self-hosting Wire App project on a custom domain, you will run into the following errors (at random intervals):

On our side, we have adhered to all the licensing restrictions and have made our own code modifications public here and here.

Wire contract with an open source community

Timeline:

Oct 2016 - Wire's public announcement is made about open source
Jan 2017 - My team chooses Wire as a platform decision and begins building on top of it
Apr 26 2017 - bug issue is first reported to Wire
May 8 2017 (wire side: founders) - we reached out to Founders in order to understand a high-level commitment to open source
June 2017 - Nov 2017 (wire: dev team) we received some technical support from staff during our implementation of both Wire App (this repo) and Wire Bot, and reported bugs--the usual...
Dec 13 2017 (wire: CEO) - we reached out to confirm their high-level vision to support businesses with use cases as ours (i.e. guest users)
Jan 17 2018 (wire: CTO) - we offered to pay a standard Professional Services fee for technical support with the goal of eventually getting to the core of CORS (Wire refused)

Closing Remarks

Let me say that wire team is doing good work. Their coding practices are top notch. I've had the pleasure of debugging errors (both ours and theirs) with them on several occasions. This ticket is in no way trying to diminish their contributions. Just attempting to sort out some misunderstandings.

I personally have been in touch with many members of their team (see above), so the reason for this ticket is that other communication venues for resolving this issue have been exhausted.

raphaelrobert commented 6 years ago

Hi @segahm,

The title of this issue is not correct. Wire is fully open-source, licensed under GPL:

You are asking to relax a security measure for the web app (#1134). We are happy to do whatever is reasonable, but relaxing security rules is not a path we want to take.

In the meantime, you have a number of options:

We understand that this is maybe not what you expect, but we would like to re-iterate that Wire is fully open-source and that the issue you mention is a measure in place for security reasons.

segahm commented 6 years ago

@raphaelrobert I think I've addressed your answers in my above summary of the issue.

But it sounds like you are saying that there is a potential vulnerability (or a weakening of the security) if a hacker hosts the chat app locally and changes etc/hosts file to:

127.0.0.1    app.wire.com

If not, what do you mean by the "relax a security measure"?

raphaelrobert commented 6 years ago

I'm referring to your request from #1134.

There is probably no problem when hosting the web app locally, but in order for that to work we would have to change the CORS header so that the Wire web app can be run on any domain/website. This is precisely what we don't want. But you can use the Wire Desktop app for that, since the limitation can be circumvented there. Or host your own compatible server (which might be the more appropriate setting anyway).

segahm commented 6 years ago

To quote stackexchange security discussion

All CORS does is relax the SOP when it is active. It does not increase security, it simply allows some exceptions to take place. Some browsers with partial CORS support allow cross site XHR requests (e.g. IE 10 and earlier), however they do not allow custom headers to be appended. In CORS supported browsers the Origin header cannot be set, preventing an attacker from spoofing this. ...

Finally, all of the above has nothing to do with forged requests coming directly from an attacker, for example with curl. Remember, the attacker needs to use the victim's browser for their attack. They need the browser to automatically send its cookies. This cannot be achieved by a direct curl request as this would only be authenticating the attacker in this type of attack scenario (the category known as "client-side attacks").

To your second point, I will quote the above

Wire's server code is not fully open sourced for us to rely on self-hosted servers

As far as we checked, this is still the case. If there is documentation and instructions to the contrary, we will be happy to explore that option.

raphaelrobert commented 6 years ago

Regarding CORS: There is no security vulnerability there. Users can of course bypass the limitation themselves, but then it's a conscious decision. We don't see that as part of our threat model.

Some more background information about CORS: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS.

As I mentioned earlier, changing our server set-up so that it can be self-hosted more easily is work-in-progress. We cannot say exactly when it will be available, but we are working on it.