[WIP] feat: implement brute force protection for public shares

[jvillafanez]

Description

Requires owncloud/reva#460

Configuration for the brute force protection from oCIS

Note that the authentication done in the middleware will be fully delegated to reva (related to #11862)

Related Issue

• Fixes <issue_link>

Motivation and Context

How Has This Been Tested?

Manually tested. After several failed attempts the access to the public share is blocked.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

Notes:

• Implementation for the brute force protection is in [WIP] feat: implement brute force protection for public links reva#460 . The behavior is also explained there.
• There is a known issue in web duplicating the requests (Password protected share gets authenticated twice web#13363) . This means that each failure will be counted as 2 until the fix is in place.
• Web isn't prepared yet for this feature and it will show a generic "unknown error". The request will fail with a 429 HTTP error if the resource is blocked.

[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.

[mmattel]

Will this go into Curie?
Mind to add some text to the readme describing the behavior?
(We also need a changelog)

[jvillafanez]

@kobergj there are some unit tests failing, likely caused by the change in the middleware here, so I'm not sure if we should remove those tests of explore a different solution.

[mmattel]

I have questions on the behavior:

1. One mad user can block the whole PL for the time defined.
2. If there is another user typing in the wrong pwd, the counter starts from the beginning.
3. No user can see when the blocking time ends.
4. No user can login even with a correct password if the treshold has been exeeded before.
5. Consequently, if a user would be able to login with the correct pwd (which is a violation of the description above), login would be reenabled for all.

[jvillafanez]

1. Technically yes. However, that could also be considered as an attack, which is what we want to prevent.
   Public links are intended for external anonymous access, and the security team decided that trying to block access by IP could be bypassed, so the access will be blocked for everyone, including regular logged-in users.
2. There is no counter. We're tracking the timestamp of each failed attempt (no longer useful data will be removed eventually) and ensuring that, given a duration, there are less than the maximum allowed failed attempts in it.
3. Correct. I'm not entirely sure how useful showing that information will be related to the effort to implement it. If we need to show an accurate information, we'll need to propagate the information from very deep; alternatively, we could show the worst case ("retry after one hour", by default). It could also give information to potential attackers. Definitely something to check with the security team.
4. Right. However, if a user could login with a correct password during the block, an attacker could keep trying passwords ignoring the block until he succeeds, which would defeat the purpose of the feature.
5. Point 4 explains it.

[kobergj]

1. Expected bahaviour. This is the point of the whole story
2. The counter should be global and not reset when another user enters a wrong password
3. Expected behaviour. We do not want attackers to automate waiting time between brute force attacks.
4. Expected behaviour. As stated above it would render the whole feature useless if we allow access to blocked resources.
5. NO user should be able to access the link while it is blocked due to an attack.

[mmattel]

Thanks for the insight 😄
Addon question:

6. If one has entered a valid pwd for the PL and accesses the resource and another user triggers the limit and blocks access, will the first user be kicked out?

[kobergj]

Depends. I would expect ongoing Office session to not break. But I would expect the user cannot upload/download the file from this point. @jvillafanez is this the actual behaviour?

[mmattel]

But I would expect the user cannot upload/download the file from this point.

Really? First you successfully login, then you cant do anything without being notified?

As logged in user, I would expect at least a notification on the screen. Then it would be ok.
Would this also affect any running up/download? Means, they will get interrupted and the session closed?

[kobergj]

First you successfully login

No login involved - this is about public links.

As logged in user, I would expect at least a notification on the screen.

Ideally yes - but from a security POV not needed.

Would this also affect any running up/download? Means, they will get interrupted and the session closed?

I would expect not. Once the download has started it uses a different sort of access token that is not bound to the user. So download should succeed. Not sure about Upload. Needs to be tested.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[kobergj]

@jvillafanez why is this unit test failing? Could we increase the threshold of failed tries to make this tests pass?

[jvillafanez]

https://github.com/owncloud/ocis/pull/11864/files#diff-6d13e529ff282391653d164b7fe8654c0580bf59dd90e7b81e26a2c84ad12a92L94-L122 is likely the cause. It was needed because there was a double authentication going on that was messing with the failure count (#11862)

Could we increase the threshold of failed tries to make this tests pass?

The feature is mainly in reva, and this PR doesn't update it, so there shouldn't be any brute force protection going on. This PR is mostly configuration for the reva service.

[jvillafanez]

I think I'll need to look at a different solution for the double authentication. There is a 401 error when trying to open a docx file from the public link with onlyoffice.

ocis-1          | {"level":"warn","service":"frontend","pkg":"rhttp","traceid":"15700baf3978712796c25f3a4cb33b8b","time":"2025-12-10T10:23:15Z","line":"/home/juan/src/ocis/ocis/vendor/github.com/owncloud/reva/v2/internal/http/interceptors/auth/auth.go:249","message":"core access token not set for URL /app/open"}
ocis-1          | {"level":"warn","service":"frontend","pkg":"rhttp","traceid":"15700baf3978712796c25f3a4cb33b8b","host":"127.0.0.1","method":"POST","uri":"/app/open?file_id=e704b38b-6725-4810-9084-dc95d02e62fc%24a73c6ea6-6e7c-103f-8110-dd19ecb0bb36%212f89376b-025c-46a3-833c-a7641d5b7c97&lang=en&mobile=0&app_name=ByCS-Office&view_mode=view","url":"/app/open?file_id=e704b38b-6725-4810-9084-dc95d02e62fc%24a73c6ea6-6e7c-103f-8110-dd19ecb0bb36%212f89376b-025c-46a3-833c-a7641d5b7c97&lang=en&mobile=0&app_name=ByCS-Office&view_mode=view","proto":"HTTP/1.1","status":401,"size":0,"start":"10/Dec/2025:10:23:15 +0000","end":"10/Dec/2025:10:23:15 +0000","time_ns":792645,"time":"2025-12-10T10:23:15Z","line":"/home/juan/src/ocis/ocis/vendor/github.com/owncloud/reva/v2/internal/http/interceptors/log/log.go:112","message":"http"}
ocis-1          | {"level":"info","service":"proxy","proto":"HTTP/1.1","request-id":"b6af202c-ac26-4c48-ad56-2dfd0bd9b87f","traceid":"dbff61fb90739a8cdd65f1baf01ed212","remote-addr":"10.0.2.28","method":"POST","status":401,"path":"/app/open","duration":14.99147,"bytes":0,"time":"2025-12-10T10:23:15Z","line":"/home/juan/src/ocis/ocis/services/proxy/pkg/middleware/accesslog.go:34","message":"access-log"}