From 17807555a1c6f9a2847509f924c7350b2ca35089 Mon Sep 17 00:00:00 2001 From: jim winstead Date: Wed, 31 Oct 2001 01:39:47 +0000 Subject: [PATCH] putting general security info first, rather than more obscure cgi stuff. git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@61229 c90b9560-bf6c-de11-be94-00142212c4b1 --- chapters/security.xml | 98 +++++++++++++++++++++---------------------- security/index.xml | 98 +++++++++++++++++++++---------------------- 2 files changed, 98 insertions(+), 98 deletions(-) diff --git a/chapters/security.xml b/chapters/security.xml index 158a5ff208..348500aad1 100644 --- a/chapters/security.xml +++ b/chapters/security.xml @@ -1,5 +1,5 @@ - + Security @@ -38,6 +38,54 @@ levels of security, and ends with some general security advice. + + General considerations + + 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, 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 + 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. + + + 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. + + + 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. + + + Installed as CGI binary @@ -729,54 +777,6 @@ AddType application/x-httpd-php .htm .html - - General considerations - - 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, 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 - 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. - - - 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. - - - 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. - - - Keeping Current diff --git a/security/index.xml b/security/index.xml index 158a5ff208..348500aad1 100644 --- a/security/index.xml +++ b/security/index.xml @@ -1,5 +1,5 @@ - + Security @@ -38,6 +38,54 @@ levels of security, and ends with some general security advice. + + General considerations + + 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, 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 + 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. + + + 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. + + + 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. + + + Installed as CGI binary @@ -729,54 +777,6 @@ AddType application/x-httpd-php .htm .html - - General considerations - - 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, 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 - 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. - - - 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. - - - 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. - - - Keeping Current