WebDav should prioritise auth header over cookie

[dareid]

Steps to reproduce

1. Perform action via webdav using auth header of user 1
2. Perform action via wedbav using auth header of user 2

Expected behaviour

User 2's auth header should take priority of user 1's cookie.

Actual behaviour

The cookie takes priority

Reasoning

Based on the webdav spec the auth header should be the primary authentication method (http://www.webdav.org/specs/rfc4918.html#rfc.section.20.1). In addition, there is no way to 'logout' a user in webdav, so no way to remove their cookie.

[MorrisJobke]

cc @LukasReschke

[MorrisJobke]

In addition, there is no way to 'logout' a user in webdav, so no way to remove their cookie.

What about just not send the cookie in the request?

[DeepDiver1975]

What about just not send the cookie in the request?

Not that easy in case the request is sent from a browser because cookies are sent by default

[dareid]

This cannot be controlled from javascript, browsers will automatically send any appropriate cookies.

[LukasReschke]

We could compare the login name in the session with the auth header.

However, there is a reason behind this behaviour: Everybody can force your browser to send authentication headers, thus this leads to a login/logout CSRF.

Imagine the following scenario;

1. Victim login to his ownCloud instance via Web
2. Attacker has an account as well and creates a similar folder structure (for example because he saw it in a beamer)
3. Attacker sends links to Victim which will log-out the user Victim and login him as user "Attacker"
4. If Victim now uploads files via the webinterface they will be uploaded as Attacker.
5. User Attacker can now access your uploaded data.

Thus we should revoke the session only if it was initially started via DAV.

[LukasReschke]

I can look at that next week.

[DeepDiver1975]

sounds like an issue to be solved within 8.0

[PVince81]

Ouch, I wonder if it's the reason why third party WebDAV clients are having issues with that:
#11400

[LukasReschke]

Fix is at #13416 – please test and report back.