User:SBassett (WMF)/Security Review Howto Extensions

The documentation below describes some typical steps followed by members of the Wikimedia Security Team when security-reviewing mediawiki extensions. Note that this does not necessarily list every step followed by every engineer, nor does it go into extensive detail for each step. The hope is that this page becomes a set of general guidelines and best practices for security-reviewing mediawiki extensions for both foundation and community members.

Initial Items to Confirm
Have the requestors:
 * 1) followed the security review process?  Specifically, have they filled out a security review request within phabricator?
 * 2) confirmed that there is an actual plan for the extension to be deployed to production (rfc, quarterly goal, sre/ops buy-in, beta-testing, scheduled launch date, etc.)?
 * 3) provided an adequate explanation of what the extension does?  e.g. a   or Mediawiki documentation page?
 * 4) provided a working development environment with appropriate instructions (vagrant role, docker, installation notes, etc.)?
 * 5) followed the basic Mediawiki security guidelines for developing code?

Basic and Automated Checks
Several basic and/or automated checks can be performed against extension codebases during a security review. These include:
 * 1) Building out the extension within a local test environment to analyze its functionality from a user's perspective.
 * 2) Reviewing and running any associated unit/integration tests (phpunit, qunit) for a better understanding of how the extension works and critical code paths.
 * 3) Testing portions of the code via shell.php or similar tools.
 * 4) Search for CVEs and other reported vulnerabilities for vendor code, etc. (nist, snyk, snort, github issues pages, etc.)
 * 5) Security headers check.
 * 6) SSL cert check.
 * 7) CSP check.
 * 8) Searching for various backup and unused files.
 * 9) Searching for   and similar leaks.
 * 10) Running various language- or platform-specific linters and static analysis tools against the codebase.
 * 11) Running the php security tools docker against the codebase.

Further Analysis
Most extensions will require more rigorous, manual analysis of the code, which will be heavily dependent upon the extension being reviewed. Some general examples of such analysis would include:


 * 1) A more in-depth, contextual analysis of the extension and how it interacts with core components and extensions.
 * 2) Automated DAST scanning via various tools (zap, wapiti, nikto, arachni, burp, etc.)
 * 3) Compliance with various privacy and internal policies (see: L3, wikimedia, WMCS TOU)
 * 4) User data collection and exposure, such as PII, IP address and User Agent.
 * 5) Authentication and authorization methods.
 * 6) Common application weaknesses, vulnerabilities and exposures (OWASP, CAPEC, CWE, etc.)
 * 7) Code quality issues, not necessarily related to security.

Here are some examples of some more in-depth security reviews:


 * 1) [[phab:T149869#3062239|PageForms - T149869]
 * 2) [[phab:T133408#2362073|TemplateStyles - T133408]

References and Tools

 * 1) wikimedia code search