Nextcloud 401/503 CSRF Cookie Issue

alankeny commented 6 years ago

This issue is a

[ ] bug
[ ] feature
[x] question

I'm trying to configure Tusk with a database from my Nextcloud server. I've tried using the shared link and webdav options, but both are giving errors.

Shared Link

When I tried the shared link option, it worked when I first added the URL, but after that Tusk gave a Network Error. The Apache logs for Nextcloud showed multiple 302 redirect entries when Tusk tried to download the file. The same URL worked fine in Chrome and wget.

I understand that this is a probably related to the way Nextcloud uses cookies, and that these cookies can't be modified by Tusk when it tries to to GET the file. If that's accurate, how would I go about debugging this, so I can open an issue with Nextcloud?

WebDAV

When I tried webdav, Tusk gave the error Invalid response: 503 Service Unavailable. The Apache access log showed a single entry "PROPFIND /remote.php/webdav/ HTTP/1.1" 503 -, and nothing was reported in the Nextcloud error log.

I verified that the same URL, user name, and password work with the cadaver command line client and Keeweb with webdav. Any ideas what I might be doing wrong or how I can debug this?

Workaround

For now I've found a work around for the shared link option. I already had a shared directory on my Nextcloud server that was served directly by Apache without going through Nextcloud. I created a randomly named sym-link in this directory that points to the kdbx file within the data directory of Nextcloud, so Tusk can bypass Nextcloud to GET the file.

The note on shared link URLs states that any direct HTTP link will do, but I found that part of the URL from Tusk is hard coded. I had to make a directory named random-string.kdbx, and in that directory I had to create a sym-link named download that points to the actual database file.

subdavis commented 6 years ago

thanks for the documentation. I seem to remember something like this but I don't remember the details.

Could you give me some more specifics?

What URL are you using as the shared URL? Feel free to mask any sensitive bits.
What URL are you using for the base WebDAV server? Again, mask it if you want.
This is all Tusk on Chrome, correct? Have you tried Firefox?
You found that part of the URL from tusk is "hard-coded" - this is a tricky problem. There's no way to "guess" that a URL comes from owncloud or nextcloud other than to notice that the path contains a 15 digit alphanumeric identifier, so Tusk looks for this. In shared URLs from own/nextcloud, you have to hit /{15-digit}/download to actually get the file, so tusk does this automatically. If you can make your URI path not contain that identifier, you won't have to do the download trick.

Is there anything special about your server setup? Any apache config where you do http/https redirects or any other rewrite rules that aren't standard?

alankeny commented 6 years ago

What URL are you using as the shared URL? Feel free to mask any sensitive bits.

Here's an example of sharing URL: https://cloud.******.net/s/5GwGLPfTDYBsEAf

What URL are you using for the base WebDAV server? Again, mask it if you want.

I tried two:

I saw the documentation about Tusk searching for *.kdbx files. That probably won't work with my usual account, because I have several large SMB shares mapped into the root of it. I tried the first URL, because I only wanted Tusk to search a single folder. When I got the 503 error, I tried the second URL, but got the same error. Based on the Apache log file, Tusk only made a single PROFIND request to the URL, failed with 503 error, and then it stopped.

I also tried creating a new Nextcloud test account from scratch. The kdbx file was the only file in the test account, but I got the same 503 error again.

This is all Tusk on Chrome, correct? Have you tried Firefox?

The shared link works in Firefox with no workarounds.

I also tested Firefox and Tusk with webdav. I used the test Nextcloud account with only the single kdbx file. After I hit the ADD button, I waited 2-3 minutes and then I got the error "TypeError: NetworkError when attempting to fetch resource" next to the "WebDAV (beta)" label on the manage databases page.

I'm looking into Tusk specifically for Chromebook users. Firefox is OK for testing and comparisons, but I'd still like to find a way to get Chrome to work without the workaround.

You found that part of the URL from tusk is "hard-coded" - this is a tricky problem.

The sharing URLs are randomly generated by Nextcloud. I can't change them without modifying the code. I'd prefer that no guessing or modifications take place at all. Just use the URL at it's entered in the field. Maybe add a note that Owncloud / Nextcloud users might need to add /download to the end of shared links.

Is there anything special about your server setup? Any apache config where you do http/https redirects or any other rewrite rules that aren't standard?

No, it's a fairly stock Apache + Nextcloud installation that's configured for HTTPS. The Chrome profile is also new, so it only has the Tusk extension.

mrozanc commented 6 years ago

Hello, I have the same issue: HTTP 503 on PROPFIND request. I tried to reproduce this error using another HTTP client. I think it may be a cookie issue as I can reproduce the issue using both basic auth with the account I use to store the keepass file and the cookie I use to login to the Nextcloud interface. No isssue on a request without cookie.

This error can be avoided if the extension's request does not use the brower's cookies.

fmunch commented 6 years ago

The issue seems to come from Nextcloud. Adding '/^Mozilla/' in this list fixes it: https://github.com/nextcloud/server/blob/v13.0.6/lib/base.php#L537-L548

I am only using WebDAV for Tusk so this is not a problem for me, but it might break other implementations since /^Mozilla/ has a really wide spectrum.

Not sure what the long term solution could be.

fmunch commented 6 years ago

Nextcloud 14 will add a property to configure the list of user agents: https://github.com/nextcloud/server/commit/c79dc0e08f9234739eccf07e13b971aa4664d86f So a workaround would just be to wait for Nextcloud 14 and configure it accordingly. And if Tusk had its own user agent it would allow to use a narrower regex (instead of /^Mozilla/), but I don't know if that is possible.

Or maybe does it come from the WebDAV client? Does it just lack support for the CSRF cookie that Nextcloud is expecting?

subdavis commented 6 years ago

Update: I've got a basic workaround for this :)

To prevent the browser from sending cookies with fetch, {credentials:'omit'} can be passed as an option to window.fetch. I'll have to get some changes into https://github.com/perry-mitchell/webdav-client because that library disregards custom options right now.

https://developer.mozilla.org/en-US/docs/Web/API/Request/credentials has more info about the fetch options.

subdavis / Tusk