sigmasternchen/php-doc-en
1
0
Fork 0
mirror of https://github.com/sigmasternchen/php-doc-en synced 2025-03-16 00:48:54 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

putting general security info first, rather than more obscure cgi stuff.

Browse source 
git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@61229 c90b9560-bf6c-de11-be94-00142212c4b1
This commit is contained in:
jim winstead 2001-10-31 01:39:47 +00:00
parent c019e46c79
commit 17807555a1
2 changed files with 98 additions and 98 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

98
chapters/security.xml
View file

@ -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 @@ AddType application/x-httpd-php .htm .html
</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>

98
security/index.xml
View file

@ -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 @@ AddType application/x-httpd-php .htm .html
</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>