Nice find.

I wonder if core wfExpandUrl() should be changed to match https://url.spec.whatwg.org/#url-parsing . I think the way extension:CSS is currently written is risky, and should use wfParseUrl instead regardless (to follow a parse and deserialize pattern instead of a validation pattern) however core mediawiki does seem at least partially at fault here.

Huh, I didn't know that there's a living standard for URLs! I guess my statement about compliant URL parsers might be wrong since MediaWiki isn't complying with it.

I initially thought that wfExpandUrl was technically not incorrect, but I suppose in this circumstance it is. Perhaps both fixes could be done.

For checking if $url is relative to $base, I suppose we could check for all three conditions:

• $url's origin (scheme, domain, port) is equal to $base's
• $url's path starts with $base's path with trailing slashses stripped, and appended to "/"
• $url's search starts with $base's

This should be reasonable to expect. However, it appears that we'll need to use our own parser or modify MediaWiki's, because:

> docker compose exec mediawiki php maintenance/run.php shell
PHP Notice:  Writing to directory /.config/psysh is not allowed. in /var/www/html/w/vendor/psy/psysh/src/ConfigPaths.php on line 327
Psy Shell v0.12.4 (PHP 8.1.20 — cli) by Justin Hileman
> $wgStylePath
= "/w/skins"

> wfParseUrl($wgStylePath)
= false

I want to try to update MediaWiki's URL parser to the standard. I've searched for wfExpandUrl and UrlUtils on Phab, and couldn't find anything related to it. Should the bug report about wfExpandUrl/UrlUtils::expand be public, or should it be fixed here privately?

I was thinking you could maybe use wfAssembleUrl(), and that passing it through that would cause questionable characters like \ to be escaped when re-assembling, but it seems like that is not the case, and wfAssembleUrl has the same problem as the other functions.

I wrote the first versions of wfRemoveDotSegments and wfAssembleUrl for reasons like this, but that was back in 2011 and based on the RFC available at the time. It seems these have not aged well.
https://static-bugzilla.wikimedia.org/bug32168.html

@BlankEclair any updates on updating the URL parser?

I'm not sure whether or not I should ship a better parser in MediaWiki core and have the extension use that, or if I should ship the spec-compliant parser in the extension, or I should replace \ with / and call it a day.

In T369486#10076383, @BlankEclair wrote:

I'm not sure whether or not I should ship a better parser in MediaWiki core and have the extension use that, or if I should ship the spec-compliant parser in the extension, or I should replace \ with / and call it a day.

IMO, the first option is ideal, as there actually seems to be an issue with some of core's url-parsing functions, while the latter two are probably far more convenient and easy to do. I'm not sure any of these are "wrong", per se.

@BlankEclair since this is not deployed on WMF production it can be pushed through Gerrit and noted in the supplemental release. We can also hold for supplemental release and apply the patch then, but I don't recommend that.

Patch: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CSS/+/1067223

@Mstyles: can you add this to the supplemental and seek CVE record?

Change #1067324 had a related patch set uploaded (by Alejandro Alcaide; author: BlankEclair):

[mediawiki/extensions/CSS@REL1_42] SECURITY: Workaround path traversal abusing backslashes

https://gerrit.wikimedia.org/r/1067324

Change #1067324 merged by jenkins-bot:

[mediawiki/extensions/CSS@REL1_42] SECURITY: Workaround path traversal abusing backslashes

https://gerrit.wikimedia.org/r/1067324

@Mstyles @sbassett: any reason this can't be public

In T369486#10199001, @RhinosF1 wrote:

@Mstyles @sbassett: any reason this can't be public

Nope. It should be out with the next supplemental release, which should hopefully come out very early next week.

Change #1199055 had a related patch set uploaded (by SomeRandomDeveloper; author: BlankEclair):

[mediawiki/extensions/CSS@REL1_39] SECURITY: Workaround path traversal abusing backslashes

https://gerrit.wikimedia.org/r/1199055

Change #1199055 merged by jenkins-bot:

[mediawiki/extensions/CSS@REL1_39] SECURITY: Workaround path traversal abusing backslashes

https://gerrit.wikimedia.org/r/1199055