Page MenuHomePhabricator

Security review of GlobalCssJs extension
Closed, ResolvedPublic

Description

For deployment.


Version: unspecified
Severity: normal
URL: https://www.mediawiki.org/wiki/extension:GlobalCssJs

Details

Reference
bz58438

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 2:19 AM
bzimport added a project: GlobalCssJs.
bzimport set Reference to bz58438.

Lego: is this extension ready for a security review now? If so, can you please coordinate with Chris S. on this?

Spoke with Chris today, and he's going to do this once he finishes the Popups review (bug 61743).

With the caveats that Kunal put on the extension's page (account compromise if you're not correctly using CentralAuth or shared user tables), the security looks ok.

The site global scripts allow admins on the central site to fully control the wikis using wgUseGlobalSiteCssJs, including elevating their own privileges, so obviously should be used with extreme caution.

(In reply to Chris Steipp from comment #3)

The site global scripts allow admins on the central site to fully control
the wikis using wgUseGlobalSiteCssJs, including elevating their own
privileges, so obviously should be used with extreme caution.

On bug 57891 we established that for the time being this would be disabled on WMF wikis, and we would need to re-review the extension if we ever decide to turn it on.

(In reply to Chris Steipp from comment #3)

With the caveats that Kunal put on the extension's page (account compromise
if you're not correctly using CentralAuth or shared user tables), the
security looks ok.

The site global scripts allow admins on the central site to fully control
the wikis using wgUseGlobalSiteCssJs, including elevating their own
privileges, so obviously should be used with extreme caution.

Is this bug resolved/fixed then?

(In reply to MZMcBride from comment #5)

(In reply to Chris Steipp from comment #3)

With the caveats that Kunal put on the extension's page (account compromise
if you're not correctly using CentralAuth or shared user tables), the
security looks ok.

The site global scripts allow admins on the central site to fully control
the wikis using wgUseGlobalSiteCssJs, including elevating their own
privileges, so obviously should be used with extreme caution.

Is this bug resolved/fixed then?

Yes