nextcloud / user_saml

:lock: App for authenticating Nextcloud users using SAML https://apps.nextcloud.com/apps/user_saml
https://portal.nextcloud.com/article/configuring-single-sign-on-10.html
GNU Affero General Public License v3.0
95 stars 75 forks source link

[Bug]: Occasionally getting access to other users cloud #872

Closed eidota closed 3 months ago

eidota commented 3 months ago

⚠️ This issue respects the following points: ⚠️

Bug description

This happens rather rarely, and we have not been able to reproduce it reliably.

What we have found out is that when loading the page, the "Logout" button is occasionally visible, which should not actually be there because of SSO. In this case, Nextcloud sets several unexpected cookies (nc_session_id, nc_token, nc_username) that are not normally present.

It seems that Nextcloud occasionally gets lost when checking the Shibboleth session and then loads in a local context. And in some of these cases people get loaded into another users cloud. We can also report that in the case of a correct session, the local cookies (nc_...) are also set when the page loading. These are then automatically removed again, presumably as soon as the shibboleth session has been verified. You only see a brief flicker of the cookies in the web tools before they disappear again.

On our IDP side, the requests and responses to Nextcloud look completely correct.

This problem occured first after we updated Nextcloud from 28.0.4 to 28.0.8 in the course of which user_saml was upgraded from 6.1.3 to 6.2.0

Steps to reproduce

  1. Have a session with your SSO (Shibboleth)
  2. Navigate to the Nextcloud-Instance
  3. Sometimes you are logged in as another user and have full access

Expected behavior

No access to foreign accounts.

Installation method

Community Manual installation with Archive

Nextcloud Server version

28

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.1

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Updated from a MINOR version (ex. 28.0.1 to 28.0.2)

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

Configuration report

{
    "system": {
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost",
            "***FQDN***",
            "***ALIAS***"
        ],
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "28.0.8.1",
        "overwrite.cli.url": "https:\/\/cloud.xxx.de",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "default_phone_region": {
            "1": "DE"
        },
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "25",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": "6379",
            "password": "***REMOVED SENSITIVE VALUE***",
            "timeout": 1.5,
            "read_timeout": 1.5transparency about our security, so any valid vulnerabilities discovered are always publicly disclos
        },
        "onlyoffice": {
            "verify_peer_off": "true",
            "jwt_header": "XOCAuth"
        },
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "filelocking.enabled": "true",
        "enable_previews": "true",
        "enabledPreviewProviders": [
            "OC\\Preview\\PNG",
            "OC\\Preview\\JPEG",
            "OC\\Preview\\GIF",
            "OC\\Preview\\BMP",
            "OC\\Preview\\XBitmap",
            "OC\\Preview\\Movie",
            "OC\\Preview\\PDF",
            "OC\\Preview\\MP3",
            "OC\\Preview\\TXT",
            "OC\\Preview\\MarkDown"
        ],
        "preview_max_x": "1024",
        "preview_max_y": "768",
        "preview_max_scale_factor": "1",
        "auth.bruteforce.protection.enabled": "true",
        "trashbin_retention_obligation": "auto,7",
        "skeletondirectory": "",
        "defaultapp": "files",
        "activity_expire_days": "14",
        "integrity.check.disabled": "false",
        "updater.release.channel": "stable",
        "forcessl": "true",
        "has_internet_connection": "true",
        "maintenance": false,
        "ldapUserCleanupInterval": "51",
        "singleuser": "false",
        "default_language": "de_DE",
        "allow_user_to_change_display_name": "false",
        "loglevel": 3,
        "simpleSignUpLink.shown": false,
        "maintenance_window_start": 2
    }
}

List of activated Apps

Enabled:
  - activity: 2.21.1
  - announcementcenter: 6.8.1
  - bruteforcesettings: 2.9.0
  - cloud_federation_api: 1.12.0
  - comments: 1.19.0
  - contactsinteraction: 1.10.0
  - dashboard: 7.9.0
  - dav: 1.30.1
  - deck: 1.13.1
  - federatedfilesharing: 1.19.0
  - federation: 1.19.0
  - files: 2.1.0
  - files_automatedtagging: 1.19.0
  - files_downloadlimit: 2.0.0
  - files_pdfviewer: 2.10.0
  - files_reminders: 1.2.0
  - files_sharing: 1.21.0
  - files_trashbin: 1.19.0
  - files_versions: 1.22.0
  - firstrunwizard: 2.18.0
  - groupfolders: 17.0.1
  - logreader: 2.14.0
  - lookup_server_connector: 1.17.0
  - nextcloud_announcements: 1.18.0
  - notifications: 2.17.0
  - oauth2: 1.17.0
  - onlyoffice: 9.3.0
  - password_policy: 1.19.0
  - photos: 2.5.0
  - privacy: 1.13.0
  - provisioning_api: 1.19.0
  - recommendations: 2.1.0
  - related_resources: 1.4.0
  - serverinfo: 1.19.0
  - settings: 1.12.0
  - sharebymail: 1.19.0
  - support: 1.12.0
  - survey_client: 1.17.0
  - systemtags: 1.19.0
  - text: 3.10.1
  - theming: 2.4.0
  - twofactor_backupcodes: 1.18.0
  - updatenotification: 1.19.1
  - user_saml: 6.1.3
  - user_status: 1.9.0
  - viewer: 2.3.0
  - weather_status: 1.9.0
  - workflowengine: 2.11.0
