Last modified: 2013-05-13 21:34:31 UTC
To complete bug 46901, we need a single domain where global users will be logged in, and all of the WMF sites can test check to see if the local wiki should allow a user to login. Because this website will have a session for every logged in user, the site should: * Highly restrict the javascript that can run on it * Minimize the amount of content and features, to reduce the risk for XSS vulnerabilities * Only be accessible over SSL * Disallow any iframing
(In reply to comment #0) > To complete bug 46901, we need a single domain where global users will be > logged in, and all of the WMF sites can test check to see if the local wiki > should allow a user to login. > > Because this website will have a session for every logged in user, the site > should: > * Highly restrict the javascript that can run on it Could take away editinterface away from sysops, But that means they can't edit any message in the mediawiki ns, Which would be bad. But stops any of the edits to js/css that effects all users > * Minimize the amount of content and features, to reduce the risk for XSS > vulnerabilities Depending on what context you want it to be used, eg: central place for userpages, You wouldn't need many extensions that are outside the group thats defaultly enabled. > * Disallow any iframing We do this by default these days iirc, Or at least tim has coded it.
(In reply to comment #1) > Could take away editinterface away from sysops, But that means they can't > edit > any message in the mediawiki ns, Which would be bad. But stops any of the > edits > to js/css that effects all users A number of people should have access, but some number less than the thousands that can edit enwiki would be nice ;) > > * Minimize the amount of content and features, to reduce the risk for XSS > > vulnerabilities > > Depending on what context you want it to be used, eg: central place for > userpages, You wouldn't need many extensions that are outside the group thats > defaultly enabled. Most of the XSS we've seen have required some input. My preference would be no user controlled data. If it seems best to also use it for global user profiles, we'll need to be extra paranoid about what extensions are enabled. > > * Disallow any iframing > > We do this by default these days iirc, Or at least tim has coded it. There are a lot of pages (e.g., action=view for articles) that override that, unfortunately. We would probably clean those up so we can disable all of them.
The domain has been finalized as login.wikimedia.org. It has been described as a reverse-fishbowl in that only global accounts are allowed -- there will be no local accounts.
(In reply to comment #3) > The domain has been finalized as login.wikimedia.org. > > It has been described as a reverse-fishbowl in that only global accounts are > allowed -- there will be no local accounts. Is there any other needed initial configuration?
(In reply to comment #2) > (In reply to comment #1) > > Could take away editinterface away from sysops, But that means they can't > > edit > > any message in the mediawiki ns, Which would be bad. But stops any of the > > edits > > to js/css that effects all users > > A number of people should have access, but some number less than the > thousands > that can edit enwiki would be nice ;) Isn't that just a matter of not giving many people sysop? Or you could do as mentioned in comment #1 (remove editinterface from sysops) and give editinterface to a different, more limited group. You'd probably also want $wgAllowUserJs and $wgAllowUserCss set to false. > > > * Disallow any iframing > > > > We do this by default these days iirc, Or at least tim has coded it. > > There are a lot of pages (e.g., action=view for articles) that override that, > unfortunately. We would probably clean those up so we can disable all of > them. There's already $wgBreakFrames that looks like it would force anything using OutputPage::output() to always set X-Frame-Options: DENY. But be careful you don't break the iframe-based login check from Gerrit change #58924. Since it doesn't use OutputPage::output(), it should be safe from $wgBreakFrames. > Most of the XSS we've seen have required some input. My preference would be > no user controlled data. Take away everything except 'read' from *, users, and autoconfirmed? ;) (does CentralAuth need 'createaccount' and/or 'centralauth-merge' to create the local account during login?)
(In reply to comment #5) > You'd probably also want $wgAllowUserJs and $wgAllowUserCss set to false. Yes, please. > Take away everything except 'read' from *, users, and autoconfirmed? ;) I actually do think this is a good idea. If we decide later it's desired, then we can always add rights. > (does CentralAuth need 'createaccount' and/or 'centralauth-merge' to create > the > local account during login?) Yes, those will be needed.
Might be worth starting a changeset in mediawiki-config for this wiki. Makes it easier to review, and it can be updated collaboratively.. :D At the same time it might be easier just to put some of these directly into CommonSettings to begin with - we can loop to set all rights not to be kept etc. Might just generally be cleaner than tens of => false on different options
(In reply to comment #7) > At the same time it might be easier just to put some of these directly into > CommonSettings to begin with - we can loop to set all rights not to be kept > etc. Might just generally be cleaner than tens of => false on different > options I definitely like the idea of explicitly assigning all rights on this wiki as opposed to disabling everything that we can think of (i.e. remove ALL rights and then add back).
Related URL: https://gerrit.wikimedia.org/r/62002 (Gerrit Change Ieef88a12cf396bca66a0f890b0fe4b4e3223751d)
Related URL: https://gerrit.wikimedia.org/r/62020 (Gerrit Change I03b88050bb253fa91240d1797c754d5084392a75)
Related URL: https://gerrit.wikimedia.org/r/62021 (Gerrit Change I3668326cc715708eeb7ff9d8350b67dd03c2a947)
(In reply to comment #6) > > (does CentralAuth need 'createaccount' and/or 'centralauth-merge' to create > > the > > local account during login?) > > Yes, those will be needed. 'centralauth-merge' is easy It would look like from the code that 'createaccount' isn't needed if we have 'centralauth-autoaccount' for * public function autoCreate() { global $wgGroupPermissions; // Yes unless account creation is restricted on this wiki return !empty( $wgGroupPermissions['*']['createaccount'] ) || !empty( $wgGroupPermissions['*']['centralauth-autoaccount'] ); } Adding createaccount is going to show the registration stuff...
