Last modified: 2014-02-12 23:32:49 UTC
When you unblock someone via the API, you get the full user object back. This includes mPassword (hashed, so I'm not sure how much of a big deal this is), mToken, mEmail (not public info), and some other things. On a slightly unrelated note, I'm not sure api.php?meta=userinfo should return the watchlisttoken preference... In the UI it says 'Filling in this field with a secret key will generate an RSS feed for your watchlist. Anyone who knows the key in this field will be able to read your watchlist, so choose a secure value.'
(In reply to comment #0) > On a slightly unrelated note, I'm not sure api.php?meta=userinfo should > return > the watchlisttoken preference... In the UI it says 'Filling in this field > with > a secret key will generate an RSS feed for your watchlist. Anyone who knows > the > key in this field will be able to read your watchlist, so choose a secure > value.' Ignore this bit. meta=userinfo is for the current user only.
Created attachment 11567 [details] Patch
This was caused by r83855.
Interesting that __toString() doesn't seem to be working.
The API uses json_encode (When using format=json, obviously. This bug probably doesn't apply to other formats), which doesn't appear to use __toString() (Why represent it as a string when we know about objects?). ------ <?php class A { public $youshouldnotseethis = "uh oh"; function __toString() { return "works"; } } echo( json_encode( new A() ) ); ------ {"youshouldnotseethis":"uh oh"}
Patch looks reasonable to me, and looks like it should apply fine to both master and 1.20. We'll get the cluster patched asap, and this will be in the 1.20.3 release. With this, and admin could easily block and unblock a user to get their password hash, and attempt to escalate their privileges. And if they escalated to someone with suppress rights, they could cover their tracks. So I think this may drive getting 1.20.3 out a little sooner.
Should 1.19 also get this?
Yes, 1.19 should also get this. Shooting for a 1.20.3/1.19.4 release next week.
Reviewing this for release and realized this throws an exception if the block was an autoblock -- "Fatal error: Call to a member function getName() on a non-object". Probably just need a $target instanceof User ? conditional.
Created attachment 11796 [details] Updated Patch
Created attachment 11797 [details] patch for 1.19 branch
Can I get someone on this bug to "+2" the attached "Updated Patch", and I'll deploy it to cluster? It's a one line change to includes/api/ApiUnblock.php.
(In reply to comment #10) > Created attachment 11796 [details] > Updated Patch +2: Looks good to me
Released as part of 1.20.3 / 1.19.4
RedHat as assigned CVE-2013-1817 to this issue.