Disabled:
  - admin_audit: 1.19.0
  - circles: 29.0.0-dev (installed 25.0.0)
  - encryption: 2.17.0
  - files_external: 1.21.0
  - suspicious_login: 7.0.0
  - twofactor_totp: 11.0.0-dev
  - user_ldap: 1.20.0

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

No response

Additional info

We have 2 Application Servers behind an HA-Proxy, the DB and redis are on its own servers. We use local nextcloud-accounts that are synchronised once a day via a custom script using occ-calls. Authentification is realised with user_saml (Shibboleth). This setup is up and running since April.

user_saml configuration REMOTE_USER Mapped displayName and mail

joshtrichards commented 3 months ago

"integrity.check.disabled": "false", [..] Integrity checker has been disabled. Integrity cannot be verified.

Any idea why your integrity check output conflicts with your configuration?

We have 2 Application Servers behind an HA-Proxy, the DB and redis are on its own servers.

Just to rule out things: are you doing any caching or header manipulation in HAProxy?

Also, how are you distributing traffic between the two app servers?

We use local nextcloud-accounts that are synchronised once a day via a custom script using occ-calls.

Synchronized to/from where?

And in some of these cases people get loaded into another users cloud.

Any pattern to what actions are taking place when this occurs? Is it immediately upon visiting? Or when going to edit an office document? Etc.

How frequently is this happening?

"loglevel": 3,

I would encourage you to set your loglevel back to the default (2) - particularly while trying to isolate this situation.

Also, can you fill in the app list as requested in the template (i.e. occ app:list)?

eidota commented 3 months ago

"integrity.check.disabled": "false", [..] Integrity checker has been disabled. Integrity cannot be verified.

Any idea why your integrity check output conflicts with your configuration?

No, as you see we didnt disable it via config. Do you have any idea where we can check further why its not working?

We have 2 Application Servers behind an HA-Proxy, the DB and redis are on its own servers.

Just to rule out things: are you doing any caching or header manipulation in HAProxy?

The proxy adds X-Forwarded-Proto and sets X-Forwarded-For and X-Forwarded-Port

Configuration for caching: total-max-size 1024 max-age 30

Also, how are you distributing traffic between the two app servers?

IP-based round-robin

We use local nextcloud-accounts that are synchronised once a day via a custom script using occ-calls.

Synchronized to/from where?

From our LDAP where we have prepared trees for the users and groups.

And in some of these cases people get loaded into another users cloud.

Any pattern to what actions are taking place when this occurs? Is it immediately upon visiting? Or when going to edit an office document? Etc.

Thats the problem. We cant see a clear pattern and it happens infrequently.

We have ~800 daily users at the moment and the problem was reported 1-3 times a day. Mostly it seems to be happening when visiting the cloud with an already active shibboleth-session. But we also had at least one case where it happened while using the cloud (editing a document in only-office)

How frequently is this happening?

see above

"loglevel": 3,

I would encourage you to set your loglevel back to the default (2) - particularly while trying to isolate this situation.

I set it back to 2 Also, can you fill in the app list as requested in the template (i.e. occ app:list)? I added the occ output to the initial post.

Updated configuration

We downgraded the user_saml app to 6.1.3 as this was version was running fine before. As this didnt fix the problem we upgraded the server to 29.0.4. The problem persists.

Any idea if there where some changes since >28.0.4 that could connected to this? 28.0.4 + 6.1.3 was running fine for months and the first report from an user was some hours after we updated 28.0.4=>28.0.8.

Please let me know if you need more information and thank you for your time.

susnux commented 3 months ago

Any idea why your integrity check output conflicts with your configuration?

Because it is a string -> truthy. It should be 'integrity.check.disabled' => false

susnux commented 3 months ago

Are you using sticky sessions to keep sessions of one user on the same server? https://thisinterestsme.com/haproxy-sticky-sessions/

eidota commented 3 months ago

Any idea why your integrity check output conflicts with your configuration?

Because it is a string -> truthy. It should be 'integrity.check.disabled' => false

Thank you, now the output is: "No errors have been found."

Are you using sticky sessions to keep sessions of one user on the same server? https://thisinterestsme.com/haproxy-sticky-sessions/

We use sticky IP.