What is the problem?
For the API action abusefiltercheckmatch, I can check a pattern like user_unnamed_ip="1.2.3.4" against an AbuseFilter log entry that I don't have permission to see and, if I guess the right IP, it will return true. This applies more widely than protected filters, as this can be used to inspect the log details for logs created by private filters.
Although it requires you to guess IPs, you can use things like like and >, < in order to narrow it down.
This has been a problem since before REL1_19, as the code in rMRELb30697e94cec for the abusefiltercheckmatch API looks like it has the same problem of not checking the right.
Steps to reproduce problem
For protected filters
- Create an abuse filter with condition user_unnamed_ip.
- While logged out, perform an action like making an edit.
- Look in Special:AbuseLog to see the log for the action you made in step 2. Make a note of the log ID (which you will see in the URL of the links for details or examine).
- Login as an admin who does not have the abusefilter-access-protected-vars right.
- Go to Special:ApiSandbox#action=abusefiltercheckmatch&format=json&filter=user_unnamed_ip%3D%22%3Cip%3E%22.
- Fill out <ip> with the IP of the user from step 2. Fill out the logid parameter with the log ID from step 3. Submit.
Expected behaviour: The response from the API should say the user does not have the right to use protected variables.
Observed behaviour: A response:
{ "abusefiltercheckmatch": { "result": true } }
For private filters
- Create an abuse filter with the condition summary = 'should be private' and mark it as private
- Trigger the private filter by making an edit with the edit summary should be private
- Look in Special:AbuseLog to see the log for the action you made in step 2. Make a note of the log ID (which you will see in the URL of the links for details or examine).
- Login as an admin who does not have the abusefilter-log-detail right but has the abusefilter-modify right
- Go to Special:ApiSandbox#action=abusefiltercheckmatch&format=json.
- Set the filter argument as summary = 'should be private'
- Fill out the logid parameter with the log ID from step 3. Submit.
Expected behaviour: The response from the API should say the user does not have rights to see abusefilter log details
Observed behaviour: A response:
{ "abusefiltercheckmatch": { "result": true } }
Environment
Wiki(s): Abuse Filter – (f65ed2b) 07:22, 21 August 2024.