Plugin inspections

A plugin inspection is a light-touch assurance exercise, intended to identify plugins which are likely to present security issues.

How we inspect plugins

During a plugin inspection, the tester scans the codebase of the plugin for particular keywords that relate to the inspection criteria given below. Matches are then manually reviewed to check for issues of concern. When a match is being reviewed, the code path leading to and/or from the match is often reviewed as well, along with the immediately surrounding code. An inspection is an attempt to obtain some assurance about the quality of a plugin without going to the time and expense of a plugin review.

During an inspection, the tester will look for instances of the failure criteria given below. A plugin inspection which finds issues should give you confidence that the plugin is likely to contain issues of concern which you should carefully consider. If we do not find issues, you should conduct your own checks to ensure that you agree with our findings. A review is not a substitute for security best-practices.

Inspections which conclude that a plugin is vulnerable in a particular configuration will result in a recommendation which assumes that the vulnerable configuration is present. The rationale for this is:

  • It is not possible within the scope of an inspection to enumerate potentially vulnerable configurations or to decide how likely it is that a given configuration will be in use, or how widespread such use might be;
  • In our experience, when users are given the option to enable something vulnerable, they will eventually do so (even if warned to the contrary).

If greater assurance is required, a code review should be conducted.

Results

The outputs of a plugin inspection are a list of the matched criteria from the list below, accompanied with a short description of the findings and a recommendation.

While testers should, in general, follow the criteria in this section when making recommendations, they may at their discretion make any recommendation. However, if the recommendation is not based on one of the criteria given below, the tester must obtain a second opinion and must explain the reason for their decision.

Possible recommendations

Potentially unsafe

This plugin should not be used unless very careful consideration is given to the vulnerabilities it contains and ways to mitigate them.

One of the following conditions must be true:

  1. The plugin contains a vulnerability which could be exploited by an end user and which would compromise the site’s confidentiality, integrity or availability.
  2. The plugin is written such that its expected, ordinary use could affect the site’s confidentiality, integrity or availability.

Use with caution

The plugin could be used but its use should be carefully considered.

One of the following conditions must be true:

  1. The plugin contains a vulnerability which could be exploited by a privileged user to affect the site’s confidentiality, integrity or availability in a manner exceeding the user’s privileges.
  2. The plugin appears not to be vulnerable, but could interact with another component in such a way as to become vulnerable.
  3. The plugin meets a large number of failure criteria and is of poor quality, leading the tester to fear that subsequent versions of the plugin are likely to introduce vulnerabilities.
  4. The plugin is written such that its expected, ordinary use is likely to harm the site’s performance.

No issues found

No issues were found or the issues identified were minor.

The plugin appears to be safe for use.

Failure criteria

Plugin inspections require human judgement and should not be conducted mechanistically. These criteria are a guide to the sorts of issues that an inspection should consider.

The presence of a problem described here does not necessarily indicate that a plugin should fail an inspection, or be given a “caution” rating. It’s important to consider the impact of the problems that are found and to balance all the relevant factors.

Failure criteria
Criterion Explanation
Lack of input sanitisation

The plugin accesses and uses data from user input without sufficient sanitisation.
Execution of unprepared SQL statements

The plugin executes unprepared SQL statements without sufficient sanitisation.
Unsafe generation of PHP code

The plugin generates and executes PHP code from user-influenceable variables using (for example) eval or create_function.
Poor coding style

Exhibits the characteristics of poor coding style, including (but not limited to):

  1. Lack of indenting
  2. Inconsistent indenting
  3. Code which produces notices
  4. Lack of clear commenting where it would be appropriate; ie, to explain complex functionality or dense code

Note: This failure criterion is not subjective and is not met merely because of a difference in opinion about good style, or because of a few examples of inconsistency or bad practice. The lack of good style must materially reduce the tester’s ability to understand what the code is doing, thereby indicating that the lack of good style has reduced code readability and maintainability.
Poor architecture

The plugin exhibits idioms or lack of structure indicative of its author being an inexperienced developer, for example:

  1. Repetitive use of code which could be factored out
  2. Use of conditions or language structures which are illogical, unnecessary, unreachable or otherwise betray a lack of structured approach
  3. Long, unwieldy functions
  4. Multiple, unrelated long sequences of code in a single file
  5. Lack of object oriented code where it would be appropriate; failure to use well-known design patterns to solve common problems
  6. Use of deprecated PHP or WordPress functions.
Failure to use available core functionality

The plugin fails to use functions available in the core API where appropriate, for example:

  1. Use of htmlspecialchars() rather than esc_html(), etc
  2. Failure to use correct functions for enqueuing CSS and JavaScript assets
  3. Failure to use definitions such as WP_CONTENT_DIR as appropriate
  4. Use of deprecated WordPress API functions.
Unsafe request processing

The plugin generates or processes requests unsafely, for example:

  1. Failure to use nonces to protect admin operations
  2. Use of confidential information in query strings.
Unsafe file or network IO

The function does not properly escape arguments to IO functions, allowing local files to be included or network calls to be made.

The plugin makes unsafe assumptions about the locations of files and directories and their permissions.
Emits unescaped variables

The plugin outputs potentially user-influenceable variables without escaping them.
Unsafe execution of system commands

The plugin executes system commands without sufficient sanitisation.
Potential compatibility issues

The plugin is written in such a way that compatibility issues may exist when it is combined with other plugins, or themes with complex functionality. For example:

  1. The plugin does not use protocol-relative URLs and may not function properly under HTTPS
  2. The plugin passes unsanitised input into filters or actions.
Very large codebase

The plugin contains more than 15,000 source lines of code. As such, it is more likely than a smaller plugin to contain exploitable issues.

Note: this is not in itself a failure criterion, but is often a factor when considered alongside other findings. Additionally, the very restrictive scope of a plugin inspection means that very large plugins usually cannot be inspected thoroughly.