psecio/iniscan

A php.ini scanner for best security practices

iniscan's Issues

[InvalidArgumentException] Unknown path register_globals

This is what i'm getting when running it against my homebrew php5.5 standard php.ini

[InvalidArgumentException]
Unknown path register_globals

Any ideas?

Error for deprecated directives like "magic_quotes_gpc"

I'm using the latest version of iniscan and PHP 5.5. My php.ini file does not contain any deprecated directives but iniscan reports errors for them (I've filed a similar issue last year: #47).

$ vendor/bin/iniscan scan
== Executing INI Scan [08.11.2014 07:11:55] ==

Results for /etc/php/cli-php5.5/php.ini:
============
Status | Severity | PHP Version | Key                      | Description
----------------------------------------------------------------------
...
FAIL   | ERROR    |             | magic_quotes_gpc         | Magic quotes automatically adds quotes to incoming data ('Off' recommended)
FAIL   | ERROR    |             | magic_quotes_runtime     | Magic quotes should be disabled at runtime in addition to being off for incoming data
...
FAIL   | ERROR    |             | safe_mode                | It's not actually 'safe' ('Off' recommended)
...

19 passing
5 failure(s) and 13 warnings

Where in the source code does iniscan check if a configuration directive exists in php.ini?

The configuration file could not be found

I tried the following and it gives me the below error

curl -LSs http://box-project.org/installer.php | php
php box.phar build

[RuntimeException]
The configuration file could not be found.

build [-c|--configuration="..."]

I also tried the following but looks like configuration is some kind of json file
php box.phar build --configuration="/etc/php5/cli/php.ini"

config-file-scan-dir ini files missed, which may contain additional config

Since PHP includes additional ini files at runtime using --with-config-file-scan-dir, some configuration might be missed.

This kind of thing can be detected in the PHP instance for the currently loaded ini settings using php_ini_scanned_files().

They usually contain extension config, but could additionally set base PHP ini settings.

Add ruleset contexts

Consider providing different contexts for rulesets ("development" vs "staging" vs "production") if this doesn't already exist.

Scan returns incorrect results for missing php.ini directives

If the php.ini doesn't define all directives that are checked, the scan will produce an incorrect result if the rule requires a value the same as the PHP default.

Example:

Environment is PHP 5.3 on Mac OX 10.8

$ php -v
PHP 5.3.15 with Suhosin-Patch (cli) (built: Dec  9 2012 19:32:02) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies

