19 New PHP Checks
Last Tuesday we announced 8 new PHP checks, and promised more were on the way.
Today, we’re releasing 19 new checks, which identify security, logical and clarity issues in your PHP code. Each new check is outlined below, by category.
Security
Changing PHP configuration dynamically
Some PHP functions are able to dynamically change properties of the system while running. Doing so can make assumptions about the structure and configuration of the running environment, limiting portability and creating potential security and performance issues.
Using debug functions
The information provided by debugging functions may inadvertently make private information public, which is a security risk.
Changing the error display levels at runtime
The error reporting level should not be changed at runtime as a consistent method should be used throughout your application to prevent accidental data leakage.
Using
echo
withfile_get_contents
The
file_get_contents
function reads the contents of a file into a string. Because this requires accessing files on the server’s file system, it is already necessary to use caution when using this function in application code. When combined with theecho
function, code that has been read from the file system withfile_get_contents
is now being displayed, which creates a security risk.Using *
parse_str
functionsWhile these are convenient for evaluating query parameters into in-memory variables, these functions have potential security and clarity issues and should be avoided where possible.
Usage of the
pass thru
commandThis method should be very selectively used because of potential security and performance issues.
Using
/e
in regular expression modifierThe
/e
regular expression modifier has been deprecated for security reasons. Using it has the dangerous side effect that the resulting string from the regular expression is evaluated as code.Using the superglobal
$_REQUEST
Since this variables combines various data from user input, it can lead to data loss as well as Delayed Cross Site Request Forgery and Session Fixation vulnerabilities.
Usage of script-delaying functions
Delaying the completion of a script opens your system up to Denial of Service (DoS) attacks as it ties up server resources for the duration of the script, putting you at risk for exceeding your available PHP processes, database connections, and other server resources.
Usage of the
system
commandThis method should be very selectively used because of potential security and performance issues.
Bug Risk
Not using the identical operator when comparing booleans
Failure to use the comparison operator (
===
) when comparing booleans can lead to unexpected results.Usage of
exit
ordie
Usage of these calls tends to result in poor user experience, hard to re-use code, and in some cases, inadvertent exposure of sensitive information.
Use of deprecated
$http_raw_post_data
Code that relies on
$http_raw_post_data
will eventually fail in future versions of PHP. Additionally, because$http_raw_post_data
depends on a special ini directive in order to be populated, using it decreases the portability of your program.
Clarity
Using more than one
Class
per fileKeeping one class per file ensures a clean, understandable file structure
High cyclomatic complexity
Cyclomatic complexity correlates the number of potential pathways through a given unit of code with complexity - a unit of code with a lot of potential pathways will have a high cyclomatic complexity score.
Long classes
The longer a class is, the harder it is to break down, test, and adequately express with a great name. Classes that are long will grow over time and become harder to manage, so it is usually a worthwhile investment to simplify classes by refactoring into smaller, more discrete units of functionality.
Long methods
Methods that are too long are error prone, hard to understand, difficult to test, and tend to grow in size over time. All of these issues are design related and documenting, testing, and breaking down large methods into smaller ones is one of the best ways to simplify class structure and clarify design.
Long variable names
Using excessively long variable names makes code difficult to scan easily and can be confusing. Long variable names are also a hassle to type and are prone to typos.
Short variable names
Short variable names convey too little information at best and are confusing or error prone at worst. Using an abbreviated or meaningless name for a variable destroys its intent-conveying purpose, which can make code difficult to read and debug.