The following configuration options are security related and can be set in the php.ini file. Using these settings ensures that the PHP configuration you have running is securely set by default.
This setting will restrict any file access to a specified directory. Any file operations are then limited to what is specified here. A good recommendation is that any file operations being performed should be located within a certain set of directories. This way, the standard old “../../../../etc/passwd” won’t go anywhere.
This allows a set of functions to be disabled in PHP. Disabling functions is considered a great way to practice defense in depth. If the applications don’t make use of securityrisky functions such as eval(), passthru(), system(), etc., then add these as functions that should never be allowed. If an attacker does find a security issue in the code, it will cause you some headaches.
Setting this configuration to off will remove the PHP banner that displays in the server headers on an HTTP response. If your concern is to hide the version of PHP or the fact that it is running on the application, setting this will help.
This setting is a simple but important configuration that enables detailed error information to be displayed to the user on an exception. This setting should always be turned off in any production environment.
Turning safe_mode on in PHP allows very strict file access permissions. It does this by checking the permissions of the owner of the PHP script that is running and any file access that the script attempts. If the permissions do not match, then PHP throws a security exception. Safe_mode is mostly used by ISPs, so that in virtual-hosted environments, multiple users can develop their own PHP scripts without risking the integrity of the server.
This configuration option will disable the ability to do file operations on remote files. This is a nice overall setting to prevent remote file inclusion vulnerabilities from working. An example of this would be if the $absolute_path variable in the following code sample was set to a value of http://www.site.com/; the exploit would fail because allow_url_ fopen was set.
Latest posts by Unallocated Author (see all)
- An Interview With the Creator of BugBountyNotes - October 20, 2018
- SickOS 1.2 – Vulnhub CTF Challenge Walkthrough - October 9, 2018
- Tips How To Recover Deleted Files on Windows PC Free and Easily - October 8, 2018