Jump to content

Core Infrastructure Initiative Best Practices badge

From mediawiki.org

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. Yes 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. Yes 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. Yes 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"