1.18.1 NC's own 'oc...' cookie causes a 503 error on dav requests

[working-name]

What's up guys? I've been fiddling with your software, trying to move from a competitor platform. Anyway short story long 😁...

Problem:

The desktop client (macOS here) sends cookies when requesting the .bcup from nextcloud (webdav). They're not used in authentication or verification thereof, so I'm not sure why they're included. I guess for future stuff, but either way, the cookie header contains ; which apparently throws off apache or nextcloud. I can't figure out which because they log nothing interesting with debug on.

Proposals:

• Look at how filestash handles its webdav auth because it works 100% with the same install - it only uses a single cookie called "auth". No Authorization header.

Things I tried:

• remove the ; after oc_sessionPassphrase= but leave the oc7ozabxv4ks=... alone - ✅
• remove ;oc7ozabxv4ks=... - ✅
• remove oc7ozabxv4ks=... only, but leave ; after oc_sessionPassphrase= - ✅
• remove cookie header altogether - ✅
• add random/stupid cookie entries with ; before oc_sessionPassphraseafter removing ;oc7ozabxv4ks=... - ✅
• move the oc7ozabxv4ks=... before oc_sessionPassphrase= but remove ; after oc_sessionPassphrase - ❌
• send just oc7ozabxv4ks=... alone - ❌
• different NC installs, reproducible on: 16.0.5, 17.0.1 (stable), 17.0.2 RC1, 16.0.5.1 at woelkli.com

So my working theory is that NC reacts to that randomly named cookie and its value. I can't find its reaction in its own logs yet.

Details:
Server: apache2 + php7.3-fpm serving nextcloud via http (ubuntu 18), behind nginx proxy with http2 via https (debian 10)
Client: Buttercup 1.18.1 on macOS 10.14.4, or Paw duplicating the request made by Buttercup

Potentially related issues: 117,#780, #817, #833, #825

Worth nothing

• iPhone app 1.10.1 and 1.12.0 do not have this problem using the same nextcloud install/bcup file
• 6d46dc6 (1.18.1 release commit) does not have a problem adding the bcup file from NC, but an edit request will fail

[perry-mitchell]

We don't actualy set any cookies - this is all done automatically by the request client. Cookies are provided by Nextcloud and ownCloud, which are set automatically it seems.. these, once sent back, seem to confuse Nextcloud and ownCloud as to whether or not to treat the request as a user session or not. At least this is what it's been looking like the more we hear about Nextcloud/ownCloud auth issues.

A related problem to this is the user-account stickiness which occurs after an initial request: buttercup/buttercup-mobile#127 (no info here though sorry).

We use axios in the webdav client, so this issue is very relevant I feel. I think following this would probably help: perry-mitchell/webdav-client#183 (comment)

Perhaps we need to add support for this in Buttercup so that all requests are made like this..

[working-name]

Yes, you are right, I was fiddling with your source code (not a programmer) and was trying to see how I could get to the chromium instance and manage its cookies. If you remove the oc####... cookie from the requests they go through normally. I don't know if NC is to blame or the chromium browser but the funny part is that a regular browser makes use of the same cookie without freaking NC out. So it must be just the webdav service having issues.

NB: the cookies are useless, it's only the Authorization header that NC recognizes from buttercup. I don't know how filestash does it mainly because I can't follow the code yet (again.... not a programmer), but it never sets an Authorization header and it only uses a single cookie value for auth.

[working-name]

The fix

Exempt the UA used by buttercup from Nextcloud's Same Site Cookie Protection by adding this to your NC's config.php:

'csrf.optout' => array(
  '/^WebDAVFS/', // comes with NC, apparently for OS X Finder
  '/^Microsoft-WebDAV-MiniRedir/', // whatever, still comes with NC
  '/Electron/', // buttercup-desktop uses Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.99 Electron/7.1.1 Safari/537.36
),

The rant

It is Nextcloud freaking out about the result of its own set-cookie requests which Chromium/Electron is following. Furthermore, NC developers seem to adhere to some HTTP specs regarding Same Site Cookie Protection – for everything, including webdav connections – and proceed to bitch about it in their sample config: 'Some user agents are notorious and don't really properly follow HTTP specifications'.

I for one have no clue what the HTTP specifications for SSCP/csrf are, nor do I understand why it needs to apply to webdav clients which use basic http auth anwyay. I guess one day I'll learn.

[perry-mitchell]

@working-name Thanks for sharing this. They do indeed have a weird process over at NC regarding auth. WebDAV requests should care about nothing other than the Authorization header, as cookies aren't relevant for clients connecting via this means. Whether or not items are requested from the browser is irrelevant.

We've been looking at our WebDAV client and so far haven't figured out a nice way to remove the cookies before making a request from within a browser.

[aesthicc]

Any updates on this?

Are there any security issues with Buttercup 1.16.2 in the meantime?

Thanks.

[goldstar611]

I can also say that I have seen this and that downgrading to 1.15 does not exhibit the problem. (the installer was on hand at the time to repro)

Are there any security issues with Buttercup 1.16.2 in the meantime?

@aesthicc Yes, especially if you are using dropbox. This was fixed in 1.18.1
#862

[aesthicc]

@aesthicc Yes, especially if you are using dropbox. This was fixed in 1.18.1
#862

That issue does say introduced in 1.18. So maybe that's good news.

[goldstar611]

That issue does say introduced in 1.18. So maybe that's good news.

I missed that comment by sallar. I feel better about downgrading now too.

[stuartm]

See also #947 which I opened before realising this issue had already been reported and tracked down. I do think the error messages/logging from Buttercup could be a bit more informative even if the underlying issue gets addressed.

I don't believe Nextcloud is wrong here to be applying CSRF protection to webdav, the fact that it's protected by BASIC auth has nothing to do with what CSRF is trying to prevent. The CSRF token isn't about verifying authorisation and Nextcloud is not using it in this way, it's about preventing replay and cross-site attacks using the existing valid session. By repeatedly sending the same stale token back you're triggering the protection mechanism, it's functioning as intended. The problem here is more likely to be the way the webdav requests are being made, I'll need to do some digging through the code.