Page MenuHomePhabricator

Access to /vendor blocked
Open, Needs TriagePublic

Description

The patch applied in T180231 blocks legitimate remote access to the /vendor folder, e.g. to style, fonts, images, ...
This breaks the Chameleon skin [1] and possibly other skins/extensions.

A less intrusive solution to the original issue would be to use FilesMatch in /vendor/.htaccess [2]:

<FilesMatch "\.(php|inc)$">
  Order allow,deny
  Deny from all
</FilesMatch>

[1] https://github.com/cmln/chameleon/issues/55
[2] http://httpd.apache.org/docs/current/mod/core.html#filesmatch

Event Timeline

Foxtrott created this task.Nov 20 2017, 8:10 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 20 2017, 8:10 PM

Anomie kind of already said this in T180231, but even before this patch, many people running hardened mediawiki installs made vendor (and basically all other folders except extensions/ skins/ and resources/ ) inaccessible - for example https://www.mediawiki.org/w/vendor/mediawiki/at-ease/README.md gives a 404

Krinkle added a subscriber: Krinkle.EditedNov 20 2017, 10:40 PM

Composer is for PHP libraries. MediaWiki does not support use of Composer for other purposes.

Having to commit front-end resources from upstream JS/CSS packages to Git is not pretty, but that is the convention right now for MediaWiki front-end development and that is supported by MediaWiki core.

Ways that bypass this convention are at-risk, unsupported, and not tested for. As a result they may break unintentionally, as seen here.

The RFC for figuring out how to conveniently integrate upstream packages for JS/CSS resources is tracked at T107561. In the mean time, the working and supported solution is to commit files to Git.

@Bawolff: Maybe. Then again I never got a single issue with this in the last 4 years.

If we were to do this, I'd prefer to whitelist filetypes instead of blacklist php.

e.g. a regex like \.(gif|jpe?g|png|css|js|json|woff|woff2|svg|eot|ttf|ico)

Krinkle closed this task as Declined.EditedNov 20 2017, 10:45 PM

@Foxtrott As courtesy, @Legoktm pointed out that mw-bootstrap managed to find a new workaround to keep this working. See https://github.com/cmln/mw-bootstrap/commit/5fc27e4d58e for details.

I don't know if that would work for you, but might be worth trying is. Anyhow as said, this pattern is unsupported. It was never provided as a feature and never agreed upon. That it worked is irrelevant. There are in fact various issues with supporting it, such as the security problem that led to the directory being disabled for web access. This directory structure it intended to host PHP files accessible only server-side, not client-side.

As such, I feel obligated to point out that the above workaround used by mw-bootstrap will most likely expose you to future security vulnerabilities. Be advised.

Well, yeah, thaks. That was me trying to find a workaround. Problem is it does not work. The package is still installed to the vendor dir.

That this is unsupported all of a sudden is certainly convenient. Never mind that there would be a less intrusive solution.

Tgr reopened this task as Open.Dec 16 2017, 5:35 AM
Tgr added a subscriber: Tgr.

This seems like a poor state of affairs.

  • T107561: MediaWiki support for Composer equivalent for JavaScript packages, having been stuck for two and half years now, is not something to handwave users towards.
  • Even if we did have a Composer equivalent for JS packages, that would not take care of the problem of JS packages that are actually defined via Composer (because they are part of some PHP package and that package wants to manage its own assets - seems like a reasonable thing to do for a frontend-oriented Composer package).
  • The "workaround" used by mw-bootstrap is to make Composer install it to a non-standard directory, thereby recreating the problem the .htaccess lockdown was supposed to fix. Surely we don't want to propose that as the recommended solution.

Whitelisting common asset formats as suggested in T180994#3776185 seems like an easy and safe temporary solution; I see no reason not to do it.

The other common solution for these problems is having the installer copy the assets over to the webroot. That's a fair amount of effort though; there is an existing Composer plugin (atelierspierrot/assets-manager) but it's super complicated and requires support in the package that's to be installed. So there doesn't seem to be much benefit in going that route.