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