MediaWiki

Core Infrastructure Initiative Best Practices badge

This is a page to document MediaWiki's compliance with https://bestpractices.coreinfrastructure.org/

Current Status: cii best practicesin progress 95%

Stuff that we do, should generally be documented in the appropriate places for the respective topic.

Stuff we don't do yet, or are not sure if we do yet

edit

Bug reporting process

edit
  • The project MUST acknowledge a majority of bug reports submitted in the last 2-12 months (inclusive); the response need not include a fix.
    • No stats on this. Let's try checking a sample of ~25 reports?
    • Probably not.
  • The project SHOULD respond to most enhancement requests in the last 2-12 months (inclusive). The project MAY choose not to respond.
    • ditto

Vulnerability reporting process

edit
  • The project's initial response time for any vulnerability report received in the last 6 months MUST be less than or equal to 14 days.
    • I (bawolff) think this is true, if you exclude bugs that are written by developers as future todo's. But I don't have any stats to back up
    • security@wikimedia.org is an e-mail alias.
      • Usually anything legit gets immediately put into Phabricator.

Automated test suite

edit

New functionality testing

edit
  • The project MUST have evidence that such tests are being added in the most recent major changes to the project
  • It is SUGGESTED that this policy on adding tests be documented in the instructions for change proposals.

Warning flags

edit
  • It is SUGGESTED that projects be maximally strict with warnings, but this is not always practical
    • Maybe an N/A? Maybe Met? This is user controlled in PHP. Most devs put it on, but disable on production.
    • This seems about compiler warnings, testing suite complaints and the like: unclear how it applies to MediaWiki.
      • I was thinking if maybe meant php error_reporting config directive. We also internally have $wgDevelopmentWarnings.

Good cryptographic practices

edit
  • The project's cryptographic software MUST use by default only cryptographic protocols and algorithms that are publicly published and reviewed by experts.
    • This is met to the best of my knowledge
  • The project security mechanisms MUST use default keylengths that at least meet the NIST minimum requirements through the year 2030 (as stated in 2012)
    • This is N/A mostly. Although we do use hashes for some purposes that are less than their requirement (hmac-md5 is used in edit tokens. md5 is used in certain non-security critical places (e.g. in certain cache keys to ensure non-ascii characters aren't used in the cache key). Sha1 is used all over the place, but again in mostly non-security critical locations).
  • The project SHOULD implement perfect forward secrecy for key agreement protocols so a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in the future.
    • N/A. Either the lower layer's job (webserver) for receiving https requests, or the PHP's openSSL extension's job (when making HTTPS requests)
  • The project MUST generate all cryptographic keys and nonces using a cryptographically secure random number generator, and MUST NOT do so using generators that are not cryptographically secure
    • There are certain secrets which will use weak randomness if the system doesn't support strong randomness. These should be very rare edge cases. See MWCryptRand::realGenerate().

Publicly-known vulnerabilities fixed

edit
  • Projects SHOULD fix all critical vulnerabilities rapidly after they are reported.   Done
    • Define rapidly? We try to do our best, but we could probably be better.
    • We don't have tools to tell how long it takes nowadays. Can something be extracted from MITRE?
    • Apparently we're doing well enough.
  • The public repositories MUST NOT leak a valid private credential (e.g., a working password or private key) that is intended to limit public access.   Done
    • Met to the best of my knowledge. If anyone is aware of a public repo with a secret key in it, they should report to security@wikimedia.org

Static code analysis

edit
  • It is SUGGESTED that at least one of the static analysis tools used for the static_analysis criterion include rules or approaches to look for common vulnerabilities in the analyzed language or environment.
    • For non-security static analysis, we run Phan and CodeSniffer on every commit
    • We are working on our own custom security static analysis tool, which runs as part of Phan: phan-taint-check-plugin. It is currently running on many extensions, but is not yet running on core.
    • Historically we used veracode - phab:T110617.
    • Some repositories appear to use the PhpStorm static analysis every now and then.
  • It is SUGGESTED that static source code analysis occur on every commit or at least daily
    • Currently once a week, so unmet.[1]
    • All Wikimedia production extensions are now running phan-taint-check for security static analysis, as part of the Phan CI job. Some extensions include it in their composer.json.

Dynamic analysis

edit

Wikimedia Security Team/ApplicationScanning?

  • It is SUGGESTED that at least one dynamic analysis tool be applied to any proposed major production release of the software before its release.
    • Unmet
  • It is SUGGESTED that if the software is application-level software written using a memory-unsafe language (e.g., C or C++) then at least one dynamic tool (e.g., a fuzzer or web application scanner) be routinely used with a mechanism to detect memory safety problems such as buffer overwrites.   Done
  • It is SUGGESTED that the software include many run-time assertions that are checked during dynamic analysis.
    • Unmet i guess?

Future

edit
  • The project SHOULD provide a way to easily install and uninstall the software using a commonly-used convention. Examples include using a package manager (at the system or language level), "make install/uninstall" (supporting DESTDIR), a container in a standard format, or a virtual machine image in a standard format. The installation and uninstallation process (e.g., its packaging) MAY be implemented by a third party as long as it is FLOSS.
    • N/A kind of ish. Unistall instructions are drop database mywiki; and rm -rf mediawiki ;)
  • The project SHOULD, if it supports TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL. [crypto_tls12]
    • PHP openssl extension is high enough/ webserver high enough, this is met. Maybe its n/a ?
  • The project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on subresources.
  • The project SHOULD, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies)
    • N/A That's the webserver's job.
  • It is SUGGESTED that the project website, repository (if accessible via the web), and download site (if separate) include key hardening headers with nonpermissive values. https://securityheaders.io/?q=https%3A%2F%2Fwww.mediawiki.org%2F&followRedirects=on
    • Unmet. Content-Security-Policy is sort of being worked on. Public-Key-Pins is talked about phab:T92002 (Also not really a MW level header), X-Frame-Options is only on special pages, and edit pages (unless $wgBreakFrames is true). X-XSS-Protection is currently not set (Maybe it should be?). Strict-Transport-Security is set on Wikimedia websites, but generally considered not mediawiki's responsibility, so not set by MW.
  • It is SUGGESTED that hardening mechanisms be used so software defects are less likely to result in security vulnerabilities.
    • Unmet for the moment, but CSP is being worked on.
    • SELinux?

Learning resources

edit
Retrieved from "https://www.mediawiki.org/w/index.php?title=Core_Infrastructure_Initiative_Best_Practices_badge&oldid=3905985"