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>
