Page MenuHomePhabricator

"Protected" status should not be disclosed on otherwise private filters
Closed, DeclinedPublicSecurity

Description

Currently, all people with the right to view filters also can see if a filter is marked as protected. This is problematic, since it allows abusers who trip private LTA filters to know that specific IP ranges are being targeted, allowing for easier evasion. Instead, the status of a private filter as protected should only be accessible to those who have the ability to view both private and protected filters.

To reproduce the issue, go on any Wikimedia project where autoconfirmed users can view filters, log in as an administrator, mark as filter as both protected and private, and switch to a non-admin AC account.

Details

Risk Rating
Low
Author Affiliation
Wikimedia Communities

Event Timeline

This got brought up on the Wikipedia-en-editfilters mailing list.

I do believe we should probably redact the "Protected" flag whenever:

  1. a filter is marked as private; and
  2. the viewing user doesn't have abusefilter-modify/abusefilter-view-private/abusefilter-log-private permissions.

Because even just showing that it's protected can give away a bit too much info about the filter, something that tech-savvy vandals might be able to use, and we probably don’t want that.

This is problematic, since it allows abusers who trip private LTA filters to know that specific IP ranges are being targeted, allowing for easier evasion

This isn't necessarily the case. Protected filters may no longer contain specific IP ranges and/or could just use IPReputation AbuseFilter variables (which are also only usable in a protected filter).

If a user tries to open a protected AbuseFilter we may also indicate to the user that they cannot access it because they lack the ability to see protected AbuseFilters, which would make the proposed idea here not solve the problem statement.


I personally don't see the "protected" flag being shown as something that should be hidden. While I see an LTA might guess that IP ranges are being used, they won't be able to guess what ranges these are. Furthermore, they could always just trial-and-error their way around it by testing out an IP outside the range that was provided. With that, and the idea that "protected" != "uses IPs in conditions", I would suggest against implementing this task.

I agree with @Dreamy_Jazz. Additionally, protected filters aren't guaranteed to contain protected variables as the protected status persists even after the protected variables are no longer being used in the filter. If we're willing to label filters as LTA specific and publicly show that they're private, then I think we can treat protected filters similarly.

Unless there is significant disagreement with the above, I propose to decline this task and make it public. I will give a couple of days for this for a chance for others to respond.

sbassett subscribed.

Unless there is significant disagreement with the above, I propose to decline this task and make it public. I will give a couple of days for this for a chance for others to respond.

I think that's fine.

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".
sbassett changed the edit policy from "Custom Policy" to "All Users".
sbassett changed Risk Rating from N/A to Low.
sbassett edited projects, added: SecTeam-Processed; removed: Security, Security-Team.