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

Added section on error handling, cleaned up some other text/typos.

Browse source 
git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@33371 c90b9560-bf6c-de11-be94-00142212c4b1
This commit is contained in:
Ron Chmara 2000-10-04 04:22:00 +00:00
parent 05b9554495
commit 379f68c6fc
2 changed files with 126 additions and 32 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

79
chapters/security.xml
View file

@ -260,10 +260,13 @@ AddHandler php3-script .php3
Often, once security is established to the point where the PHP user
(in this case, the apache user) has very little risk, it is
discovered that PHP now has been prevented from writing virus files
to user directories, or accessing or changing a non-public database
but it has equally been secured from writing files that it should,
or entering database transactions. A frequent security mistake made
at this point is to allow apache root permissions.
to user directories. Or perhaps it has been prevented from accessing
or changing a non-public database. It has equally been secured from
writing files that it should, or entering database transactions.
</simpara>
<simpara>
A frequent security mistake made at this point is to allow apache
root permissions.
</simpara>
<simpara>
Escalating the Apache user's permissions to root is extremely
@ -291,15 +294,11 @@ AddHandler php3-script .php3
read and write are the appropriate ones.
</simpara>
<simpara>
Since PHP was designed to allow user level access to the filesystem,
it's entirely possible to write a PHP script that will allow you
to read system files such as /etc/password. This has some obvious
implications, in that you need to ensure that the files that you
read and write are the appropriate ones. Consider the following
script, where a user indicates that they'd like to delete a file
in their home directory. This assumes a situation where the web
interface is regularly used for file management, so the Apache user
is allowed to delete files in the user home directories.
Consider the following script, where a user indicates that they'd
like to delete a file in their home directory. This assumes a
situation where a PHP web interface is regularly used for file
management, so the Apache user is allowed to delete files in
the user home directories.
</simpara>
<para>
<example>
@ -320,6 +319,54 @@ echo "$file_to_delete has been deleted!";
In this case, you'd want to use some other form of authentication.
</para>
</sect1>
<sect1 id="security.errors">
<title>Error Reporting</title>
<simpara>
A standard attack tactic involves profiling a system by feeding
it improper data, and checking for the kinds, and contexts, of the
errors which are returned. This allows the system cracker to probe
for information about the server, to determine possible weaknesses.
</simpara>
<simpara>
The PHP errors which are normally returned can be quite helpful to a
developer who is trying to debug a script, indicating such things
as the function or file that failed, the PHP file it failed in,
and the line number which the failure occured in. This is all
information that can be exploited.
</simpara>
<simpara>
For example, the very style of error indicates a system is running
PHP. If the attacker was looking at an .html page, and wanted to
probe for the back-end (to look for known weaknesses in the system),
by feeding it the wrong data they may be able to determine that a
system was built with PHP.
</simpara>
<simpara>
A function error can indicate whether a system may be running a
specific database engine, or give clues as to how a web page or
programmed or designed. This allows for deeper investigation into
open database ports, or to look for specific bugs or weaknesses
in a web page. By feeding different pieces of bad data, for example,
an attacker can determine the order of authentication in a script,
(from the line number errors) as well as probe for exploits that
may be exploited in different locations in the script.
</simpara>
<simpara>
A filesystem or general PHP error can indicate what permissions
the webserver has, as well as the structure and organization of
files on the web server.
</simpara>
<simpara>
There are three major solutions to this issue. The first is to
scrutinize all functions, and attempt to compensate for the bulk
of the errors. The second is to disable error reporting entirely
on the running code. The third is to use PHP's custom error
handling functions to create your own error handler. Depending
on your security policy, you may find all three to be applicable
to your situation.
</simpara>
</sect1>
<sect1 id="security.variables">
<title>User Submitted Data</title>
@ -347,9 +394,9 @@ exec ($evil_var);
?>
</programlisting>
</example>
You should always carefully examin your code to make sure that any
variables being submitted from a web browser and ask the following
questions:
You should always carefully examine your code to make sure that any
variables being submitted from a web browser are being properly
checked, and ask yourself the following questions:
<itemizedlist>
<listitem>
<simpara>

