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.
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.
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:
- The plugin contains a vulnerability which could be exploited by an end user and which would compromise the site’s confidentiality, integrity or availability.
- 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:
- 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.
- The plugin appears not to be vulnerable, but could interact with another component in such a way as to become vulnerable.
- 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.
- 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.
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.
|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):
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.
The plugin exhibits idioms or lack of structure indicative of its author being an inexperienced developer, for example:
|Failure to use available core functionality||
The plugin fails to use functions available in the core API where appropriate, for example:
|Unsafe request processing||
The plugin generates or processes requests unsafely, for example:
|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:
|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.