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