search

owncloud / brute_force_protection

Brute-force protection app for ownCloud
GNU General Public License v2.0
6 stars 5 forks source link

apiBruteForceProtection/bruteforceprotection.feature:76-83 sometimes fail #168

Closed individual-it closed 2 years ago

individual-it commented 2 years ago

e.g https://drone.owncloud.com/owncloud/brute_force_protection/1720/15/11 or https://drone.owncloud.com/owncloud/brute_force_protection/1718 but pass on rerun https://drone.owncloud.com/owncloud/brute_force_protection/1719

phil-davis commented 2 years ago

These failed in a couple of nightly builds last week. For example: https://drone.owncloud.com/owncloud/brute_force_protection/1775/15/11

Scenario Outline: access is still possible from another IP after user/ip combination was blocked # /var/www/owncloud/testrunner/apps/brute_force_protection/tests/acceptance/features/apiBruteForceProtection/bruteforceprotection.feature:67
    When the client accesses the server from IP address "10.4.1.248" using X-Forwarded-For header  # IpContext::theClientAccessesTheServerFromIpAddressUsingXForwardedForHeader()
    And user "Alice" sends HTTP method "<method>" to URL "<endpoint>" with password "notvalid"     # FeatureContext::userSendsHTTPMethodToUrlWithPassword()
    And user "Alice" sends HTTP method "<method>" to URL "<endpoint>" with password "notvalid"     # FeatureContext::userSendsHTTPMethodToUrlWithPassword()
    And the client accesses the server from IP address "192.168.56.1" using X-Forwarded-For header # IpContext::theClientAccessesTheServerFromIpAddressUsingXForwardedForHeader()
    And user "Alice" sends HTTP method "<method>" to URL "<endpoint>"                              # FeatureContext::userSendsHTTPMethodToUrl()
    Then the HTTP status code should be "<http-code>"                                              # FeatureContext::thenTheHTTPStatusCodeShouldBe()

    Examples:
      | method   | endpoint                                | http-code |
      | GET      | /index.php/apps/files                   | 200       |
        HTTP status code 403 is not the expected value 200
        Failed asserting that 403 matches expected '200'.
      | PROPFIND | /remote.php/dav/systemtags              | 207       |
        HTTP status code 401 is not the expected value 207
        Failed asserting that 401 matches expected '207'.
      | PROPFIND | /remote.php/dav/files/Alice/welcome.txt | 207       |
        HTTP status code 401 is not the expected value 207
        Failed asserting that 401 matches expected '207'.
      | GET      | /remote.php/dav/files/Alice/welcome.txt | 200       |
        HTTP status code 401 is not the expected value 200
        Failed asserting that 401 matches expected '200'.
      | PROPFIND | /remote.php/webdav/welcome.txt          | 207       |
        HTTP status code 401 is not the expected value 207
        Failed asserting that 401 matches expected '207'.
      | GET      | /remote.php/webdav/welcome.txt          | 200       |
        HTTP status code 401 is not the expected value 200
        Failed asserting that 401 matches expected '200'.
      | MKCOL    | /remote.php/dav/files/Alice/blocked     | 201       |
        HTTP status code 401 is not the expected value 201
        Failed asserting that 401 matches expected '201'.
      | MKCOL    | /remote.php/webdav/blocked              | 201       |
        HTTP status code 401 is not the expected value 201
        Failed asserting that 401 matches expected '201'.

We should think how to make these reliable in CI - look at what network things the tests depend on and try to minimize the dependency on particular network addresses...

amrita-shrestha commented 2 years ago

In my local setup, apiBruteForceProtection/bruteforceprotection.feature:76-83 doesn't pass in 50-80 test run . on ci https://github.com/owncloud/brute_force_protection/pull/170 , I tried different combinations of passing test scenarios with apiBruteForceProtection/bruteforceprotection.feature:76-83

Through the curl command ,

kiranparajuli589 commented 2 years ago

latest build failure: https://drone.owncloud.com/owncloud/brute_force_protection/1804/15/11

