zero.wikipedia.org has raw html enabled. However ZeroPortal allows parsing arbitrary wikitext from url GET parameters in the event the user has the zero-edit right. This is an XSS.
The potential attack scenario I see would be someone sends a phising email with a url like http://zero.wikimedia.org/wiki/Special:ZeroPortal?portal=ns:0}}%3Chtml%3E%3Cscript%3Ealert(1)%3C/script%3E%3C/html%3E to a zero-admin, and then uses that to take over their privileged account and do further evil.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| SECURITY: [XSS] Ensure portal url parameter is a valid title. | mediawiki/extensions/ZeroPortal | master | +6 -3 |
Proposed patch
Even though its trivial, it would be great if someone who works on the extension could comment on it (Assuming there actually is anyone left at the foundation who does).
See T156184 for a proposal to fix this type of vulnerability in general in MediaWiki.
We've taken care of the xss with generic changes in MediaWiki. However there is still the possibility of disclosing (what I'm told is) secret information via template transclusion - e.g. http://zero.wikimedia.org/wiki/Special:ZeroPortal?portal=ns:0}}{{special:AllPages/Zero:}} . And not just here, there are other examples in the zero extension, for example https://zero.wikimedia.org/w/index.php?title=Special%3AZeroPortal&zppage=marketing&zproute=%3Cdiv%20title=%22{{urlencode:{{Zero:250-99}}|wiki}}%22%3Ehover%20here%3C/div%3E
The generic issue is T160266 (Although fixing it generically will probably explode zerowiki even more). Perhaps in the mean time we should add $wgNonincludableNamespaces[] = 480; (Which would disable transcluding the Zero: namespace), although that's probably not sufficient.
The confidentiality expectations/sensitivity of the data in zero wiki does not appear to documented anywhere. It would be helpful if that was documented somewhere so we could more clearly evaluate the risk here.
I deployed this patch today (apr 24). I'm leaving this bug still open as there are other vectors mentioned here.
Ok, $wgNonincludableNamespaces[] = 480; is set now which should harden this significantly - but we should still fix the lua module itself to escape things.
What is still left to do here? We've had this patch sitting on the cluster since February.
What is still left to do here?
The two previous comments by Bawolff mention further vectors.
The fix to $wgNonincludableNamespaces and the prior (2?) patches are deployed. I guess all that's left is the Lua module?