I work on the MediaWiki Security Team.
Fri, Jan 18
FYI: My current opinion on this is we should drop the wordlist thing. I think most of the time the combining two words results in a string that is not recognizable as a word, and it probably helps computers more than humans.
Just wondering, is there a reason for the doing the new SiteMapper stuff, instead of using core's WikiMap (and related) class? (I haven't looked at WikiMap in a while, so the answer might just be that WikiMap really sucks)
Wed, Jan 16
This Google doc (accessible to all WMF staff) has all our project notes to date (again, we just started) and I've added a summary of your comments. I will publish an update on our cross-department program's Meta page about blocking tools.
I think any conversation that starts from a place of "Lets stop all abuse" is not going to go anywhere. There's lots of different types of abuse on the wiki, involving different methods, motives and sophistication. Solutions are not going to be one size fits all and it will probably be a poor solution if it doesn't start from a place of usecases.
Tue, Jan 15
That said, probably couldn't hurt to mention cookies as a possibility in that error message.
So looking at the code (I assume we are talking about login here):
Mon, Jan 14
Sat, Jan 12
Fri, Jan 11
In my defense, look at the default values in old versions of the official docs: https://web.archive.org/web/20151002085202/https://secure.php.net/manual/en/function.file-get-contents.php
Thu, Jan 10
I guess worst case scenario, we could add a post-processing step
I'm not sure which malicious actors we're worried about here - The primary questions seem almost certainly ethical & technical (does the mechanism actually work, what is the false positive rate, what is the false negative rate, etc).
Wed, Jan 9
Tue, Jan 8
I personally have no strong feelings about this, as long as there is a clear policy which is documented in a way that allows people on github to understand what assumptions they can make about members of the wikimedia project.
Mon, Jan 7
As an addendum:
Just set the mailing list to not allow html email. That's really the only fool proof way to get what you're asking for.
@Sophivorus To give further context, to move this forwards, this really needs a champion with deploy access to push it forward. @greg can help you in determining what other requirements beyond security review are needed in order to get this deployed.
Ok, its Jan 7. Making this public
If you make an existing security task be a child task of a public task, it will only show up when people have rights to view, so it all works out fine.
Fri, Jan 4
Do you think you should still be a member of the wikimedia "organization" on github? What are you using this membership for?
Thu, Jan 3
On a related note, recaptcha isn't just a concern about FOSS, there are also concerns about privacy and security of allowing a third party to run JS on our sites.
On a related note, given WMF has now started to abandon the old and highly restrictive policy of only ever using free and open source software, alternative CAPTCHA services can now be considered.
Wed, Jan 2
So one big table holding the data for all the wikis is probably not a good idea as you'd be creating just a big massive table.
Sat, Dec 29
I suspect its caused by a7cbc776ba7
Fri, Dec 28
Ah, according to php docs: https://secure.php.net/manual/en/function.dirname.php it sounds like dirname( '/' ); will maybe output \ on windows, so that's probably where its coming from.
Hmm, maybe this is from line 37 of index.php:
$scriptPath is supposed to be the path for a URL. So / would be correct even on windows.
Thu, Dec 27
Sorry for being negative, but...
Wed, Dec 26
Dec 18 2018
Dec 16 2018
Note, there was some relatively recent changes to the schema for change tags - T185355
Dec 15 2018
Dec 13 2018
So this has now been marked as secret for 22 months. I appreciate that some of the lesser issues still aren't fixed, but security tasks are intended to only be kept secret for a limited amount of time to allow for fixes to be applied. Tasks like these are not supposed to be kept confidential indefinitely.
Dec 12 2018
Dec 11 2018
Sorry, for the confusion of the instructions. The bug is only present for certain log types, such as: newusers, renameuser, block, rights, gblblock, globalauth, massmessage.
Dec 10 2018
The internet also claims grapheme_strlen is a thing - https://secure.php.net/manual/en/function.grapheme-strlen.php but it didn't seem to work when i tested locally...
using mb_strlen instead of strlen would probably get us 60% of the way to something reasonable.
Dec 8 2018
Dec 6 2018
Hmm, http://www.123seminarsonly.com/Seminar-Reports/008/47584359-captcha.pdf has some advice about eliminating characters that look alike (e.g. 1 and l)
Dec 5 2018
I kind of think maybe we should just go with random letters. I don't think the combining two words thing helps users very much since usually they are weird enough words its not identifyable as a word. But it does probably help attackers quite a bit.
It was pointed out to me that this might not be the best idea, because if an attacker compromises an account that has temporarily removed 2FA, the attacker can just enroll into 2FA to get back access.
Dec 4 2018
CheckUsers have unlogged access to IP addresses via the AbuseFilter API
Dec 3 2018
Ok, so its doing the query
SELECT user_id,user_name,user_real_name,user_email,user_touched,user_token,user_email_authenticated,user_email_token,user_email_token_expires,user_registration,user_editcount,user_actor.actor_id,ipb_deleted,ipb_id,ipb_expiry,ipb_timestamp,ipb_by,ipb_by_text,NULL AS `ipb_by_actor`,comment_ipb_reason.comment_text AS `ipb_reason_text`,comment_ipb_reason.comment_data AS `ipb_reason_data`,comment_ipb_reason.comment_id AS `ipb_reason_cid` FROM `user` LEFT JOIN `actor` `user_actor` ON ((user_actor.actor_user = user_id)) LEFT JOIN `ipblocks` ON ((ipb_user=user_id) AND (ipb_expiry > '20181203070920')) JOIN `comment` `comment_ipb_reason` ON ((comment_ipb_reason.comment_id = ipb_reason_id)) WHERE user_name = 'Quiddity' ;
It seems like minimal reproducible test case is: https://test.wikipedia.org/w/api.php?format=jsonfm&formatversion=2&action=query&list=users&usprop=blockinfo&ususers=Quiddity
Dec 1 2018
Nov 30 2018
I didn't think it was, but after a long (albeit, heated) discussion it seems like that is exactly the threat model of the same-origin policy. At least for credential-less cross-origin requests, but the browser will not send credentials cross-origin, so it is a matter of intranet sites.
Note previous discussion on T62835 - perhaps it was unnecessarily paranoid.
On one hand, I kind of feel like its a browser issue - Should they really allow globally routed internet apps make requests to private IP space intranet app. But that's probably kind of impossible.
Nov 28 2018
The gci task is already accepted - we cant force the student to do more work (we can of course ask nicely)
Nov 27 2018
On the subject of rate limits: i guess it could make sense if they only applied when blocking a user with the ability to block other accounts. I still think the block user who blocked you is a better mitigation
Fwiw: on the subject of unblockself rights - even if all admins have that the attacker could still just immediatly (via an automated script) reblock anyone who unblocks themselves as soon as they do so, before they can block attacker. Sure eventually a defender could write a script to win the race condition, but it would probably take longer to do that then just fetch a steward. So i dont think removing unblockself significantly increases the risk of an attacker blocking all other admins.
There's discussion on enwiki about also having a rate limit on blocking users. Seems like a reasonable enough idea, but we'd want it high, as we really only want it in cases of truly malicious users.
In T150826#4775305, @Tgr wrote: [...] Allow blocked admins to block the user who blocked them (but not others). That removes first-mover advantage on small wikis - in case of >serious trouble the admins will lock each other out and things will mostly be at a standstill until stewards come and clean things up.
Nov 26 2018
This patch doesn't seem to apply cleanly
patching file includes/api/ApiQueryAbuseLog.php Hunk #1 FAILED at 56. Hunk #2 FAILED at 66. Hunk #3 FAILED at 95. Hunk #4 FAILED at 190. Hunk #5 FAILED at 283. 5 out of 5 hunks FAILED -- saving rejects to file includes/api/ApiQueryAbuseLog.php.rej
If you have 2 honest admins, they can just unblock each other.