Page MenuHomePhabricator

Separate access to tools and test features from ability to view private filters
Open, LowestPublicSecurity

Description

As a user who does not have access to view private filters on some wikis,
It should be possible for users who cannot view private filters to be able to use the /test and /tools abuse filter features

Currently, AbuseFilter::canViewPrivate is used to restrict access to the tools and test utilities.
As noted in {T230320}, "private" is the highest (and only) possible restriction on viewing abuse filters.
In a vein similar to T230103: Systematize wgRestrictionLevels, the ability to use /test and /tools should not be restricted based on other rights.

Proposal: Create a new right (or two?) abusefilter-test, to be able to use the /test and /tools utilities.
Just as abusefilter-modify implies abusefilter-view-private, both should imply abusefilter-test for backwards compatibility (at least for now)

Filed as a security task in case there are security issues pertinent to expanding access, given that the views are restricted in the first place

Details

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
DannyS712 changed Author Affiliation from N/A to Wikimedia Communities.
DannyS712 added subscribers: Daimona, Huji, Urbanecm.

Why is this security?

"Filed as a security task in case there are security issues pertinent to expanding access, given that the views are restricted in the first place" - I don't have access to security tasks, so I don't know the full history / can't tell if there is some other issue that may be relevant. Filed as security to err on the side of caution.

Thanks, missed that. @Daimona and @sbassett , what do you think?

I think it's good to have this task protected as sectask as a precaution. However, I don't really think it should stay protected. I believe there's nothing exploitable in the various test features, as they don't give any access to private filters, in any way. Either way, it'd be good to have Scott or someone else on the Sec Team speak their mind.

As for the subject of the task, I'm fine with that, we can introduce a new right (as long as the change is back-compat for WMF wikis).

Daimona triaged this task as Lowest priority.Sep 16 2020, 1:32 PM
Daimona moved this task from Backlog to Discussion on the AbuseFilter (Overhaul-2020) board.

Just want to note that the restrictions on access to /test separate from the ability to view private filters came up in a discussion at https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Edit_filter_helper#Nomination_requirement? - allowing a separate right would make it easier to expand access to the testing interface without the potential consequences of expanding access to viewing private filters.

I think it's good to have this task protected as sectask as a precaution. However, I don't really think it should stay protected. I believe there's nothing exploitable in the various test features, as they don't give any access to private filters, in any way. Either way, it'd be good to have Scott or someone else on the Sec Team speak their mind.

{{ping}} any objections to making this public @sbassett?

{{ping}} any objections to making this public @sbassett?

None from me. I agree with @Daimona that the task and the proposed solution do not expose anything particularly security-sensitive and/or not already-known by interested parties. I'll make this task public now.

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".Jan 5 2021, 8:07 PM

The only concern that came up on the enwp discussion was to ensure that someone could not overload the tool with either rate or size of test cases, with a corresponding effect on the wiki itself since the tool does run the regex against the live database. So some sort of rate limit or query condition limit may be desirable.

JJMC89 added a subscriber: JJMC89.

Please reset the edit policy.

Legoktm changed the edit policy from "Custom Policy" to "All Users".Jan 8 2021, 1:14 AM

Instead of a rate limit, what if unprivileged uses of /test were limited to at most N cores and M bytes of memory? Then the only "service" anyone could "deny" is /test itself, which doesn't seem like a worthwhile target. Something similar is done with regex and Special:Search, if I recall.

Change 665374 had a related patch set uploaded (by Matěj Suchánek; owner: Matěj Suchánek):
[mediawiki/extensions/AbuseFilter@master] Use a new method for using

https://gerrit.wikimedia.org/r/665374

As a reminder, Special:AbuseFilter/test still allows you to view private filters with a URL like https://en.wikipedia.org/wiki/Special:AbuseFilter/test/2.

As a reminder, Special:AbuseFilter/test still allows you to view private filters with a URL like https://en.wikipedia.org/wiki/Special:AbuseFilter/test/2.

But only if you have abusefilter-modify or abusefilter-view-private.

@sbassett: I thought the idea was to have canTestTools(), in the future, also allow users some new right (abusefilter-test, etc.). If that's done, then users with that new right will also be able to view private filters, with an URL like the one above.

Not saying anything is broken now, or even with this patch.

Not saying anything is broken now, or even with this patch.

Right, I just wanted to avoid any confusion if someone thought /test wasn't currently locked down via af user rights.

Change 665374 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@master] Create a new method for authorizing access to test tools

https://gerrit.wikimedia.org/r/665374