Last modified: 2011-11-28 23:40:24 UTC
action=ajax requests are dispatched to the relevant function without any read permission checks being done. This can lead to data leakage on private wikis. A quick survey of the many extensions which use action=ajax suggests that few, if any, have anticipated this security issue. This includes the popular CategoryTree extension, which can be used to obtain lists of page titles. The ExtTab and InlineEditor extensions appear to allow disclosure of the full text of the page. In the core, most former action=ajax uses have been migrated to api.php, however SpecialUpload::ajaxGetExistsWarning still remains, which allows confirmation of the existence of a given file upload, given the name. A dictionary attack could lead to significant data leakage. Previous versions of MediaWiki may have more severe vulnerabilities. I suggest denying all access to action=ajax for users without read permissions. If there are any extensions that really need to provide data from a private wiki to logged-out users, api.php can be used instead. It provides an opt-in model for bypassing read permissions.
Created attachment 9541 [details] Proposed patch
Is the "!in_array( 'read', User::getGroupPermissions( array( '*' ) )" a necessary logical component or an optimization to skip over the User::isAllowed() call in the common case of non-restricted sites? Might want to indicate if it's a shortcut in a comment so it doesn't get removed by some clever refactorer later. :)
The code was copied from ApiMain. It was introduced there in r62544 based on code from ApiOpenSearch r62540. It was described as an optimisation in the commit message on r62540.
The patch has been reviewed and sent to Sam Reed to prepare the new release. I think we agreed to release the new version on monday or tuesday because of thanksgiving in the US.
Fixed in trunk with r104505, 1.17 in r104506, 1.18 in r104508 and 1.18wmf1 in r104509
