cvs: phpdoc /en/chapters security.xml

jimw Tue Oct 30 20:39:47 2001 EDT Modified files: /phpdoc/en/chapters security.xml Log: putting general security info first, rather than more obscure cgi stuff. Index: phpdoc/en/chapters/security.xml diff -u phpdoc/en/chapters/security.xml:1.29 phpdoc/en/chapters/security.xml:1.30 --- phpdoc/en/chapters/security.xml:1.29 Sat Oct 13 11:52:38 2001 +++ phpdoc/en/chapters/security.xml Tue Oct 30 20:39:47 2001 @@ -1,5 +1,5 @@ <?xml encoding="iso-8859-1"?> -<!-- $Revision: 1.29 $ --> +<!-- $Revision: 1.30 $ --> <chapter id="security"> <title>Security</title> @@ -38,6 +38,54 @@ levels of security, and ends with some general security advice. </simpara> + <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. + </simpara> + <simpara> + 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. + </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> + <sect1 id="security.cgi"> <title>Installed as CGI binary</title> @@ -729,54 +777,6 @@ </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. - </simpara> - <simpara> - 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. - </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> - <sect1 id="security.current"> <title>Keeping Current</title> <simpara>