79
security/index.xml
View file

@ -260,10 +260,13 @@ AddHandler php3-script .php3
Often, once security is established to the point where the PHP user
(in this case, the apache user) has very little risk, it is
discovered that PHP now has been prevented from writing virus files
to user directories, or accessing or changing a non-public database
but it has equally been secured from writing files that it should,
or entering database transactions. A frequent security mistake made
at this point is to allow apache root permissions.
to user directories. Or perhaps it has been prevented from accessing
or changing a non-public database. It has equally been secured from
writing files that it should, or entering database transactions.
</simpara>
<simpara>
A frequent security mistake made at this point is to allow apache
root permissions.
</simpara>
<simpara>
Escalating the Apache user's permissions to root is extremely
@ -291,15 +294,11 @@ AddHandler php3-script .php3
read and write are the appropriate ones.
</simpara>
<simpara>
Since PHP was designed to allow user level access to the filesystem,
it's entirely possible to write a PHP script that will allow you
to read system files such as /etc/password. This has some obvious
implications, in that you need to ensure that the files that you
read and write are the appropriate ones. Consider the following
script, where a user indicates that they'd like to delete a file
in their home directory. This assumes a situation where the web
interface is regularly used for file management, so the Apache user
is allowed to delete files in the user home directories.
Consider the following script, where a user indicates that they'd
like to delete a file in their home directory. This assumes a
situation where a PHP web interface is regularly used for file
management, so the Apache user is allowed to delete files in
the user home directories.
</simpara>
<para>
<example>
@ -320,6 +319,54 @@ echo "$file_to_delete has been deleted!";
In this case, you'd want to use some other form of authentication.
</para>
</sect1>
<sect1 id="security.errors">
<title>Error Reporting</title>
<simpara>
A standard attack tactic involves profiling a system by feeding
it improper data, and checking for the kinds, and contexts, of the
errors which are returned. This allows the system cracker to probe
for information about the server, to determine possible weaknesses.
</simpara>
<simpara>
The PHP errors which are normally returned can be quite helpful to a
developer who is trying to debug a script, indicating such things
as the function or file that failed, the PHP file it failed in,
and the line number which the failure occured in. This is all
information that can be exploited.
</simpara>
<simpara>
For example, the very style of error indicates a system is running
PHP. If the attacker was looking at an .html page, and wanted to
probe for the back-end (to look for known weaknesses in the system),
by feeding it the wrong data they may be able to determine that a
system was built with PHP.
</simpara>
<simpara>
A function error can indicate whether a system may be running a
specific database engine, or give clues as to how a web page or
programmed or designed. This allows for deeper investigation into
open database ports, or to look for specific bugs or weaknesses
in a web page. By feeding different pieces of bad data, for example,
an attacker can determine the order of authentication in a script,
(from the line number errors) as well as probe for exploits that
may be exploited in different locations in the script.
</simpara>
<simpara>
A filesystem or general PHP error can indicate what permissions
the webserver has, as well as the structure and organization of
files on the web server.
</simpara>
<simpara>
There are three major solutions to this issue. The first is to
scrutinize all functions, and attempt to compensate for the bulk
of the errors. The second is to disable error reporting entirely
on the running code. The third is to use PHP's custom error
handling functions to create your own error handler. Depending
on your security policy, you may find all three to be applicable
to your situation.
</simpara>
</sect1>
<sect1 id="security.variables">
<title>User Submitted Data</title>
@ -347,9 +394,9 @@ exec ($evil_var);
?>
</programlisting>
</example>
You should always carefully examin your code to make sure that any
variables being submitted from a web browser and ask the following
questions:
You should always carefully examine your code to make sure that any
variables being submitted from a web browser are being properly
checked, and ask yourself the following questions:
<itemizedlist>
<listitem>
<simpara>