cvs: phpdoc /nl/chapters install.xml security.xml

derick Wed Oct 11 09:55:45 2000 EDT Modified files: /phpdoc/nl/chapters install.xml security.xml Log: - Update from English tree Index: phpdoc/nl/chapters/install.xml diff -u phpdoc/nl/chapters/install.xml:1.1 phpdoc/nl/chapters/install.xml:1.2 --- phpdoc/nl/chapters/install.xml:1.1 Tue Oct 10 15:07:53 2000 +++ phpdoc/nl/chapters/install.xml Wed Oct 11 09:55:45 2000 @@ -2869,6 +2869,11 @@ Exit Regedit. </simpara> </listitem> + <listitem> + <simpara> + If using PWS on Windows, reboot to reload the registry. + </simpara> + </listitem> </itemizedlist> </para> <simpara> Index: phpdoc/nl/chapters/security.xml diff -u phpdoc/nl/chapters/security.xml:1.1 phpdoc/nl/chapters/security.xml:1.2 --- phpdoc/nl/chapters/security.xml:1.1 Tue Oct 10 15:07:53 2000 +++ phpdoc/nl/chapters/security.xml Wed Oct 11 09:55:45 2000 @@ -9,8 +9,9 @@ properties make anything run on a web server insecure by default. PHP is designed specifically to be a more secure language for writing CGI programs than Perl or C, and with correct selection of - compile-time and runtime configuration options it gives you - exactly the combination of freedom and security you need. + compile-time and runtime configuration options, and proper coding + practices, it can give you exactly the combination of freedom and + security you need. </simpara> <simpara> As there are many different ways of utilizing PHP, there are many @@ -18,12 +19,25 @@ selection of options guarantees you can use PHP for a lot of purposes, but it also means there are combinations of these options and server configurations that result in an insecure - setup. This chapter explains the different configuration option - combinations and the situations they can be safely used. + setup. </simpara> + <simpara> + The configuration flexibility of PHP is equally rivalled by the + code flexibility. PHP can be used to build complete server + applications, with all the power of a shell user, or it can be used + for simple server-side includes with little risk in a tightly + controlled environment. How you build that environment, and how + secure it is, is largely up to the PHP developer. + </simpara> + <simpara> + This chapter starts by explaining the different configuration + option combinations and the situations they can be safely used. It + then describes different considerations in coding for different + levels of security, and ends with some general security advice. + </simpara> <sect1 id="security.cgi"> - <title>CGI binary</title> + <title>Installed as CGI binary</title> <sect2> <title>Possible attacks</title> @@ -241,7 +255,7 @@ </sect1> <sect1 id="security.apache"> - <title>Apache module</title> + <title>Installed as an Apache module</title> <simpara> When PHP is used as an Apache module it inherits Apache's user permissions (typically those of the "nobody" user). This has several @@ -302,7 +316,7 @@ </simpara> <para> <example> - <title>Filesystem attack</title> + <title>Poor variable checking leads to....</title> <programlisting role="php"> &lt;?php // remove a file from the user's home directory @@ -317,6 +331,58 @@ Since the username is postable from a user form, they can submit a username and file belonging to someone else, and delete files. In this case, you'd want to use some other form of authentication. + Consider what could happen if the variables submitted were + "../etc/" and "passwd". The code would then effectively read: + <example> + <title>... A filesystem attack</title> + <programlisting role="php"> +&lt;?php +// removes a file from anywhere on the hard drive that +// the PHP user has access to. If PHP has root access: +$username = "../etc/"; +$homedir = "/home/../etc/"; +$file_to_delete = "passwd"; +unlink ("/home/../etc/passwd"); +echo "/home/../etc/passwd" has been deleted!"; +?> + </programlisting> + </example> + There are two appropriate measures to prevent these issues. + <itemizedlist> + <listitem> + <simpara> + Only allow limited permissions to the PHP web user binary. + </simpara> + </listitem> + <listitem> + <simpara> + Check all file-related variables which are submitted. + </simpara> + </listitem> + </itemizedlist> + Here is an improved script: + <example> + <title>More secure file name checking</title> + <programlisting role="php"> +&lt;?php +// removes a file from the hard drive that +// the PHP user has access to. +$username = $HTTP_REMOTE_USER; // use an authentication mechanisim + +$homedir = "/home/$username"; + +$file_to_delete = basename("$userfile"); // strip paths +unlink ($homedir/$file_to_delete); + +$fp = fopen("/home/logging/filedelete.log","+a"); //log the deletion +$logstring = "$HTTP_REMOTE_USER $homedir $file_to_delete"; +fputs ($fp, $logstring); +fclose($fp); + +echo "$file_to_delete has been deleted!"; +?> + </programlisting> + </example> </para> </sect1> @@ -385,7 +451,7 @@ unlink ($evil_var); // Write logging of their access... or maybe not? -fputs ($evil_var); +fputs ($fp, $evil_var); // Execute something trivial.. or rm -rf *? system ($evil_var); @@ -427,10 +493,55 @@ </itemizedlist> By adequately asking these questions while writing the script, rather than later, you prevent an unfortunate re-write when you - need to oncrease your security. + need to increase your security. By starting out with this mindset, + you won't guarantee the security of your system, but you can help + improve it. </para> + </sect1> + + <sect1 id="security.general"> + <title>General considerations</title> + <simpara> + A completely secure system is a virtual impossibility, so an + approach often used in the security profession is one of balancing + risk and usability. If every variable submitted by a user required + two forms of biometric validation (such as a retinal scan and a + 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. + </simpara> + <simpara> + A phrase worth remembering: A system is only as good as the weakest + link in a chain. If all transactions are heavily logged based on + time, location, transaction type, etc. but the user is only + verified based on a single cookie, the validity of tying the users + to the transaction log is severely weakened. + </simpara> + <simpara> + When testing, keep in mind that you will not be able to test all + possibilities for even the simplest of pages. The input you + may expect will be completely unrelated to the input given by + a disgruntled employee, a cracker with months of time on their + hands, or a housecat walking across the keyboard. This is why it's + best to look at the code from a logical perspective, to discern + where unexpected data can be introduced, and then follow how it is + modified, reduced, or amplified. + </simpara> + <simpara> + The Internet is filled with people trying to make a name for + themselves by breaking your code, crashing your site, posting + inappropriate content, and otherwise making your day interesting. + It doesn't matter if you have a small or large site, you are + a target by simply being online, by having a server that can be + connected to. Many cracking programs do not discern by size, they + simply trawl massive IP blocks looking for victims. Try not to + become one. + </simpara> </sect1> - </chapter> <!-- Keep this comment at the end of the file