centralathtoken parameter allows you to log in to the api as a different user for just that request. Since each user can load custom js, this means that malicious user's custom js will be run when looking at the help page. The malicious js can make further ajax requests without the centralauthtoken parameter, thus doing actions on the original users behalf.
Attack steps:
- Mallory sets his [[Special:MyPage/apioutput.js]] to something like $.post( '/w/api.php?format=json&meta=userinfo|tokens&action=query', function(r) { alert(r.query.userinfo.name + ' has token ' + r.query.tokens.csrftoken ) } );
- Alice is logged in to wiki
- Alice visits Mallory's (external website)
- Mallory on the server side (logged into his account) does api.php?action=centralauthtoken&format=json
- Mallory redirects Alice to api.php?centralauthtoken=<Foo>
- This page loads for Alice as being under Mallory's account. Critically, User:Mallory/apioutput.js is executed
- The Script on User:Mallory/apioutput.js makes a post request to the API (without centralauthtoken) fetching tokens. Since Alice is looged in, this runs under Alice's account. Since this is the same origin, Mallory now has Alice's token, and can otherwise take actions on Alice's behalf
The easiest way to test this is to log in on one account to test.wikipedia.org, and a different account on say en.wikivoyage.org. Modify the js for the user being used on wikivoyage on test, Get the centralauthtoken from wikivoyage, and then load the page using the central auth token on test and watch the attack.