Sanitise the http requests

[vascoguita]

Add http.ServeMux to http server to sanitise http requests and mitigate XSS.
Use html.EscapeString whenever responding to an http request with user-provided values (internal/http/services/ocmd/invites.go and pkg/siteacc/siteacc.go).

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[lgtm-com]

This pull request fixes 3 alerts when merging defa86a into db57930 - view on LGTM.com

fixed alerts:

• 3 for Reflected cross-site scripting

[lgtm-com]

This pull request fixes 3 alerts when merging c1dd14e into db57930 - view on LGTM.com

fixed alerts:

• 3 for Reflected cross-site scripting

[lgtm-com]

This pull request fixes 3 alerts when merging ff4312e into e58cd30 - view on LGTM.com

fixed alerts:

• 3 for Reflected cross-site scripting

[lgtm-com]

This pull request fixes 3 alerts when merging 1802b1e into 1e4948b - view on LGTM.com

fixed alerts:

• 3 for Reflected cross-site scripting

[lgtm-com]

This pull request fixes 3 alerts when merging f463253 into 1e4948b - view on LGTM.com

fixed alerts:

• 3 for Reflected cross-site scripting

[phil-davis]

https://drone.cernbox.cern.ch/cs3org/reva/9096/10/6

Scenario: send DELETE requests to webDav endpoints with 2 slashes                                        # /drone/src/tmp/testrunner/tests/acceptance/features/apiAuthWebDav/webDavSpecialURLs.feature:13
    When user "Alice" requests these endpoints with "DELETE" using password "%regular%" about user "Alice" # OCSContext::userSendsRequestToTheseEndpointsWithOutBodyUsingPassword()
      | endpoint                                            |
      | //remote.php/webdav/textfile0.txt                   |
      | //remote.php//dav/files/%username%/textfile1.txt    |
      | /remote.php//dav/files/%username%/PARENT/parent.txt |
      | /remote.php//webdav/PARENT                          |
      | //remote.php/dav//files/%username%//FOLDER          |
    Then the HTTP status code of responses on all endpoints should be "204"                                # FeatureContext::theHTTPStatusCodeOfResponsesOnAllEndpointsShouldBe()
      Expected same but found different http status codes of last requested responses.Found status codes: 200,200,200,501,501 (Exception)

Those are examples of URLs that have multiple / in various places. They all pass on ownCloud10. The routing/URL-parsing manages to cope with it. But with the ServeMux changes here, it seems that ServeMux is not coping with the last 2 examples - it returns 501

In real life a client that sends such requests should be fixed anyway! So maybe you are OK with these odd-looking-URL tests failing. If so, then add them to the expected-failures files:
https://github.com/cs3org/reva/blob/master/tests/acceptance/expected-failures-on-OCIS-storage.md
https://github.com/cs3org/reva/blob/master/tests/acceptance/expected-failures-on-S3NG-storage.md

If not, then work out how ServeMux has to be set up so that it can understand and route these requests.

[phil-davis]

  Scenario: send PUT requests to webDav endpoints with 2 slashes                                                                       # /drone/src/tmp/testrunner/tests/acceptance/features/apiAuthWebDav/webDavSpecialURLs.feature:184
    When user "Alice" requests these endpoints with "PUT" including body "doesnotmatter" using password "%regular%" about user "Alice" # OCSContext::userSendsRequestToTheseEndpointsWithBodyUsingPassword()
      | endpoint                                             |
      | //remote.php/webdav/textfile0.txt                    |
      | /remote.php//webdav/textfile1.txt                    |
      | //remote.php//dav/files/%username%/textfile1.txt     |
      | /remote.php/dav/files/%username%/textfile7.txt       |
      | //remote.php/dav/files/%username%/PARENT//parent.txt |
    Then the HTTP status code of responses on all endpoints should be "204" or "201"                                                   # FeatureContext::theHTTPStatusCodeOfResponsesOnAllEndpointsShouldBeOr()
      Unexpected status code received 200

This one is strange - these PUT requests were returning 204 or 201, but now they return 200. Why is ServeMux processing these "OK" but returning a different 2xx HTTP status then the previous way it was done?

Again, add to expected failures if you do not care about this.

[phil-davis]

https://drone.cernbox.cern.ch/cs3org/reva/9096/12/6

Scenario: Copy file within a public link folder new public WebDAV API                         # /drone/src/tmp/testrunner/tests/acceptance/features/apiSharePublicLink2/copyFromPublicLink.feature:8
    Given user "Alice" has uploaded file with content "some data" to "/PARENT/testfile.txt"     # FeatureContext::userHasUploadedAFileWithContentTo()
    And user "Alice" has created a public link share with settings                              # FeatureContext::userHasCreatedAPublicLinkShareWithSettings()
      | path        | /PARENT                   |
      | permissions | read,update,create,delete |
    When the public copies file "/testfile.txt" to "/copy1.txt" using the new public WebDAV API # PublicWebDavContext::thePublicCopiesFileUsingTheWebDAVApi()
    Then the HTTP status code should be "201"                                                   # FeatureContext::thenTheHTTPStatusCodeShouldBe()
      HTTP status code 200 is not the expected value 201
      Failed asserting that 200 matches expected '201'.

The failures in this test pipeline are of real things. In this example the returned status has changed from 201 to 200 - maybe that is a real problem, or maybe no client will care.

But:

Scenario: Copy folder within a public link folder new public WebDAV API                                 # /drone/src/tmp/testrunner/tests/acceptance/features/apiSharePublicLink2/copyFromPublicLink.feature:20
    Given user "Alice" has created folder "/PARENT/testFolder"                                            # FeatureContext::userHasCreatedFolder()
    And user "Alice" has uploaded file with content "some data" to "/PARENT/testFolder/testfile.txt"      # FeatureContext::userHasUploadedAFileWithContentTo()
    And user "Alice" has created a public link share with settings                                        # FeatureContext::userHasCreatedAPublicLinkShareWithSettings()
      | path        | /PARENT                   |
      | permissions | read,update,create,delete |
    When the public copies folder "/testFolder" to "/testFolder-copy" using the new public WebDAV API     # PublicWebDavContext::thePublicCopiesFileUsingTheWebDAVApi()
    Then the HTTP status code should be "201"                                                             # FeatureContext::thenTheHTTPStatusCodeShouldBe()
      HTTP status code 501 is not the expected value 201
      Failed asserting that 501 matches expected '201'.

In this case, the receiver of a public link share is copying a folder that is inside the public link share, to create another folder inside the public link share. A 501 is returned, so the request is broken. That looks like it really needs to be fixed.

In a lot of the other failures in that pipeline, the request is returning 200 instead of a more-specific 2xx HTTP status code. So maybe there is something in ServeMux that is causing a "generic" 200 code to get returned?

[lgtm-com]

This pull request fixes 3 alerts when merging 181e1b4 into 0a5d64b - view on LGTM.com

fixed alerts:

• 3 for Reflected cross-site scripting