Last modified: 2012-03-22 19:46:50 UTC
Created attachment 9957 [details] Fix! It was noted on IRC by "Krenair" that the block/unblock modules in the API would allow a user to block/unblock another user without passing a token (never mind whether the token was actually valid) Some poking around and I noticed it was due to the 'gettoken' parameter that both have, whereas the other modules do not have this. $foo['bar'] = false; ... !isset( $foo['bar'] ) evaluates to false, and it meant the code to die for a missing token parameter was never met due to the wrong evaluation if ( $salt !== false && !$moduleParams['gettoken'] ) {
Fixed it on the cluster. I'm presuming this warrants a security release of some sort?
Both REL1_17 and REL1_18 are vulnerable to this too
Ouch, this was an embarrassing oversight on my part ~3 years ago. Patch looks good.
I'm confused: why isn't this patched on trunk?
Although its a crsf issue, its not a major issue, as its in quite a small use case. Hence it warrants a security release, but it's not urgent. issue is patched on wmf currently. It can wait for the next releases, or a more important fix also
Related revision: r114429.
