[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libreoffice-website] Authentication issue with Nextcloud


On Fri, 22 Mar 2019 at 22:32:02 +0100, William Gathoye wrote:
> It appears the location of these fonts haven't been whitelisted properly
> leading to the Nextcloud client webview (qt5-webengine) to not load them
> to avoid a potential XSS vulnerability.

The CSP violation looks somewhat odd to me:

[unknown Refused to load the font 'https://auth.documentfoundation.org/saml/singleSignOn?SAMLRequest=…' because it violates the following Content Security Policy directive: "font-src 'self' data:".

There is no CSP for font resources on https://auth.documentfoundation.org .
(In fact the page doesn't have any font resource AFAICT, although I suppose
it might depend on the User-Agent.) On https://nextcloud.documentfoundation.org
we have

Content-Security-Policy: default-src 'none'; […]; font-src 'self' data:; […]

I don't understand why your client tries apply that policy when loading
resources from https://auth.documentfoundation.org . There is a 303
redirection in the middle, and the CSP doesn't apply to the Location
target.

Also, the CSP is populated by Nextcloud itself. Plugins can amend it,
for instance instance ‘richdocuments’ adds the LOOL domain to the
frame-src whitelist:

https://github.com/nextcloud/server/blob/master/lib/public/AppFramework/Http/EmptyContentSecurityPolicy.php
https://github.com/nextcloud/richdocuments/blob/v3.2.4/appinfo/app.php#L70

If ‘user_saml’ was really non-functioning without loading font resources
from the SAML IdP URI (even if just on desktop clients), I would expect
to see

$policy->addAllowedFontDomain($samlDomain)

somewhere in the source.

> 2. *not* successful, http result code is 302 [2] --> the connection
> issue per se

That's rdm#2658 right? If so, please avoid cross-posting.

> Could you please disable "Use SAML auth for the Nextcloud desktop
> clients (requires user re-authentication)" in the Nextcloud server admin
> settings? SAML SSO remains active without this parameter.

From https://github.com/nextcloud/user_saml/blob/master/appinfo/app.php#L124
it's not exactly clear to me what that would entail.

* Does that require authentication via application-specific passwords?
If so, changing the setting requires some kind of consensus, and if
users agree to disable SAML, we need a transition (and warn users)
to avoid confusion. You're not the only one using the desktop
client against out instance, and most other folks are using a
version that seems to work. AFAICT disabling the setting would make
their setup stop working until they add an app password. (I guess
they won't object if they can have long-lived sessions, but they
still need to be consulted and warned.)

* Does it mean that the Nextcloud server hijacks the SAML challenge
and perform authentication on behalf of the user? (Doesn't seem so
based of my understanding of the code, but I'm not sure.) If so,
that would completely collapse the threat model. WebSSO isn't only
a convenience, the different front-ends don't get to see user
credentials. Reducing the attack surface is the whole point.

--
Guilhem.

--
To unsubscribe e-mail to: website+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/website/
Privacy Policy: https://www.documentfoundation.org/privacy

Follow-Ups:
Re: [libreoffice-website] Authentication issue with NextcloudWilliam Gathoye <william@gathoye.be>
References:
[libreoffice-website] Authentication issue with NextcloudWilliam Gathoye <william@gathoye.be>
Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.