The API (api.php) in previous versions of MediaWiki sends private cache headers by default for almost all API operations, but allows public cache headers to be sent if they are requested via URL or POST data parameters. We have discovered that this policy allows leakage of private data, if an attacker can access the wiki through the same caching HTTP proxy as the victim user.
A user's browser can be tricked into requesting private data with public caching headers, via a CSRF-style attack on an external web page. The attacker would cause the victim's browser to request private data with public caching headers, then the attacker would download the same data from the intermediate HTTP proxy, bypassing access controls.
The kinds of things that may be leaked by this bug are:
- Article titles and contents (if these are restricted)
- The contents of deleted articles
- User email addresses
- User watchlists
The following types of data are not affected and cannot be leaked by this bug:
- User passwords
- Session IDs
- The contents of uploaded files
The main mitigating factor is the need for an HTTP proxy to be shared between the victim and the attacker. However, we believe that some hosting providers use caching HTTP proxies to improve performance, without informing their users that they are doing so. Thus we advise all MediaWiki users to upgrade, unless they control both the server and the network path to the wiki's users, and are convinced that there are no HTTP proxies on that network path.
Our fix will be included in MediaWiki 1.15.5 and 1.16.0. The following versions are affected:
- All versions from MediaWiki 1.8 to 1.14. Note that in MediaWiki 1.8, the API was disabled by default, this would mitigate the attack.
- MediaWiki 1.15.0 to 1.15.4.
- All beta versions in the MediaWiki 1.16 series.
Our fix is comprehensive: it disables public caching for all API modules except those which explicitly declare their data to be public. On private wikis, all responses will be marked private.