Change Details

==== 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 likely been an issue since the `abusefiltercheckmatch` API was added to #AbuseFilter, but I will investigate this further. ==== 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.

==== 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 b30697e94cec5e4005f537981db702ee30da6ae8 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.

==== 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 likely been an issue problem since the `abusefiltercheckmatch` API was added to #AbuseFiltere before REL1_19, but I will investigate this furtheras the code in b30697e94cec5e4005f537981db702ee30da6ae8 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.