Username enumeration using PROPFIND requests

[C0rby]

An authenticated user can enumerate usernames by sending PROPFIND requests.

~
❯ curl -k -s -u einstein:relativity -X PROPFIND https://localhost:9200/remote.php/dav/files/admin
<?xml version="1.0" encoding="UTF-8"?>
<d:error xmlns:d="DAV" xmlns:s="http://sabredav.org/ns"><s:exception>Sabre\DAV\Exception\NotFound</s:exception><s:message>Resource /users/ddc2004c-0977-11eb-9d3f-a793888cd0f8 not found</s:message></d:error>
                              
~
❯ curl -k -s -u einstein:relativity -X PROPFIND https://localhost:9200/remote.php/dav/files/notexists
<?xml version="1.0" encoding="UTF-8"?>
<d:error xmlns:d="DAV" xmlns:s="http://sabredav.org/ns"><s:exception>Sabre\DAV\Exception\NotFound</s:exception><s:message>Resource /users/notexists not found</s:message></d:error>

The error message of an existing user contains the users uuid whereas for a non existing user it returns the requested username.

[phil-davis]

PR #3564 added scenarios to expected-failures with a link to this issue. So I am reopening the issue and adding to the QA project.

ToDo:

• investigate exactly how the related scenarios started to fail
• if the failures are real (if the system-under-test does not behave correctly) then raise a separate issue with details of what exactly is failing
• if the system-under-test now behaves correctly "to specification", then sort out the tests so that they correctly expect the behavior

Note: we don't want to have links in expected-failures to issues that are closed.

[C0rby]

investigate exactly how the related scenarios started to fail

@kobergj changed the response message when a resource can not be found.
Before the message was something like: "Resource /users/ not found" but now it doesn't contain the path anymore, like this: "Resource not found".

if the system-under-test now behaves correctly "to specification", then sort out the tests so that they correctly expect the behavior

This is the case IMO and the tests just need to be updated.
Sorry, next time we'll ping someone from your team to coordinate the test updates instead of just adding them to the expected failures.

[phil-davis]

The commit id update in #3576 fixed the test problem in oCIS.

But I am getting a failure in reva. It looks like reva can still include the path.

apiWebdavProperties2/getFileProperties.feature:324 fails in reva.

[phil-davis]

apiWebdavProperties2/getFileProperties.feature:324 was removed from expected-failures in PR cs3org/reva#2780

[phil-davis]

@C0rby the 2 example curl commands now give the same answer on current ocis locally for me.

There are no expected-failures related to this issue.

IMO it is fixed. Close?

[C0rby]

Yes, this has been fixed here: cs3org/reva#2735