Big data loss on WEBDAV MOVE

[Lionel VEST]

Hi,

I implemented some WEBDAV function in my software using the SABREDAV CLIENT

We just encountered this morning an odd bug that deleted 6Gb of data (hopefully we had a backup)

Here's the PHP code :

$response = $client->request('MOVE', '/files/user/DOSSIERS/test',null, ['Destination' => '/files/user/DOSSIERS/' . $newname]);

In this case the user didn't input $newname so the executed command was : 

$response = $client->request('MOVE', '/files/user/DOSSIERS/test',null, ['Destination' => '/files/user/DOSSIERS/']);

You can think that this command returns an error.
It is in fact the case : ERROR 404

BUT !

This command deletes the whole ==DOSSIERS== folder including every subfolders and files in it !!

THIS IS VERY VERY DANGEROUS !

Is this the expected behaviour ?

[Evert Pot]

Hi Lionel,

On Tuesday, January 3, 2017 at 6:18:27 PM UTC-5, Lionel VEST wrote:

Hi,

I implemented some WEBDAV function in my software using the SABREDAV CLIENT

We just encountered this morning an odd bug that deleted 6Gb of data (hopefully we had a backup)

Here's the PHP code :

$response = $client->request('MOVE', '/files/user/DOSSIERS/test',null, ['Destination' => '/files/user/DOSSIERS/' . $newname]);

In this case the user didn't input $newname so the executed command was : 

$response = $client->request('MOVE', '/files/user/DOSSIERS/test',null, ['Destination' => '/files/user/DOSSIERS/']);

This is definitely not expected. Which WebDAV server software are you using? The expected behavior in this case is that the server should emit a 409 Conflict, and not make *any* changes.

Evert

[Lionel VEST]

I'm using SABREDAV 3.2 as server

[Evert Pot]

On Wednesday, January 4, 2017 at 4:11:10 PM UTC-5, Lionel VEST wrote:

I'm using SABREDAV 3.2 as server

I'm looking at the source, and it's definitely starting to look like that this is a sabre/dav bug.

The situation we check for is if you take a resource and move it into a subtree of itself, but what's not checked is if a resource overwrites its own parent. Because this check doesn't exist, we first delete the target node and then try to move the source node into the place of the target node.

Because the source node gets deleted during step 1, it can no longer be moved during step 2.

I'm opening a new ticket for this. As an aside, I really think you should specify the 'Overwrite: F' HTTP header as this would have prevented this problem. If you allow your users to rename resources, it might be nice to protect them from overwriting existing ones.

Evert