Abusefilter API does not check for abusefilter-view-private userright
Closed, ResolvedPublic


506 is a hidden filter on enwiki, which means I (not a sysop or EFM) cannot see https://en.wikipedia.org/wiki/Special:AbuseFilter/506. However, I can still see https://en.wikipedia.org/w/api.php?action=query&list=abuselog&aflfilter=506, which is basically the same content.

I'm marking this as major since it's another data leak.

Version: unspecified
Severity: major


bzimport set Reference to bz42814.
bzimport added a subscriber: Unknown Object (MLST).
Legoktm created this task.Dec 7 2012, 4:53 AM

I believe this just needs an additional security check in extensions/AbuseFilter/api/ApiQueryAbuseLog.php. It looks like there are already some permissions checks in place, but none for the "filter" prop. I'm marking this bug with the "easy" keyword as I don't believe adding a check should be very difficult.


I just filed a similar one at bug 42816, which deals which permissions of blocked users.

As I accidentally posted on bug 42816...

I think the basis of the leak is that the special page only filters the result
for a filter id if the user has the permission 'abusefilter-log-private' or
'abusefilter-view-private' (SpecialAbuseLog around line 225). The api doesn't
seem to check for this. Should be easy to check for.

Additionally, the api always lists the filter_id that triggered the log entry, whereas the special page gives the generic "an abuse filter".

Gerrit 37989

hoo added a comment.Dec 18 2012, 9:40 PM

Change tested and merged

hoo added a comment.Dec 18 2012, 9:54 PM

Reopened: I didn't notice that with aflprop=filter|action|details it's still possible to see information usually being hidden.

hoo added a comment.Dec 18 2012, 10:05 PM

Fixed in https://gerrit.wikimedia.org/r/39317 (tested). Please review

hoo added a comment.Dec 19 2012, 7:43 AM

Chris merged my patch... thanks :)

Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptJan 28 2016, 6:09 PM

Add Comment