Extension:CentralAuth/Global session threat assessment
 | This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. The idea of automatically starting a session on other wikis at login was implemented in 2008. See r33061. |
Some notes from my initial security assessment of global sessions for SUL...
Background:
- On login, cookies are to be set for each second-level domain we have shared wikis (wikipedia.org, wiktionary.org, wikimedia.org, etc)
- These global cookies contain current session state or permanent login tokens, so can be considered login-equivalent if you've got em
XSS
[edit]Cross-site scripting vulnerabilities in the various side services that sit on our major domains, especially wikimedia.org, could potentially access global session cookies and do evil things.
The good news is, the same-origin policy should restrict XSS code from doing anything directly to the wiki subdomains; they can only steal the session cookie for an attacker to use.
This could be mitigated by HttpOnly cookies, restricting client-side JS from accessing the cookies on supporting browsers (current IE and Firefox versions, beta of Opera, some others).
PHP 5.2 has an explicit option for sending cookies in this way; we'd need to roll out some upgrades to our Fedora machines which are running patched 5.1 releases.
Rogue admins on wikis
[edit]Malicious site JS written by a rogue admin could cause some trouble; a smaller, less-watched site might end up with some Evil JavaScript which abuses your account on that wiki without your noticing.
httpOnly protection should avoid stealing of the global tokens, but leaves you open to use of the account within the open session via DOM calls. The attack profile is a bit higher than without SUL/global sessions, since you'll be automatically logged in on more wikis, and an attack on one wiki could affect the global account.
At a minimum, we should ensure that the global e-mail and account settings can't be reset through a silent attack. Forcing a password entry to reset the email might help.
Server-side code
[edit]Server-side access to cookies could not be prevented by HttpOnly cookie support.
Abuse here requires being able to run arbitrary server-side code, which is less likely than an XSS but possible in buggy side services.
Cases where we have a wikimedia.org subdomain pointing to an offsite service may be at risk.
Toolserver
[edit]Relatively large number of semi-trusted users have access to run arbitrary code in PHP or other server-side tools here on both HTTP and HTTPS.
As long as this remains at the tools.wikimedia.de domain, it should be relatively safe; we won't send any cookies there.
If TS users' web hosting is exposed on hemlock.ts.wikimedia.org or tools.wikimedia.org, then global session and token cookies are vulnerable to access by server-side code.
Ensure that hosting is correctly placed at the offsite domain, and that redirects are not overridable.
Uploads
[edit]Long ago, in the dark times, one of the reasons we shunted media files over to the upload.wikimedia.org domain was for cookie safety. In case client-executable JavaScript got uploaded, XSS code couldn't reach the wikis or their session and token cookies.
As long as PHP execution is disabled, any XSS code in uploads should be protected by httpOnly cookies (unless there's a plugin vulnerability, perhaps).
Offsite services
[edit]Several wikimedia.org subdomains point to offsite servers:
- cfp.wikimania (obsolete)
- dvd
- wm08reg (empty?)
Session data could be exposed to server-side code there.
Recommend pruning the obsolete one and moving the other two to safer hostnames. We can provide redirects so old URLs keep working.
Secure server
[edit]SSL access to the wikis is currently segregated on secure.wikimedia.org. As long as this is configured to set cookies as secure and for that full domain only, it should avoid leakage of global cookies from the secure to the insecure sites.
This could make them a nice, safe testbed for the global session state prior to rolling it out for the cross-domain use.
It may be possible for cookies to leak from the insecure to the secure site, which might be annoying.
Currently, OTRS is hosted on secure.wikimedia.org alongside the wikis, however; XSS issues there would still affect the wikis within the parameters outlined above.