The ini file in use is empty except for section headers (due to #57) :

$ head -5 php.ini.sections-only 
[PHP]
[Date]
[filter]
[iconv]
[intl]

When PHP is run with this ini file, safe_mode is Off (the default in 5.3).

$ php -i -c php.ini.sections-only | grep '^safe_mode =>'
safe_mode => Off => Off

The scan output shows "FAIL" for safe_mode:

$ bin/iniscan scan --path=php.ini.sections-only --fail-only

Results for php.ini.sections-only:
============
Status | Severity | Key                      | Description
----------------------------------------------------------------------
FAIL   | ERROR    | session.use_cookies      | Accepts cookies to manage sessions
FAIL   | ERROR    | session.use_only_cookies | Must use cookies to manage sessions, don't accept session-ids in a link
FAIL   | WARNING  | session.cookie_domain    | It is recommended that you set the default domain for cookies.
FAIL   | ERROR    | session.cookie_httponly  | Setting session cookies to 'http only' makes them only readable by the browser
FAIL   | ERROR    | session.use_trans_sid    | If used 'use_trans_sid' setting puts the session ID on the URL, making it easier to hijack
FAIL   | ERROR    | session.cookie_secure    | Cookie secure specifies whether cookies should only be sent over secure connections.
FAIL   | ERROR    | allow_url_fopen          | Do not allow the opening of remote file resources ('Off' recommended)
FAIL   | ERROR    | allow_url_include        | Do not allow the inclusion of remote file resources ('Off' recommended)
FAIL   | WARNING  | display_errors           | Don't show errors in production ('Off' recommended)
FAIL   | WARNING  | log_errors               | Log errors in production ('On' recommended)
FAIL   | ERROR    | magic_quotes_gpc         | Magic quotes automatically adds quotes to incoming data ('Off' recommended)
FAIL   | ERROR    | magic_quotes_runtime     | Magic quotes should be disabled at runtime in addition to being off for incoming data
FAIL   | ERROR    | safe_mode                | It's not actually 'safe' ('Off' recommended)
FAIL   | WARNING  | max_input_vars           | A maximum number of input variables should be defined to prevent performance issues
FAIL   | WARNING  | display_startup_errors   | Showing startup errors could provide extra information to potential attackers
FAIL   | WARNING  | open_basedir             | Restricting PHP's access to the file system to a certain directory prevents file-based attacks in unauthorized areas.
FAIL   | WARNING  | error_reporting          | Error reporting should be different based on context, off in production
FAIL   | WARNING  | upload_max_filesize      | A maximum upload size should be defined to prevent server overload from large requests
FAIL   | WARNING  | memory_limit             | A memory limit should be defined to prevent server overload from large processes
FAIL   | WARNING  | disable_functions        | Methods still enabled - exec, passthru, shell_exec, system, proc_open, popen, curl_exec, curl_multi_exec

8 passing
20 failure(s)

Add check for max_input_vars

Limiting the max_input_vars to something reasonable can help prevent things like DoS from overloading. Should be a "warning".

Have process return a valid CLI code

If the scan passes, one could should be retuned (?) and on any failures another.

Not sure offhand what these should be or if the Symfony Console component supports these return codes. This is so that other apps running it can determine pass/fail without needing to parse the output.

Problem installing on PHP 7 (ocramius/instantiator dependency)

Hi,

There is problem when installing using composer global,

• ocramius/instantiator 1.1.2 requires php ~5.3 -> your PHP version (7.0.3) or "config.platform.php" value does not satisfy that requirement.

because of out of date dependency ocramius/instantiator, which is apparently abandoned:

This package is abandoned and no longer maintained. The author suggests using the doctrine/instantiator package instead.

BR,
Peter

Add functionality to handle deprecated settings

Things like "register_globals" have been completely removed from the php.ini in more recent versions (like PHP 5.4). Right now these will throw a "not found" error and stop evaluation.

Add crowd-sourcing of rulesets

Consider creating a website or other such interface to allow user submissions of rulesets for inclusion in the scanner, and then crowd-source their validity or correctness (via voting or other such mechanism).

Scan fails with missing ini sections

This particular example is overkill, but it displays the problem:

$ touch php.ini.empty
$ bin/iniscan scan --path=php.ini.empty 
   ERROR:                    
   [0] Unknown section Session

Duplicate "post_max_size" rule

This rule exists in two places:

1. https://github.com/psecio/iniscan/blob/master/src/Psecio/Iniscan/rules.json (twice)
2. https://github.com/psecio/iniscan/blob/master/src/Psecio/Iniscan/Rule/MaximumPostSize.php

== Executing INI Scan [09.02.2014 12:47:18] ==
...
FAIL   | WARNING  |             | post_max_size            | Unless necessary, a maximum post size of 16M is too large
...
PASS   | WARNING  |             | post_max_size            | A maximum post size should be defined to prevent server overload from large requests
FAIL   | WARNING  |             | post_max_size            | The max upload size should not be too high, to prevent server overload from large requests
...

The first and third warning are duplicates.

allow for addition of custom checks

There may be custom settings you want to check in the php.ini, so there should be a way to add in these without having to update the rules.json configuration.

Add "env" option to the scanner

By default, iniscan assumes a production environment so it's reports are the strictest. Since this may not always be the desired environment, an "env" option should be added as well as functionality to relax some checks when the env is set to a non-"PROD" environment.

Support for php-fpm.conf

Quite a few settings are defined per pool when using PHP-FPM, so only scanning php.ini doesn't give the full picture.

Add "threshold" option

There should be an option added to the "scan" command to only show things at or above the threshold that failed.

For example:
./bin/iniscan scan --path=/path/to/php.ini --threshold=ERROR

would show ERRORs and above (FATAL?)

Add some descriptions to the checks

It would be nice to have a verbose mode, with some text why the current value is bad and why the recommended setting is a good one. Also some further reading (Links to articles for this issue) would be nice.

allow_url_include value unrecognized

In my php.ini

allow_url_fopen = Off
allow_url_include = Off

For this, iniscan gives:

FAIL   | ERROR    | allow_url_fopen          | Do not allow the opening of remote file resoources ('Off' recommended)
FAIL   | ERROR    | allow_url_include        | Do not allow the inclusion of remote file resources ('Off' recommended)

If I change php.ini like so:

allow_url_fopen = 'Off'
allow_url_include = 'Off'

iniscan gives an odd result:

PASS   | ERROR    | allow_url_fopen          | Do not allow the opening of remote file resoources ('Off' recommended)
PASS   | ERROR    | allow_url_include        | Do not allow the inclusion of remote file resources ('Off' recommended)

Btw, using 0 (zero) values gives the same result as the first one.

False warning about "deprecated configuration items"

I'm using PHP 5.4(.21) and none of the following 5 directives that iniscan complains about exist in my php.ini:

WARNING: deprecated configuration items found:
-> register_globals
-> magic_quotes_gpc
-> magic_quotes_runtime
-> safe_mode
-> register_long_arrays

Xdebug disabled

For additional security in a production environment, if Xdebug is installed it should be turned off.

xdebug.remote_enable=1

setup

Probably not the worst idea to make people aware of the global require:

$ ./composer.phar global require "psecio/iniscan=dev-master"

Uses ~/.composer/composer.json, then invoke with:

$ ~/.composer/vendor/bin/iniscan

Update rules find to be recursive

Right now the "get rules" only looks in one directory, but there will soon be nested check (a CVE directory), so the find needs to use something like a RecursiveDirectoryIterator to find things under Psecio/Iniscan/Rule.

Changing some of the functionality into a Bundle?

I'm not overly familiar with the bundling system Symfony implements, so I thought I'd put out a suggestion to those more Symfony-minded to see if it made sense to move some of the current functionality into a reusable bundle. The commands all use the Symfony Console component already.

Not sure if it'd be work the work or not...I'd love some input on it.

Add additional session checks

Check for valid values of:

• session.entropy_file
• session.entropy_length
• session.use_strict_mode
• session.use_only_cookies
• session.cookie_lifetime
• session.use_trans_sid
• session.hash_function (set to 1)
• session.bug_compat_42 (set to 0)
• session.bug_compat_warn (set to 0)

http://www.php.net/manual/en/session.configuration.php

PHP 5.4+: register_long_arrays false positive

In PHP 5.4 the "register_long_arrays" directive has been removed (http://www.php.net/manual/en/ini.core.php#ini.register-long-arrays). It therefore does not exist in my php.ini file. But iniscan throws the following warning:

FAIL   | WARNING  | register_long_arrays     | Registering long arrays turns on the HTTP_*_VARS (Recommended Off)

report on config that should no longer be there

As we have a "deprecated" array defined in the json, the tool should be able to look at the PHP version it's currently using and the one the setting was deprecated in to see if it should be removed.

For example, if you're using PHP 5.4 you no longer even need a "register_globals" or "magic_quotes_gpc" setting as they are deprecated to be removed.

This information should be included in the normal output, not via a thrown exception or anything.

usage of Console TableHelper

TableHelper should be used instead of formatting table by hand.

http://symfony.com/doc/current/components/console/helpers/tablehelper.html

PHP warnings when using memcache session handler

Hey,

i get the following warnings when using the scan command with a php.ini that has memcache session handlers configured:

$ vendor/bin/iniscan scan --path=php.ini
Warning: fileperms(): Unable to find the wrapper "tcp" - did you forget to enable it when you configured PHP? in /home/patryk/composer/vendor/psecio/iniscan/src/Psecio/Iniscan/Rule/CheckSessionPath.php on line 24
Warning: fileperms(): Unable to find the wrapper "tcp" - did you forget to enable it when you configured PHP? in /home/patryk/composer/vendor/psecio/iniscan/src/Psecio/Iniscan/Rule/CheckSessionPath.php on line 24
Warning: fileperms(): stat failed for tcp://127.0.0.1:11211 in /home/patryk/composer/vendor/psecio/iniscan/src/Psecio/Iniscan/Rule/CheckSessionPath.php on line 24

Cheers,
Patryk

Make "web enabled" example

Since the web and CLI configuration can be separate from the web config, an example of using it in a web-facing environment needs to be made.

Expose PHP flag error

Hi I have got expose_php = Off in my php.ini, but the tool shows:

FAIL   | WARNING  | expose_php : Showing the PHP signature exposes additional information

My PHP version: 5.4.21
Is this a bug?

Add custom rule check for CVE20121823

CVE20121823
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1823
http://www.exploit-db.com/exploits/29290/

sapi/cgi/cgi_main.c in PHP before 5.3.12 and 5.4.x before 5.4.2, when configured as a CGI script (aka php-cgi), does not properly handle query strings that lack an = (equals sign) character, which allows remote attackers to execute arbitrary code by placing command-line options in the query string, related to lack of skipping a certain php_getopt for the 'd' case.

"paranoid" switch

Something fun to have would be a "paranoid" cli option that enforces even more strict checks. This could possibly be implemented with the context handling....

Examples:
https://www.owasp.org/index.php/PHP_Configuration_Cheat_Sheet#some_more_security_paranoid_checks

Add support for configuration dirs

PHP has a setting, which set by default on e.g. Debian/Ubuntu, to load additional configuration files.

Looking at the output of iniscan scan --help I don't see an easy way to mimic this behavior quickly.

Suggestion: let --path also accept a directory by automatically reading all *.ini files in there; that's how PHP itself works

Another observation / suggestion:
Since providing a file/dir (=path) is essentially the required thing to perform anything useful I would suggest to simply drop --path option and use Symfonys arguments which don't require that prefix, effectively turning

iniscan scan --path foo.ini into iniscan scan foo.ini

This would also allow it easier to specify multiple filers, e.g. iniscan scan /etc/php5/cli/conf.d/*.ini

Output reporting in different formats

Right now the output reports as formatted plain text in stdout. An "output" option should be added to the "scan" command to allow for export to:

XML
(others?)

to make for easier parsing by other tools.

Add warning if soap.wsdl_cache_dir is not set for PHP <= 5.6.7 (or if it is set to /tmp at all)

The default soap.wsdl_cache_dir setting in (1) php.ini-production and (2) php.ini-development in PHP through 5.6.7 specifies the /tmp directory, which makes it easier for local users to conduct WSDL injection attacks by creating a file under /tmp with a predictable filename that is used by the get_sdl function in ext/soap/php_sdl.c.

Relevant to this released CVE: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-6501

Add check for CVE-2013-1635 (only for 5.3.22 and 5.4.x before 5.4.13)

ext/soap/soap.c in PHP before 5.3.22 and 5.4.x before 5.4.13 does not validate the relationship between the soap.wsdl_cache_dir directive and the open_basedir directive, which allows remote attackers to bypass intended access restrictions by triggering the creation of cached SOAP WSDL files in an arbitrary directory.

validate that if open_basedir is in effect that the soap.wsdl_cache_dir is inside it

http://www.cvedetails.com/cve/CVE-2013-1635/

security.limit_extensions ?

Wouldn't security.limit_extensions = .php .php3 .php4 .php5 also be useful? Perhaps a warning about cgi.fix_pathinfo?

Show "Current value" column in the scan results table

It would be nice to have it. Also consider having "recommened value" column there.

Define reasonable amount of memory_limit and max_upload_size

Right now it's only checked if these values are set, but not if it's a reasonable amount. Imho is a memory_limit in a php.ini of 1GB or something like that, too much and dangerous, but that also strongly depends on the application.

I would suggest we check for values greater than the PHP default settings (i.e. 128M for memory_limit), and then show a warning, because someone should really think twice of increasing these.

What are your ideas on that?

Create rules related to OWASP recommendations

There's some basic good practices on the OWASP site about php.ini configs - need to create the rules to find those:

https://www.owasp.org/index.php/Configuration#PHP_Configuration

PHP version check

How do you feel about adding a list of PHP versions and their vulnerbility states (cann be used to warn the user if his PHP version needs to be updated)? Would need to either store a resource file (would become outdated quickly) with this data or use an external source to pull a fresh list periodically.

Domain expired

The link http://box-project.org/installer.php is down 😧

Add check for register_long_arrays

Ensure that register_long_arrays is turned off (warning)

Scan::parseConfig() missing argument

Running command:

$ bin/iniscan scan --path=/path/to/php.ini

End with warning:
PHP Warning: Missing argument 1 for Psecio\Iniscan\Scan::parseConfig(), called in /.../iniscan/src/Psecio/Iniscan/Scan.php on line 80 and defined in /.../iniscan/src/Psecio/Iniscan/Scan.php on line 66

Support for open_basedir containing more then one paths set

Currently, if you open_basedir contains more then one path, for example:

open_basedir="/var/www:/php/tmp_cache"

consraints included in CheckSoapWsdlCacheDir and CheckUploadTmpDir are not passing at:

    if ($openBasedir === false) {
        $this->setDescription('The open_basedir did not resolve to a valid directory');
        $this->fail();
        return false;
    }

due to realpath usage, which returns false for coma separated paths:

    $openBasedir = realpath($openBasedir);

The idea is to split $openBasedir by PATH_SEPARATOR into an array of $openBasedirPaths and to check each one of them against included rules.

The question is, how should I treat it. If one of paths === false, then should entire test fails? Or maybe all of them should be equal false?

What do you think about it? I can prepare tommorow appropriate patch.

Add check for display_startup_errors

display_startup_errors should always be "Off" unless debugging or on context=dev

[Feature Request] Phar package as a stand-alone command line tool

A phar package would be nice, so you could use it easier outside of a project as a stand-alone command line tool.

Add composer.lock into repository

composer.lock file helps developers by "locking" external dependencies to certain version so that each developer will use the exact same versions.

expose_php check doesn't work right

Hi,

I just installed the latest verison of iniscan (ab4b5a7) and I noticed an issue scanning my INI file.

Here's the command I ran:

./vendor/bin/iniscan scan --path /etc/php5/fpm/php.ini

And this line in the output is the issue:

FAIL | WARNING | expose_php | Showing the PHP signature exposes additional information

I went to fix that, but saw that I already had expose_php turned off:

vagrant@precise64:~/tmp$ cat /etc/php5/fpm/php.ini |grep -i expose_php
;expose_php = On
expose_php = Off

I'm not clear if the leading semi-colon on the first line isn't being filtered out, or if something else is at play, but I wanted to let you know.

Thanks for your time,

-- Doug