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 (Against an appropriate staging environment.)
 * 6) SSL cert check (Against an appropriate staging environment.)
 * 7) CSP check (Against an appropriate staging environment.)
 * 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) Compliance with various privacy and internal policies (see: L3, wikimedia, WMCS TOU)
 * 3) User data collection and exposure, such as PII, IP address and User Agent.
 * 4) Authentication and authorization methods.
 * 5) Common application weaknesses, vulnerabilities and exposures (OWASP, CAPEC, CWE, etc.)
 * 6) Automated DAST scanning via various tools (zap, wapiti, nikto, arachni, burp, etc.)
 * 7) Code quality issues, not necessarily related to security (see mediawiki style guide, etc.)

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


 * 1) PageForms - T149869
 * 2) TemplateStyles - T133408

References and Tools

 * 1) wikimedia code search