Our regexp in OutputHandler, ApiFormatJson and ApiFormatPhp ('/\<\s*cross-domain-policy\s*\>/i') counts on this tag to never have any attributes. This is not the case, e.g. https://twitter.com/crossdomain.xml has <cross-domain-policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/schemas/PolicyFile.xsd">. In any case, we must not assume that the spec will never change or that there will never be non-compliant plugin implementations.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • demon | T124940 MediaWiki 1.26.3 security release | |||
| Resolved | • dpatrick | T123653 Cross-domain policy regexp is too narrow |
Event Timeline
Comment Actions
Alternatively, just nuke teh whole thing? Unless someone has an insane rewrite that allows to actually output this XML at /crossdomain.xml, this technique shouldn't be needed anymore.
Comment Actions
I believe it's still needed, since any site can helpfully point to a custom url for crossdomain.xml on a site. I believe /crossdomain.xml will override the custom policy, but I haven't yet deployed a /crossdomain.xml yet (T75574: Host crossdomain.xml master policy file).
Comment Actions
I think we should be able to get away with just changing the regex, along the lines of '/\<\s*cross-domain-policy(?=\s|>)/i', and the replacements similarly. This would be a slight change in that it would turn <cross-domain-policy> into \u003Ccross-domain-policy> instead of \u003Ccross-domain-policy\u003E for ApiFormatJson, but I don't think that will matter for the purpose.
Comment Actions
This patch looks fine to me, although I wonder if it would be simpler to do /\<\s*cross-domain-policy/i instead
Comment Actions
Well, that would catch things like <cross-domain-policy-foobar that aren't the problematic tag.
Comment Actions
Patch deployed (https://wikitech.wikimedia.org/wiki/Server_Admin_Log):
22:47 dapatrick: Deployed patch for T123653 to wmf18 and wmf19