Security overview¶

This document outlines the security design of the MediaWiki charm along with common security risks and best practices.

Handling of sensitive configuration settings¶

Sensitive configuration settings, such as generated secrets, database credentials, SMTP relay credentials, and arbitrary user-configured settings, are stored outside of the MediaWiki webroot to reduce the risk of exposure. These files are not world-readable and the web server process cannot write against them.

Secrets¶

Updates¶

For security and database integrity reasons, the MediaWiki charm does not automatically update the MediaWiki application itself. Additionally, database schema updates outside of initial installation, if required, need to be triggered manually by the operator. See the how to upgrade guide for more details.

Risks¶

Application CVEs¶

MediaWiki, can be vulnerable to new CVEs and may require updates to patch the CVEs. In case of an exposure to a CVE, it is recommended that you update your MediaWiki charm and rotate the secrets. If private SSH keys for git operations were configured, they should also be rotated.

Extensions¶

The MediaWiki charm comes with a limited number of MediaWiki extensions that are not included in the default MediaWiki installation. Some of these extensions are maintained by the MediaWiki community and are not vetted by the Wikimedia Foundation.

Additionally, users can choose to install arbitrary MediaWiki extensions by configuring the charm with a custom composer.json file. Risk is minimized by installing the extensions with a non-root user with write permissions against the webroot, but it is still prudent to only install trusted extensions. Changes to the extensions installed take effect once a change in the configured composer.json file is detected.

File uploads¶

The MediaWiki charm allows for file uploads to S3-compatible object storage. By default, uploaded files are scanned using ClamAV for viruses before being stored in the object storage. Definitions for ClamAV are updated regularly. To ensure that the latest definitions are being used, make sure to add the relevant ClamAV database URLs to your firewall allowlist as described in the allowlist reference documentation.

Even with virus scanning in place, allowing file uploads introduces risk. Refer to the MediaWiki documentation on file uploads for best practices and additional security considerations when allowing file uploads.

SSH keys¶

The MediaWiki charm optionally allows for private SSH keys to be configured using a Juju user secret for use in Git operations, such as when using an extension or skin hosted in a private repository. The SSH keys are injected into the relevant workload containers as needed, in a manner which ensures that they are inaccessible to the web server process.

To reduce risk further, ensure that the SSH key is properly scoped with read-only permissions, only has read permissions, and does not have access to unnecessary resources. Only add trustworthy hosts to the ssh-known-hosts configuration option.

Static assets¶

When using syncing in static assets from a Git repository, all contents of the repository other than hidden files will be in the webroot and are thus served by the web server.

To prevent abuse, make sure that the remote repository is trustworthy and configure a git reference instead of using the default branch’s HEAD. Also, it is recommended to use the static-assets-git-sparse-checkout configuration option to only checkout necessary files from the repository.

HTTP¶

The MediaWiki charm does function behind an HTTP endpoint or with a protocol-relative URL. However, it is highly recommended to configure MediaWiki to operate as HTTPS-only, especially if using OAuth or SSO.

To accomplish this, the charm’s url-origin configuration key should be set to a HTTPS scheme and the $wgForceHTTPS configuration parameter should be set to true via the charm’s local-settings configuration key. For more details, refer to the official MediaWiki documentation on HTTPS.