saw-jan commented 2 years ago

Failed today as well: https://drone.owncloud.com/owncloud/brute_force_protection/1846/14/11

individual-it commented 2 years ago

any progress in investigating why this is happening?

kiranparajuli589 commented 2 years ago

This fails every time in my local machine as it is failing intermittently in the CI.

  1. When client accesses the server from IP address "10.4.1.248" two times with invalid auth

    More details 
    MKCOL /owncloud/core/remote.php/webdav/blocked HTTP/1.1
Host: localhost
User-Agent: GuzzleHttp/7
Authorization: Basic QWxpY2U6bm90dmFsaWQ=
X-Forwarded-For: 10.4.1.248

HTTP/1.1 401 Unauthorized
Date: Thu, 31 Mar 2022 09:47:33 GMT
Server: Apache/2.4.41 (Ubuntu)
Set-Cookie: oc7epvr9s2gv=kuk26ulhl0bnddh6b8t26040qt; path=/owncloud/core; HttpOnly; SameSite=Strict
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: oc_sessionPassphrase=Jfcj6oztUN2uTx9uN6l46sD%2BF%2Fwxm6kUHD0H6zzUXPw7r3rDBpyzqP8nVC932ypv5iQcGA52F%2FHXIBSWrn4IZSMByDBzq7PzadhKopeOLVbUn%2B1j%2B80xbi%2BpusJI75k3; path=/owncloud/core; HttpOnly; SameSite=Strict
Content-Security-Policy: default-src 'none';
X-XSS-Protection: 0
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Robots-Tag: none
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
Set-Cookie: oc7epvr9s2gv=k4gbf07m17nfcpabgmkojgv52i; path=/owncloud/core; HttpOnly; SameSite=Strict
WWW-Authenticate: Basic realm="ownCloud", charset="UTF-8"
WWW-Authenticate: Bearer realm="ownCloud"
Content-Length: 379
Content-Type: application/xml; charset=utf-8



  Sabre\DAV\Exception\NotAuthenticated
  Username or password was incorrect, Username or password was incorrect, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured

  2. Now the client again accesses the server from IP address "192.168.56.1" using X-Forwarded-For header with valid auth, the request fails with

I need some help on how to proceed on this.

phil-davis commented 2 years ago

Failed again last night: https://drone.owncloud.com/owncloud/brute_force_protection/1860/14/11

kiranparajuli589 commented 2 years ago

The reported tests are now

closing for now. this can be reopened if the issue appears again.

phil-davis commented 2 years ago

https://drone.owncloud.com/owncloud/brute_force_protection/1903/14/11

runsh: Total unexpected failed scenarios throughout the test run:
apiBruteForceProtection/bruteforceprotection.feature:76
apiBruteForceProtection/bruteforceprotection.feature:77
apiBruteForceProtection/bruteforceprotection.feature:78
apiBruteForceProtection/bruteforceprotection.feature:79
apiBruteForceProtection/bruteforceprotection.feature:80
apiBruteForceProtection/bruteforceprotection.feature:81
apiBruteForceProtection/bruteforceprotection.feature:82
apiBruteForceProtection/bruteforceprotection.feature:83

This is very hard to reproduce. Maybe we need to skip these in nightly runs, and just verify them when there is an app release?

I will think about it next week.

SwikritiT commented 2 years ago

Failing in today's nightly as well: https://drone.owncloud.com/owncloud/brute_force_protection/1908/14/11

apiBruteForceProtection/bruteforceprotection.feature:76
apiBruteForceProtection/bruteforceprotection.feature:77
apiBruteForceProtection/bruteforceprotection.feature:78
apiBruteForceProtection/bruteforceprotection.feature:79
apiBruteForceProtection/bruteforceprotection.feature:80
apiBruteForceProtection/bruteforceprotection.feature:81
apiBruteForceProtection/bruteforceprotection.feature:82
apiBruteForceProtection/bruteforceprotection.feature:83
SwikritiT commented 2 years ago

