, (*1)
PLEASE NOTE: This tool is still in a very early stage. The work continues..., (*2)
The Parse scanner is a static scanning tool to review your PHP code for potential security-related
issues. A static scanner means that the code is not executed and tested via a web interface (that's
dynamic testing). Instead, the scanner looks through your code and checks for certain markers and notifies
you when any are found., (*3)
For example, you really shouldn't be using eval in your code anywhere if you can
help it. When the scanner runs, it will parse down each of your files and look for any eval() calls.
If it finds any, it adds that match to the file and reports it in the results., (*4)
Installation
Install as a development dependency in your project using composer:, (*5)
composer require --dev psecio/parse
The path to the installed executable may vary depending on your
bin-dir setting. With the
default value parse is located at vendor/bin/psecio-parse., (*6)
For a system-wide installation use:, (*7)
composer global require psecio/parse
Make sure you have ~/.composer/vendor/bin/ in your path., (*8)
Usage
NOTE: In version 0.6 the executable was renamed psecio-parse. In earlier
versions the tool was simply named parse., (*9)
NOTE: In version 0.4 and earlier the --target option was used to specify the
project path, this is no longer supported. Use the syntax below., (*10)
To use the scanner execute it from the command line:, (*11)
psecio-parse scan /path/to/my/project
For more detailed information see the help and list commands., (*12)
psecio-parse help scan
Currently console (dots), xml and json output formats are available. Set format with the --format option., (*13)
psecio-parse scan --format=xml /path/to/my/project
psecio-parse scan --format=dots /path/to/my/project
psecio-parse scan --format=json /path/to/my/project
The console formats supports setting the verbosity using the -v or -vv switch., (*14)
psecio-parse scan -vv /path/to/my/project
If your platform does not support ANSI codes, or if you want to redirect the console output
to a file, use the --no-ansi option., (*15)
psecio-parse scan --no-ansi /path/to/my/project > filename
Listing the checks
You can also get a listing of the current checks being done with the rules command:, (*16)
psecio-parse rules
Managing rules to run
There are several ways to control which rules are run. You can specifically include rules using
the --include-rules option, specifically exclude them with --exclude-rules, turn them on and
off on a case-by-case basis using annotations, and disable annotations using
--disable-annotations., (*17)
Excluding and Including rules
By default, psecio-parse scan includes all available rules in its scan. By using
--exclude-rules and --include-rules, the rules included can be reduced., (*18)
Any rules specified by --exclude-rules are explicitly excluded from the scan, regardless of any
other options selected. These rules cannot be added back to the scan, short of re-running the scan
with different options. Invalid rules are silently ignored., (*19)
If --include-rules is provided, only those rules specified can be used. No other rules are
checked. Note that rules that aren't available (whether they do not exist or --excluded-rules is
used to exclude them) cannot be included. Invalid rules are silently ignored., (*20)
Annotations
Rules can be enabled and disabled using DocBlock annotations. These are comments in the code being
scanned that tells Parse to specifically enable or disable a rule for the block of code the
DocBlock applies to., (*21)
-
@psecio\parse\disable <rule>: Tells Parse to ignore the given rule for the scope of the
DocBlock.
-
@psecio\parse\enable <rule>: Tells Parse to enable the given rule for the scope of the
DocBlock. This can be used to re-enable a particular rule when @psecio\parse\disable has been
applied to the containing scope.
Note that annotations cannot enable tests that have been omitted via the command line options. If
a test is disabled at the command line, it is disabled for the entire scan, regardless of any
annotations., (*22)
Comments can be added after <rule> following a dobule-slash (//) comment separator. It is
recommended that comments be used to indicate why the rule has been disabled or enabled., (*23)
To disable the use of annotations, use the --disable-annotations option., (*24)
See the examples directory for some examples of the use of annotations for Parse., (*25)
The Checks
Here's the current list of checks:, (*26)
- Warn when sensitive values are committed (as defined by a variable like "username" set to a string)
- Warn when
display_errors is enabled manually
- Avoid the use of
eval()
- Avoid the use of
exit or die()
- Avoid the use of logical operators (ex. using
and over &&)
- Avoid the use of the
ereg* functions (now deprecated)
- Ensure that the second parameter of
extract is set to not overwrite (not EXTR_OVERWRITE)
- Checking output methods (
echo, print, printf, print_r, vprintf, sprintf) that use variables in their options
- Ensuring you're not using
echo with file_get_contents
- Testing for the system execution functions and shell exec (backticks)
- Use of
readfile, readlink and readgzfile
- Using
parse_str or mb_parse_str (writes values to the local scope)
- Warn if a
.phps file is found
- Using
session_regenerate_id either without a parameter or using false
- Avoid use of
$_REQUEST (know where your data is coming from)
- Don't use
mysql_real_escape_string
- Avoiding use of
import_request_variables
- Avoid use of
$GLOBALS
- Ensure the use of type checking validating against booleans (
===)
- Ensure that the
/e modifier isn't used in regular expressions (execute)
- Using concatenation in
header() calls
- Avoiding the use of $http_raw_post_data
Plenty more to come... (yup, @todo), (*27)
TODO
See the current issues list for @todo items..., (*28)
Parse is covered under the MIT license., (*29)
@author Chris Cornutt (ccornutt@phpdeveloper.org), (*30)
Wallogit.com
