search

owncloud / brute_force_protection

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

public link that are read and write , the user problem creates a folder #146

Closed ugliola closed 3 years ago

ugliola commented 3 years ago

When creating a public link giving read and write rights, the user is able to upload files but if he creates a folder he receives this error: This folder is not available, check the logs or contact the administrator. On the ChRome console it gives me this message: Failed to load resource: the server responded with a status of 500 (Internal Server Error) We noticed that disabling the problem does not arise. The problem arises when creating the folder at that point if I try to reconnect to the public link it tells me too many failed attempts Regards. My version
Brute-Force Protection 1.1.0 ownCloud 10.5

phil-davis commented 3 years ago

I added some more test scenarios to our automated tests. https://github.com/owncloud/brute_force_protection/pull/147/files#diff-467fe5dacf3d45d2c76340b32dd78152e561776477de18011e7854a7c1c29e3cR129

Creating a folder inside a password-protected public link shared folder works with brute_force_protection enabled. If you try a few times with the wrong password then brute_force_protection correctly locks out access for some time.

I also tried with a public link shared folder that has no password, and creating a folder works in that case also.

Please share more details of what you are doing to get this error.

phil-davis commented 3 years ago

OK - I ran the test with oC10 server 10.5.0 and brute_force_protection and get the 500 error. It happens on the 3rd request with a wrong password. That is when brute_force_protection reaches its trigger point to start blocking.

Feature: brute force protection

  As an administrator
  I want to be able to lock out users after multiple failed login attempts
  So that the server is protected against brute force password attacks

  Background:                                                           # /home/phil/git/owncloud/core/apps-external/brute_force_protection/tests/acceptance/features/apiBruteForceProtection/bruteforceprotection.feature:8
    Given these users have been created with skeleton files:            # FeatureContext::theseUsersHaveBeenCreated()
      | username |
      | Alice    |
    And the administrator has set the bruteforceprotection settings to: # BruteForceProtectionContext::setTheBruteforceprotectionSettings()
      | threshold-time | 60  |
      | fail-tolerance | 2   |
      | ban-period     | 300 |

  Scenario: access to create a folder in a public link folder is blocked after too many invalid requests                                                                           # /home/phil/git/owncloud/core/apps-external/brute_force_protection/tests/acceptance/features/apiBruteForceProtection/bruteforceprotection.feature:124
    When user "Alice" creates a public link share using the sharing API with settings                                                                                              # FeatureContext::userCreatesAPublicLinkShareWithSettings()
      | path        | PARENT      |
      | password    | %public%    |
      | permissions | read,create |
    Then the public should be able to create folder "new-folder" in the last public shared folder using the new public WebDAV API with password "%public%"                         # PublicWebDavContext::publicShouldBeAbleToCreateFolderWithPassword()
    And the public creation of folder "a-folder" in the last public shared folder using the new public WebDAV API with password "abcdef" should fail with HTTP status code "401"   # PublicWebDavContext::publicCreationOfFolderWithPasswordShouldFail()
    And the public creation of folder "a-folder" in the last public shared folder using the new public WebDAV API with password "123abc" should fail with HTTP status code "401"   # PublicWebDavContext::publicCreationOfFolderWithPasswordShouldFail()
    And the public creation of folder "a-folder" in the last public shared folder using the new public WebDAV API with password "abc123" should fail with HTTP status code "401"   # PublicWebDavContext::publicCreationOfFolderWithPasswordShouldFail()
      creation of a-folder in the last publicly shared folder should have failed with code 401
      Failed asserting that 500 matches expected '401'.
    And the public creation of folder "a-folder" in the last public shared folder using the new public WebDAV API with password "%public%" should fail with HTTP status code "401" # PublicWebDavContext::publicCreationOfFolderWithPasswordShouldFail()

--- Failed scenarios:

    /home/phil/git/owncloud/core/apps-external/brute_force_protection/tests/acceptance/features/apiBruteForceProtection/bruteforceprotection.feature:124

1 scenario (1 failed)
8 steps (6 passed, 1 failed, 1 skipped)
0m22.98s (16.27Mb)
phil-davis commented 3 years ago

This looks like issue #112 which is fixed by some oC10 core changes in PR https://github.com/owncloud/core/pull/37948

The fix will be released in oC10 10.6.0 which currently has an RC2 in QA.

I expect that the fix will fix your problem, because I can reproduce the problem with oC10.5 and the test passes in CI with current oC10.6 code.

Thanks for reporting - it made me write some extra test scenarios to cover the folder-creation scenarios!

ugliola commented 3 years ago

Hi Phill, You said that: "K - I ran the test with oC10 server 10.5.0 and brute_force_protection and get the 500 error. It happens on the 3rd request with a wrong password. That is when brute_force_protection reaches its trigger point to start blocking."

I am not mistaken the password but it is probably misinterpreted and seen as a bad password. So we need to update ownCloud to version 10.6.0 to fix the problem?

phil-davis commented 3 years ago

ownCloud 10.6.0 has not been released yet. So you cannot upgrade just yet!

But if you provide the correct password then there should be no problem. Have you made a password that has special characters in it? Iff so, it might be easier to have a plain-ASCII password.

ugliola commented 3 years ago

Hi, Have you made a password that has special characters in it? Yes I set the special characters in policy password. Do you want me to try to remove the special characters in the password?

phil-davis commented 3 years ago

Depending how "special" the characters are that you used, it might be difficult to actually enter the password correctly - e.g. if you have put some other script (Arabic, Chinese, Hindi...) Or things like a forward slash / might be not read successfully in a password.

If possible, try different "special" passwords and let me know what character is causing the problem.

ugliola commented 3 years ago

Hi, I try create password without special characters but I have same error. Dario

karakayasemi commented 3 years ago

The problem probably will be fixed with https://github.com/owncloud/core/pull/38016. The core was emiting wrong failed.password event in public link auths before https://github.com/owncloud/core/pull/38016. It will be also released in ownCloud 10.6.0. As a quick solution, you can apply the patch to your instance to check result or you can wait for the oc 10.6. Thank you for reporting.

karakayasemi commented 3 years ago

@ugliola please test the issue with oc10.6. If it still happens, please add a comment and re-open the issue. Closing for now. Thanks.