Remote CSS: Allow data URIs in CSS properties

[ryelle]

I'm using the Remote CSS feature for WordCamp Boston. I'd like to use SVGs for background images, encoded directly into the CSS file using ​data-uris. Unfortunately, the sanitization for URLs in the jetpack-tweaks sees this value as a URL, and strips data:, thinking it's a bad protocol. You can see it's broken on ​boston.wordcamp.org, the white rectangle should be our logo.

I've attached a patch which just adds data as a valid protocol, but I'm not sure if there are any reasons we might not allow that (security comes to mind, but if we allow any http url...?).

I hesitate to allow svg as data uris, because svg can contain script code. Am I paranoid, or correct?

Note that svg with malicious script on a different domain has the domain problem. Data uri, not so much.

SVGs used as images, like css background-images, should have javascript disabled by browsers. ​mdn outright says this for Gecko, while ​this presentation makes the claim that svgs as images "should not execute JavaScript"... however I can't find any definitive guide saying that each browser definitely does or not.

FWIW, I've tried adding JS to an SVG image and it's not executing.

Note that svg with malicious script on a different domain has the domain problem. Data uri, not so much.

I hadn't thought of that, so it's worth making sure.

My understanding is that SVGs can't execute JavaScript in the context of a background image, because they're not a DOM element. IIRC, I didn't intend to prevent data-uris in r2085, but I'll double check before merging this.

​#wp24251 has a lot of related information and discussion.

I haven't found anything definitive yet either.

I suspect that all modern browser engines will treat background-image SVGs the same way Gecko does, but there are so many esoteric SVG exploits¹ that it's really hard to be confident in anything. Even if JavaScript is disabled, there may still be XML attacks, etc.

I think we need some more research before this can be committed.

In the mean time, it looks like you're hosting the SVGs on an external domain, so that the cross-domain policy offers some protection. Ideally we want all resources hosted on wordcamp.org for longevity, but hosting them externally sounds like a good compromise until this is sorted out.

[1] - For example, check out section 3.3 of ​Crouching Tiger -- Hidden Payload, where data: URIs are used in inline SVGs to nest malicious SVGs via the feImage tag.