Page MenuHomePhabricator

Security review of GlobalUserPage extension
Closed, ResolvedPublic

Description


Version: unspecified
Severity: normal

Details

Reference
bz70584

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:43 AM
bzimport added a project: GlobalUserPage.
bzimport set Reference to bz70584.
Legoktm created this task.Sep 8 2014, 9:37 PM

I'm a bit confused about the status of this bug. Should it be marked assigned? Does Chris have time to do this?

Sorry for the delay on this.

Minor nitpick: The default central wiki is an http link, can you make that https, so we encourage that?

That ties into the bigger issue with the extension-- The security of the each wiki becomes even more tied to that of the central wiki, since the parse is happening on the remote wiki. So we definitely want to be sure we're talking to the right remote server. But it also opens up some potential attacks that we haven't really had to deal with before.

For example:

  • Someone who can add raw html to a page/template/message on the central wiki can add javascript to the local wiki, for any user.
  • If a url is blacklisted on the local wiki, but isn't blacklisted on the central wiki, a user can add it centrally and it gets rendered by the local wiki.
  • A local wiki oversighter can't delete/suppress content on the user page if they don't also have rights on the central wiki.

Inside the WMF cluster, I don't think these will have a major impact, but I think https://www.mediawiki.org/wiki/Extension:GlobalUserPage should at least document that enabling this on a wiki means you totally trust the central wiki and the admins there.

(In reply to Chris Steipp from comment #2)

Sorry for the delay on this.
Minor nitpick: The default central wiki is an http link, can you make that
https, so we encourage that?

https://gerrit.wikimedia.org/r/173461

That ties into the bigger issue with the extension-- The security of the
each wiki becomes even more tied to that of the central wiki, since the
parse is happening on the remote wiki. So we definitely want to be sure
we're talking to the right remote server. But it also opens up some
potential attacks that we haven't really had to deal with before.

Yup, though I don't think this extension is opening up any new attack vectors (just new locations) since we already have things like CentralNotice and ForeignFileRepo.

For example:

  • Someone who can add raw html to a page/template/message on the central

wiki can add javascript to the local wiki, for any user.

  • If a url is blacklisted on the local wiki, but isn't blacklisted on the

central wiki, a user can add it centrally and it gets rendered by the local
wiki.

  • A local wiki oversighter can't delete/suppress content on the user page if

they don't also have rights on the central wiki.

They could create a blank userpage and full protect it to get rid of the globaluserpage (assuming oversighter > sysop).

Inside the WMF cluster, I don't think these will have a major impact, but I
think https://www.mediawiki.org/wiki/Extension:GlobalUserPage should at
least document that enabling this on a wiki means you totally trust the
central wiki and the admins there.

https://www.mediawiki.org/w/index.php?title=Extension%3AGlobalUserPage&diff=1262378&oldid=1141449

Do you want me to expand on the warning with specific examples?

(In reply to Kunal Mehta (Legoktm) from comment #3)

(In reply to Chris Steipp from comment #2)
https://www.mediawiki.org/w/index.
php?title=Extension%3AGlobalUserPage&diff=1262378&oldid=1141449
Do you want me to expand on the warning with specific examples?

Good enough, thanks!