A "fun" little thing I noticed while implementing {T227345} for #SocialProfile: a bunch of special pages which allow the user to perform database-altering write actions correctly check that the request was POSTed but totally lack a token check, making them vulnerable to CSRF.
Affected special pages (and their subcomponents in the `/extensions/SocialProfile` dir):
* Special:PopulateAwards (SystemGifts)
** This is just scary. The special page should probably implement a "Are you sure you wanna do this?" screen (which would contain the form containing the anti-CSRF token) instead of running the operation right away.
* Special:RemoveMasterSystemGift (SystemGifts)
* Special:SystemGiftManager (SystemGifts)
* //Special:SystemGiftManagerLogo// (SystemGifts)
* Special:SendBoardBlast (UserBoard)
* Special:GiftManager (UserGifts)
* //Special:GiftManagerLogo// (UserGifts)
* Special:GiveGift (UserGifts)
* Special:RemoveGift (UserGifts)
* Special:RemoveMasterGift (UserGifts)
* Special:AddRelationship (UserRelationship)
* Special:RemoveRelationship (UserRelationship)
* Special:ViewRelationshipRequests (UserRelationship) or rather, the backend code (API module, `/extensions/SocialProfile/UserRelationship/includes/api/ApiRelationshipResponse.php` and the JS code calling it in `/extensions/SocialProfile/UserRelationship/resources/js/UserRelationship.js` -- JS should use `( new mw.Api() ).postWithToken( 'csrf', { ... } );` like how #VoteNY and such tools use to implement appropriate anti-CSRF measures)
* Special:EditProfile (UserProfile)
* Special:PopulateExistingUsersProfiles (UserProfile)
** Literally equally scary and problematic as SystemGifts' Special:PopulateAwards page and needs similar changes
* Special:RemoveAvatar (UserProfile)
* Special:ToggleUserPage
** Previously/first reported in August 2018 as {T202272} (public task)
* Special:UpdateProfile (UserProfile)
* Special:GenerateTopUsersReport (UserStats)
** It's just like Special:PopulateAwards or Special:PopulateExistingUsersProfiles
* Special:UpdateEditCounts
** Scary like Special:PopulateAwards, Special:PopulateExistingUsersProfiles & Special:PopulateAwards and could use a confirmation screen
I didn't check the uploading special pages (//italicized// above) too closely, but they probably are also vulnerable as Special:Upload (from which those are derived, originally anyway) started requiring the CSRF token around MW 1.18/1.19; Special:UploadAvatar, the user-oriented special page for uploading an avatar, **does** implement anti-CSRF measures properly.
I will start working on this once the work on T227345 is complete as the changes needed in SocialProfile for that task are best described as "massive", whereas this task should be //relatively// straightforward and easy to implement (much like T241735).