From 4e640f8c4492eeae0d00d52a7f68c46826f83d2f Mon Sep 17 00:00:00 2001 From: Ron Chmara Date: Thu, 2 Nov 2000 06:11:37 +0000 Subject: [PATCH] More content/examples. git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@35031 c90b9560-bf6c-de11-be94-00142212c4b1 --- chapters/security.xml | 66 +++++++++++++++++++++++++++++++++---------- security/index.xml | 66 +++++++++++++++++++++++++++++++++---------- 2 files changed, 102 insertions(+), 30 deletions(-) diff --git a/chapters/security.xml b/chapters/security.xml index bd544e3c73..0002453fdc 100644 --- a/chapters/security.xml +++ b/chapters/security.xml @@ -293,19 +293,20 @@ AddHandler php3-script .php3 Filesystem Security - PHP honors the security built into most server systems with respect - to permissions on a file and directory basis. This allows you to - control which files in the filesystem may be read. Care should be - taken with any files which are world readable to ensure that they - are safe for reading by all users who have access to that + PHP is subject to the security built into most server systems with + respect to permissions on a file and directory basis. This allows + you to control which files in the filesystem may be read. Care + should be taken with any files which are world readable to ensure + that they are safe for reading by all users who have access to that filesystem. Since PHP was designed to allow user level access to the filesystem, it's entirely possible to write a PHP script that will allow you - to read system files such as /etc/password. This has some obvious - implications, in that you need to ensure that the files that you - read and write are the appropriate ones. + to read system files such as /etc/password, modify your ethernet + connections, send massive printer jobs out, etc. This has some + obvious implications, in that you need to ensure that the files + that you read from and write to are the appropriate ones. Consider the following script, where a user indicates that they'd @@ -347,7 +348,8 @@ echo "/home/../etc/passwd has been deleted!"; ?> - There are two appropriate measures to prevent these issues. + There are two important measures you should take to prevent these + issues. @@ -356,7 +358,7 @@ echo "/home/../etc/passwd has been deleted!"; - Check all file-related variables which are submitted. + Check all variables which are submitted. @@ -382,7 +384,28 @@ fclose($fp); echo "$file_to_delete has been deleted!"; ?> - + + Alternately, you may prefer to write a more customized check: + + More secure file name checking + +<?php +$username = $HTTP_REMOTE_USER; +$homedir = "/home/$username"; + +if (!ereg('^[^./][^/]*$', $userfile)) + die('bad filename'); //die, do not process + +//etc... +?> + + + Dpending on your operating system, there are a wide variety of files + which you should be concerned about, including device entries (/dev/ + or COM1), configuration files (/etc/ files and the .ini files), + well known file storage areas (/home/, My Documents), etc. For this + reason, it's usually easier to create a policy where you forbid + everything except for what you explicitly allow. @@ -497,6 +520,15 @@ exec ($evil_var); you won't guarantee the security of your system, but you can help improve it. + + You may also want to consider turning off register_globals, + magic_quotes, or other convenience settings which may confuse + you as to the validity, source, or value of a given variable. + Working with PHP in error_reporting(E_ALL) mode can also help warn + you about variables being used before they are checked or + initialized (so you can prevent unusual data from being + operated upon). + @@ -509,10 +541,14 @@ exec ($evil_var); fingerprint), you would have an extremely high level of accountability. It would also take half an hour to fill out a fairly complex form, which would tend to encourage users to find ways of - bypassing the security. The best security is often inobtrusive - enough to suit the requirements without the user being prevented - from accomplishing their work. Indeed, some security attacks are - merely exploits of this kind of overly built security. + bypassing the security. + + + The best security is often inobtrusive enough to suit the + requirements without the user being prevented from accomplishing + their work, or over-burdening the code author with excessive + complexity. Indeed, some security attacks are merely exploits of + this kind of overly built security, which tends to erode over time. A phrase worth remembering: A system is only as good as the weakest diff --git a/security/index.xml b/security/index.xml index bd544e3c73..0002453fdc 100644 --- a/security/index.xml +++ b/security/index.xml @@ -293,19 +293,20 @@ AddHandler php3-script .php3 Filesystem Security - PHP honors the security built into most server systems with respect - to permissions on a file and directory basis. This allows you to - control which files in the filesystem may be read. Care should be - taken with any files which are world readable to ensure that they - are safe for reading by all users who have access to that + PHP is subject to the security built into most server systems with + respect to permissions on a file and directory basis. This allows + you to control which files in the filesystem may be read. Care + should be taken with any files which are world readable to ensure + that they are safe for reading by all users who have access to that filesystem. Since PHP was designed to allow user level access to the filesystem, it's entirely possible to write a PHP script that will allow you - to read system files such as /etc/password. This has some obvious - implications, in that you need to ensure that the files that you - read and write are the appropriate ones. + to read system files such as /etc/password, modify your ethernet + connections, send massive printer jobs out, etc. This has some + obvious implications, in that you need to ensure that the files + that you read from and write to are the appropriate ones. Consider the following script, where a user indicates that they'd @@ -347,7 +348,8 @@ echo "/home/../etc/passwd has been deleted!"; ?> - There are two appropriate measures to prevent these issues. + There are two important measures you should take to prevent these + issues. @@ -356,7 +358,7 @@ echo "/home/../etc/passwd has been deleted!"; - Check all file-related variables which are submitted. + Check all variables which are submitted. @@ -382,7 +384,28 @@ fclose($fp); echo "$file_to_delete has been deleted!"; ?> - + + Alternately, you may prefer to write a more customized check: + + More secure file name checking + +<?php +$username = $HTTP_REMOTE_USER; +$homedir = "/home/$username"; + +if (!ereg('^[^./][^/]*$', $userfile)) + die('bad filename'); //die, do not process + +//etc... +?> + + + Dpending on your operating system, there are a wide variety of files + which you should be concerned about, including device entries (/dev/ + or COM1), configuration files (/etc/ files and the .ini files), + well known file storage areas (/home/, My Documents), etc. For this + reason, it's usually easier to create a policy where you forbid + everything except for what you explicitly allow. @@ -497,6 +520,15 @@ exec ($evil_var); you won't guarantee the security of your system, but you can help improve it. + + You may also want to consider turning off register_globals, + magic_quotes, or other convenience settings which may confuse + you as to the validity, source, or value of a given variable. + Working with PHP in error_reporting(E_ALL) mode can also help warn + you about variables being used before they are checked or + initialized (so you can prevent unusual data from being + operated upon). + @@ -509,10 +541,14 @@ exec ($evil_var); fingerprint), you would have an extremely high level of accountability. It would also take half an hour to fill out a fairly complex form, which would tend to encourage users to find ways of - bypassing the security. The best security is often inobtrusive - enough to suit the requirements without the user being prevented - from accomplishing their work. Indeed, some security attacks are - merely exploits of this kind of overly built security. + bypassing the security. + + + The best security is often inobtrusive enough to suit the + requirements without the user being prevented from accomplishing + their work, or over-burdening the code author with excessive + complexity. Indeed, some security attacks are merely exploits of + this kind of overly built security, which tends to erode over time. A phrase worth remembering: A system is only as good as the weakest