Last modified: 2013-12-06 16:52:48 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T58178, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 56178 - Security review of GLAM Wiki Toolkit
Security review of GLAM Wiki Toolkit
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
GWToolset (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Chris Steipp
:
Depends on:
Blocks: 56181 56182
  Show dependency treegraph
 
Reported: 2013-10-25 18:44 UTC by Greg Grossmeier
Modified: 2013-12-06 16:52 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Greg Grossmeier 2013-10-25 18:44:03 UTC
Please do a security review of the GLAM Wiki Toolkit.
Comment 2 dan 2013-11-06 08:23:24 UTC
on friday, 2013-11-01 we agreed that the tentative review date will be monday, 2013-11-11 depending on the mvp status, architecture review and chris’ schedule.
Comment 3 Chris Steipp 2013-11-06 21:31:14 UTC
Correct, I'm targeting 11/11 as a start date for the review, which I should be able finish sometime that week. If you can have everything merged by then, that would help.
Comment 4 Chris Steipp 2013-11-21 20:30:28 UTC
Hi Dan,

I'm working through the review. There are a couple of things I'd like to see fixed at their root, so I don't have to document every occurrence, so this is just a partial list for now. Let me know if you have questions.


includes/Php/Filter.php
* $filter_sanitize === null in sanitize() should not be allowed. Since you use Filter::evaluate() to sanitize for xss in several places, there can't be a chance that would return without any filtering. If you can remove setting a custom filter, that would be even better.
* Split array handling into another class that calls the scalar version, so all filtering logic is in one class, but when you filter, it's explicit if you're expecting an array or scalar.

includes/Handlers/Forms/FormHandler.php
Line 109: getForm is called without validating the class beyond existence. Please check this is a form class you're expecting (have them all inherit and check instanceof?)

includes/Handlers/Forms/MetadataDetectHandler.php
* getUserOptions() - doing urldecode after filtering invalidates filtering
* You have MAX_FILE_SIZE come in from the form, although it looks like you never actually use it. You should obviously never rely on user-submitted data to check sizes. You can probably just remove that field, in case another developer decides to trust it?

includes/functions/functions.php
* is there a reason these aren't static methods in a utility class?
* Attack can get arbitrary values through getWhitelistedPost by passing in a whitelisted name as an array with 'filter-sanitize'=null. Fixing Filter should prevent this from being an issue.

includes/Specials/SpecialGWToolset.php
* Line 143: Please log, don't print_r
* Line 164: I would make things easier if you could escape the exception message, or demonstrate that it's been properly sanitized. Otherwise all exceptions have to be sanitized for xss (more places to get something wrong).

includes/Handlers/Xml/XmlHandler.php
* XMLReader must disable external entity loading before reading xml
Comment 6 dan 2013-11-26 04:53:19 UTC
• sanitized-exceptions: https://gerrit.wikimedia.org/r/#/c/97676/
Comment 7 Chris Steipp 2013-11-27 19:06:40 UTC
includes/Helpers/FileChecks.php
* mimeTypeAndExtensionMatch doesn't ensure mime = extension. mimeTypeAndExtensionMatch() should use MimeMagic::isMatchingExtension()
* It looks like this is only used for the xml metadata. If so, can you please document that in the code?

includes/Jobs/UploadMetadataJob.php
* The variables put into the $_POST global state can be anything, since the whitelisting for MetadataMappingHandler is based on the templates, which are user-controlled. If you need arbitrary values to be input from the form, you need to use something other than $_POST to pass the state to the dependent objects.

includes/Php/File.php
* Use MimeMagic for mimetype detection

includes/Handlers/UploadHandler.php
* Remove augmentAllowedExtensions if it's unused

includes/Handlers/Xml/XmlDetectHandler.php
* getButtonRowNoMetadata, getFirstRow use Sanitizer::escapeId for html id attr
* xml_validator.asp needs to be an external link

includes/Handlers/Forms/MetadataMappingHandler.php
* no access control on who can access files in the backend?

includes/Forms/PreviewForm.php
* Can getPostAsHiddenFields only return a whitelist of fields?

includes/Adapters/Php/MediawikiTemplatePhpAdapter.php
* Should use a derivative request object instead of curling the api. If this isn't possible for some reason, it needs to use https instead of http.

includes/Adapters/Php/MappingPhpAdapter.php
* Needs to check of the user has access, or get FOR_PUBLIC


== Not security related ==
table-create-gwtoolset-mediawiki-templates.sql
* missing hooks for update.php

includes/Handlers/Forms/MetadataMappingHandler.php
* Checking for PHP_SAPI = 'cli' seems like the wrong way to check if this is running from a job
Comment 8 Chris Steipp 2013-11-27 23:05:23 UTC
ext.gwtoolset.js
* Line 311: Don't include error message in that string, since it's sent to .html().
Comment 9 dan 2013-12-03 20:40:27 UTC
• js-error-output: https://gerrit.wikimedia.org/r/#/c/98686/
• mime-type: https://gerrit.wikimedia.org/r/#/c/98725/
• table-create: https://gerrit.wikimedia.org/r/#/c/98735/
• sanitizer-escape-id: https://gerrit.wikimedia.org/r/#/c/98742/
• derivative-request: https://gerrit.wikimedia.org/r/#/c/98807/
• augmentAllowedExtensions: https://gerrit.wikimedia.org/r/#/c/98812/
• PreviewForm: https://gerrit.wikimedia.org/r/#/c/98825/
• FOR_PUBLIC: https://gerrit.wikimedia.org/r/#/c/98835/
• original-post: https://gerrit.wikimedia.org/r/#/c/98846/


MetadataMappingHandler.php
--------------------------
no access control on who can access files in the backend.

as far as i can tell there is no way to restrict MediaWiki User access similar to the way UploadStash does. the only “security” i’ve seen is via the FileBackend->prepare() and FileBackend->secure() methods. the code is already implementing the prepare() method.

1. is there a way to secure the files per User?
2. is that necessary?
3. if there’s no way to do it yet and it’s necessary, how do we move forward?
Comment 10 dan 2013-12-05 13:40:59 UTC
filebackend-user-access: https://gerrit.wikimedia.org/r/#/c/99387/
Comment 11 Chris Steipp 2013-12-06 00:37:08 UTC
I think Dan's addressed everything. LGTM.
Comment 12 MZMcBride 2013-12-06 00:42:38 UTC
(In reply to comment #11)
> I think Dan's addressed everything. LGTM.

Is this bug resolved/fixed then? :-)
Comment 13 Greg Grossmeier 2013-12-06 16:52:48 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > I think Dan's addressed everything. LGTM.
> 
> Is this bug resolved/fixed then? :-)

Yep :)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links