@phil-davis https://drone.owncloud.com/owncloud/brute_force_protection/1909/14/11 failed in today's nightly as well. What shall we do? Shall we skip the tests?

phil-davis commented 2 years ago

https://drone.owncloud.com/owncloud/brute_force_protection/1939/14/11

  Scenario Outline: access is still possible from another IP after user/ip combination was blocked # /var/www/owncloud/testrunner/apps/brute_force_protection/tests/acceptance/features/apiBruteForceProtection/bruteforceprotection.feature:67
    When the client accesses the server from IP address "10.4.1.248" using X-Forwarded-For header  # IpContext::theClientAccessesTheServerFromIpAddressUsingXForwardedForHeader()
    And user "Alice" sends HTTP method "<method>" to URL "<endpoint>" with password "notvalid"     # FeatureContext::userSendsHTTPMethodToUrlWithPassword()
    And user "Alice" sends HTTP method "<method>" to URL "<endpoint>" with password "notvalid"     # FeatureContext::userSendsHTTPMethodToUrlWithPassword()
    And the client accesses the server from IP address "192.168.56.1" using X-Forwarded-For header # IpContext::theClientAccessesTheServerFromIpAddressUsingXForwardedForHeader()
    And user "Alice" sends HTTP method "<method>" to URL "<endpoint>"                              # FeatureContext::userSendsHTTPMethodToUrl()
    Then the HTTP status code should be "<http-code>"                                              # FeatureContext::thenTheHTTPStatusCodeShouldBe()

    Examples:
      | method   | endpoint                                | http-code |
      | GET      | /index.php/apps/files                   | 200       |
        HTTP status code 403 is not the expected value 200
        Failed asserting that 403 matches expected '200'.
      | PROPFIND | /remote.php/dav/systemtags              | 207       |
        HTTP status code 401 is not the expected value 207
        Failed asserting that 401 matches expected '207'.
      | PROPFIND | /remote.php/dav/files/Alice/welcome.txt | 207       |
        HTTP status code 401 is not the expected value 207
        Failed asserting that 401 matches expected '207'.
      | GET      | /remote.php/dav/files/Alice/welcome.txt | 200       |
        HTTP status code 401 is not the expected value 200
        Failed asserting that 401 matches expected '200'.
      | PROPFIND | /remote.php/webdav/welcome.txt          | 207       |
        HTTP status code 401 is not the expected value 207
        Failed asserting that 401 matches expected '207'.
      | GET      | /remote.php/webdav/welcome.txt          | 200       |
        HTTP status code 401 is not the expected value 200
        Failed asserting that 401 matches expected '200'.
      | MKCOL    | /remote.php/dav/files/Alice/blocked     | 201       |
        HTTP status code 401 is not the expected value 201
        Failed asserting that 401 matches expected '201'.
      | MKCOL    | /remote.php/webdav/blocked              | 201       |
        HTTP status code 401 is not the expected value 201
        Failed asserting that 401 matches expected '201'.

Failed again last night. I will make a PR to skip these.

phil-davis commented 2 years ago

In test PR #178 I checked that the Apache config file was really getting the X-Forwarded-For settings, and that there was not some other Apache running that might have missed the settings. The Apache that is run in the server service is the one that the tests use.

Documentation of RemoteIPHeader X-Forwarded-For and RemoteIPInternalProxy and RemoteIPTrustedProxy indicates that the default is that all IP addresses are trusted if these Proxy settings are not set. So Apache should be always passing through the client IP address specified in X-Forwarded-For

I don't see anything special in the log of the Apache server process when these tests fail. So there is no obvious reason for the problem.

The tests are skipped in PR #179 - but they will still be in the test suite so that they can be run manually or semi-automatically in CI if and when we want to.

kiranparajuli589 commented 2 years ago

@phil-davis, after #179 can we close this ticket?

phil-davis commented 2 years ago

We have skipped these tests. Note: they can be run locally by specifically select the filter tag @blockBasedOnClientIpAddress