Page MenuHomePhabricator

Security review of GLAM Wiki Toolkit
Closed, ResolvedPublic


Please do a security review of the GLAM Wiki Toolkit.

Version: unspecified
Severity: normal



Related Objects

Resolved csteipp

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:37 AM
bzimport set Reference to bz56178.

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.

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.

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.


  • $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.

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?)


  • 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?


  • 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.


  • 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).


  • XMLReader must disable external entity loading before reading xml


  • 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?


  • 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.


  • Use MimeMagic for mimetype detection


  • Remove augmentAllowedExtensions if it's unused


  • getButtonRowNoMetadata, getFirstRow use Sanitizer::escapeId for html id attr
  • xml_validator.asp needs to be an external link


  • no access control on who can access files in the backend?


  • Can getPostAsHiddenFields only return a whitelist of fields?


  • 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.


  • Needs to check of the user has access, or get FOR_PUBLIC

Not security related


  • missing hooks for update.php


  • Checking for PHP_SAPI = 'cli' seems like the wrong way to check if this is running from a job


  • Line 311: Don't include error message in that string, since it's sent to .html().

• js-error-output:
• mime-type:
• table-create:
• sanitizer-escape-id:
• derivative-request:
• augmentAllowedExtensions:
• PreviewForm:
• original-post:


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?

I think Dan's addressed everything. LGTM.

(In reply to comment #11)

I think Dan's addressed everything. LGTM.

Is this bug resolved/fixed then? :-)

(In reply to comment #12)

(In reply to comment #11)

I think Dan's addressed everything. LGTM.

Is this bug resolved/fixed then? :-)

Yep :)

Gilles raised the priority of this task from Medium to Unbreak Now!.Dec 4 2014, 10:25 AM
Gilles moved this task from Untriaged to Done on the Multimedia board.
Gilles lowered the priority of this task from Unbreak Now! to Medium.Dec 4 2014, 11:20 AM