rspec/rules/S3333/php/rule.adoc
2023-10-25 17:24:03 +02:00

112 lines
3.5 KiB
Plaintext

When accessing files on the local filesystem, PHP can enforce security checks to
defend against some attacks. The `open_basedir` setting in the main PHP
configuration defines a set of directories that the application is allowed to
access. Access to locations outside of these directories will be blocked.
== Why is this an issue?
The PHP runtime will allow the application to access all files underneath the
configured set of directories. If no value is set, the application may access
any file on the filesystem.
=== What is the potential impact?
`open_basedir` is commonly used to ensure that a PHP application can only access
files needed for the application function. While deactivating this setting does
not pose a direct threat to the application's security, it can make exploitation
of other vulnerabilities easier and more severe.
If an attacker can exploit a path traversal vulnerability, they will be able to
access any file made available to the application's user account. This may
include system-critical or otherwise sensitive files.
In shared hosting environments, a vulnerability can affect all co-hosted
applications and not only the vulnerable one. `open_basedir` can help limit the
scope of the compromise in that case.
== How to fix it
The main PHP configuration should define the `open_basedir` setting.
This setting should not include overly large directories, such as the root
directory of the filesystem.
Adding the current directory, denoted by "`.`", to the `open_basedir`
configuration is also dangerous. It is possible to change the current directory
within PHP scripts by calling `chdir()`, effectively removing any protection.
=== Code examples
==== Noncompliant code example
[source,php,diff-id=1,diff-type=noncompliant]
----
; php.ini
open_basedir="/:${USER}/scripts/data" ; Noncompliant; root directory in the list
----
[source,php,diff-id=2,diff-type=noncompliant]
----
; php.ini
; open_basedir= ; Noncompliant; setting commented out
----
==== Compliant solution
[source,php,diff-id=1,diff-type=compliant]
----
; php.ini
open_basedir="${USER}/scripts/data"
----
[source,php,diff-id=2,diff-type=compliant]
----
; php.ini try 1
open_basedir="/var/www/myapp/data"
----
== Resources
=== Standards
* OWASP - https://owasp.org/Top10/A05_2021-Security_Misconfiguration/[Top 10 2021 Category A5 - Security Misconfiguration]
* OWASP - https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration[Top 10 2017 Category A6 - Security Misconfiguration]
* CWE - https://cwe.mitre.org/data/definitions/23[CWE-23 - Relative Path Traversal]
* CWE - https://cwe.mitre.org/data/definitions/36[CWE-36 - Absolute Path Traversal]
ifdef::env-github,rspecator-view[]
'''
== Implementation Specification
(visible only on this page)
=== Message
* Set "open_basedir".
* Limit "open_basedir" to a narrower path than "xxx".
'''
== Comments And Links
(visible only on this page)
=== on 1 Sep 2015, 07:55:30 Linda Martin wrote:
@Ann actually I just realised that comment in the php.ini file are defined as the following: "any text on a line after an unquoted semicolon (; ) is ignored" from documentation: see \http://php.net/manual/en/configuration.file.php.
So shall we update the code snippet or not (for readability)?
Otherwise LGTM!
=== on 1 Sep 2015, 13:08:23 Ann Campbell wrote:
Absolutely [~linda.martin]! Please always correct my syntax. :-]
I've made an update just now. Double-check it?
=== on 12 Nov 2015, 17:45:03 Linda Martin wrote:
\[~ann.campbell.2] Thanks, I update the remaining comments.
endif::env-github,rspecator-view[]