mirror of
https://github.com/sigmasternchen/php-doc-en
synced 2025-03-15 08:28:54 +00:00
Add some acronym's tag
#Accept some patchs from PhDOE git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@297645 c90b9560-bf6c-de11-be94-00142212c4b1
This commit is contained in:
parent
c84d13055e
commit
ab6785b01c
8 changed files with 41 additions and 41 deletions
|
@ -89,7 +89,7 @@ The field 'age' has a data length of 4
|
|||
<note>
|
||||
<title>Note to Windows Users</title>
|
||||
<para>
|
||||
Due to a limitation in the underlying API used by PHP (MS DBLib C API),
|
||||
Due to a limitation in the underlying <acronym>API</acronym> used by <acronym>PHP</acronym> (MS DBLib C <acronym>PHP</acronym>),
|
||||
the length of <literal>VARCHAR</literal> fields is limited to
|
||||
<emphasis>255</emphasis>. If you need to store more data, use a
|
||||
<literal>TEXT</literal> field instead.
|
||||
|
|
|
@ -4,10 +4,10 @@
|
|||
<chapter xml:id="security.apache" xmlns="http://docbook.org/ns/docbook">
|
||||
<title>Installed as an Apache module</title>
|
||||
<simpara>
|
||||
When PHP is used as an Apache module it inherits Apache's user
|
||||
When <acronym>PHP</acronym> is used as an Apache module it inherits Apache's user
|
||||
permissions (typically those of the "nobody" user). This has several
|
||||
impacts on security and authorization. For example, if you are using
|
||||
PHP to access a database, unless that database has built-in access
|
||||
<acronym>PHP</acronym> to access a database, unless that database has built-in access
|
||||
control, you will have to make the database accessible to the
|
||||
"nobody" user. This means a malicious script could access and modify
|
||||
the database, even without a username and password. It's entirely
|
||||
|
@ -15,12 +15,12 @@
|
|||
administrator's web page, and drop all of your databases. You can
|
||||
protect against this with Apache authorization, or you can design
|
||||
your own access model using LDAP, &htaccess; files, etc. and include
|
||||
that code as part of your PHP scripts.
|
||||
that code as part of your <acronym>PHP</acronym> scripts.
|
||||
</simpara>
|
||||
<simpara>
|
||||
Often, once security is established to the point where the PHP user
|
||||
Often, once security is established to the point where the <acronym>PHP</acronym> user
|
||||
(in this case, the apache user) has very little risk attached to it,
|
||||
it is discovered that PHP is now prevented from writing any files
|
||||
it is discovered that <acronym>PHP</acronym> is now prevented from writing any files
|
||||
to user directories. Or perhaps it has been prevented from accessing
|
||||
or changing databases. It has equally been secured from writing
|
||||
good and bad files, or entering good and bad database transactions.
|
||||
|
@ -39,7 +39,7 @@
|
|||
<simpara>
|
||||
There are some simpler solutions. By using
|
||||
<link linkend="ini.open-basedir">open_basedir</link> you can control and restrict what
|
||||
directories are allowed to be used for PHP. You can also set up
|
||||
directories are allowed to be used for <acronym>PHP</acronym>. You can also set up
|
||||
apache-only areas, to restrict all web based activity to non-user,
|
||||
or non-system, files.
|
||||
</simpara>
|
||||
|
|
|
@ -18,9 +18,9 @@
|
|||
linkend="security.database.sql-injection">tamper with an SQL query</link>.
|
||||
</simpara>
|
||||
<simpara>
|
||||
As you can surmise, PHP cannot protect your database by itself. The
|
||||
As you can surmise, <acronym>PHP</acronym> cannot protect your database by itself. The
|
||||
following sections aim to be an introduction into the very basics of how to
|
||||
access and manipulate databases within PHP scripts.
|
||||
access and manipulate databases within <acronym>PHP</acronym> scripts.
|
||||
</simpara>
|
||||
<simpara>
|
||||
Keep in mind this simple rule: defense in depth. The more places you
|
||||
|
@ -78,7 +78,7 @@
|
|||
<!--simpara>
|
||||
If your database server has native SSL support, consider using <link
|
||||
linkend="ref.openssl">OpenSSL functions</link> in communication between
|
||||
PHP and database via SSL.
|
||||
<acronym>PHP</acronym> and database via SSL.
|
||||
</simpara-->
|
||||
</sect1>
|
||||
|
||||
|
@ -98,7 +98,7 @@
|
|||
</simpara>
|
||||
<simpara>
|
||||
The easiest way to work around this problem is to first create your own
|
||||
encryption package, and then use it from within your PHP scripts. PHP
|
||||
encryption package, and then use it from within your <acronym>PHP</acronym> scripts. <acronym>PHP</acronym>
|
||||
can assist you in this with several extensions, such as <link
|
||||
linkend="ref.mcrypt">Mcrypt</link> and <link
|
||||
linkend="ref.mhash">Mhash</link>, covering a wide variety of encryption
|
||||
|
@ -180,10 +180,10 @@ $result = pg_query($conn, $query);
|
|||
</programlisting>
|
||||
</example>
|
||||
Normal users click on the 'next', 'prev' links where the <varname>$offset</varname>
|
||||
is encoded into the URL. The script expects that the incoming
|
||||
is encoded into the <acronym>URL</acronym>. The script expects that the incoming
|
||||
<varname>$offset</varname> is a decimal number. However, what if someone tries to
|
||||
break in by appending a <function>urlencode</function>'d form of the
|
||||
following to the URL
|
||||
following to the <acronym>URL</acronym>
|
||||
<informalexample>
|
||||
<programlisting role="sql">
|
||||
<![CDATA[
|
||||
|
@ -366,7 +366,7 @@ $result = mssql_query($query);
|
|||
</listitem>
|
||||
<listitem>
|
||||
<simpara>
|
||||
Check if the given input has the expected data type. PHP has
|
||||
Check if the given input has the expected data type. <acronym>PHP</acronym> has
|
||||
a wide range of input validating functions, from the simplest ones
|
||||
found in <link linkend="ref.var">Variable Functions</link> and
|
||||
in <link linkend="ref.ctype">Character Type Functions</link>
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
<chapter xml:id="security.filesystem" xmlns="http://docbook.org/ns/docbook">
|
||||
<title>Filesystem Security</title>
|
||||
<simpara>
|
||||
PHP is subject to the security built into most server systems with
|
||||
<acronym>PHP</acronym> is subject to the security built into most server systems with
|
||||
respect to permissions on a file and directory basis. This allows
|
||||
you to control which files in the filesystem may be read. Care
|
||||
should be taken with any files which are world readable to ensure
|
||||
|
@ -12,8 +12,8 @@
|
|||
filesystem.
|
||||
</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
|
||||
Since <acronym>PHP</acronym> was designed to allow user level access to the filesystem,
|
||||
it's entirely possible to write a <acronym>PHP</acronym> script that will allow you
|
||||
to read system files such as /etc/passwd, modify your ethernet
|
||||
connections, send massive printer jobs out, etc. This has some
|
||||
obvious implications, in that you need to ensure that the files
|
||||
|
@ -22,7 +22,7 @@
|
|||
<simpara>
|
||||
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
|
||||
situation where a <acronym>PHP</acronym> web interface is regularly used for file
|
||||
management, so the Apache user is allowed to delete files in
|
||||
the user home directories.
|
||||
</simpara>
|
||||
|
@ -73,7 +73,7 @@ echo "The file has been deleted!";
|
|||
<itemizedlist>
|
||||
<listitem>
|
||||
<simpara>
|
||||
Only allow limited permissions to the PHP web user binary.
|
||||
Only allow limited permissions to the <acronym>PHP</acronym> web user binary.
|
||||
</simpara>
|
||||
</listitem>
|
||||
<listitem>
|
||||
|
@ -147,7 +147,7 @@ if (!ctype_alnum($username) || !preg_match('/^(?:[a-z0-9_-]|\.(?!\.))+$/iD', $us
|
|||
<sect1 xml:id="security.filesystem.nullbytes">
|
||||
<title>Null bytes related issues</title>
|
||||
<simpara>
|
||||
As PHP uses the underlying C functions for filesystem related
|
||||
As <acronym>PHP</acronym> uses the underlying C functions for filesystem related
|
||||
operations, it may handle null bytes in a quite unexpected way.
|
||||
As null bytes denote the end of a string in C, strings containing them
|
||||
won't be considered entirely but rather only until a null byte occurs.
|
||||
|
|
|
@ -5,21 +5,21 @@
|
|||
<title>Using Register Globals</title>
|
||||
&warn.deprecated.feature-5-3-0.removed-6-0-0;
|
||||
<para>
|
||||
Perhaps the most controversial change in PHP is when the default value
|
||||
for the PHP directive <link linkend="ini.register-globals">
|
||||
register_globals</link> went from ON to OFF in PHP
|
||||
Perhaps the most controversial change in <acronym>PHP</acronym> is when the default value
|
||||
for the <acronym>PHP</acronym> directive <link linkend="ini.register-globals">
|
||||
register_globals</link> went from ON to OFF in <acronym>PHP</acronym>
|
||||
<link xlink:href="&url.php.release4.2.0;">4.2.0</link>. Reliance on this
|
||||
directive was quite common and many people didn't even know it existed
|
||||
and assumed it's just how PHP works. This page will explain how one can
|
||||
and assumed it's just how <acronym>PHP</acronym> works. This page will explain how one can
|
||||
write insecure code with this directive but keep in mind that the
|
||||
directive itself isn't insecure but rather it's the misuse of it.
|
||||
</para>
|
||||
<para>
|
||||
When on, register_globals will inject your scripts with all
|
||||
sorts of variables, like request variables from HTML forms. This
|
||||
coupled with the fact that PHP doesn't require variable initialization
|
||||
sorts of variables, like request variables from <acronym>HTML</acronym> forms. This
|
||||
coupled with the fact that <acronym>PHP</acronym> doesn't require variable initialization
|
||||
means writing insecure code is that much easier. It was a difficult
|
||||
decision, but the PHP community decided to disable this directive by
|
||||
decision, but the <acronym>PHP</acronym> community decided to disable this directive by
|
||||
default. When on, people use variables yet really don't know for sure
|
||||
where they come from and can only assume. Internal variables that are
|
||||
defined in the script itself get mixed up with request data sent by
|
||||
|
@ -62,7 +62,7 @@ if ($authorized) {
|
|||
When register_globals = on, we could also use
|
||||
<varname>$username</varname> in our example below but again you must
|
||||
realize that <varname>$username</varname> could also come from other
|
||||
means, such as GET (through the URL).
|
||||
means, such as GET (through the <acronym>URL</acronym>).
|
||||
</para>
|
||||
<para>
|
||||
<example>
|
||||
|
|
|
@ -8,14 +8,14 @@
|
|||
But in some cases, every little bit of extra security is desirable.
|
||||
</para>
|
||||
<para>
|
||||
A few simple techniques can help to hide PHP, possibly slowing
|
||||
A few simple techniques can help to hide <acronym>PHP</acronym>, possibly slowing
|
||||
down an attacker who is attempting to discover weaknesses in your
|
||||
system. By setting expose_php to <literal>off</literal> in your
|
||||
&php.ini; file, you reduce the amount of information available to them.
|
||||
</para>
|
||||
<para>
|
||||
Another tactic is to configure web servers such as apache to
|
||||
parse different filetypes through PHP, either with an &htaccess;
|
||||
parse different filetypes through <acronym>PHP</acronym>, either with an &htaccess;
|
||||
directive, or in the apache configuration file itself. You can
|
||||
then use misleading file extensions:
|
||||
<example>
|
||||
|
@ -37,10 +37,10 @@ AddType application/x-httpd-php .bop .foo .133t
|
|||
]]>
|
||||
</programlisting>
|
||||
</example>
|
||||
Or hide it as HTML code, which has a slight performance hit because
|
||||
all HTML will be parsed through the PHP engine:
|
||||
Or hide it as <acronym>HTML</acronym> code, which has a slight performance hit because
|
||||
all <acronym>HTML</acronym> will be parsed through the <acronym>PHP</acronym> engine:
|
||||
<example>
|
||||
<title>Using HTML types for PHP extensions</title>
|
||||
<title>Using <acronym>HTML</acronym> types for PHP extensions</title>
|
||||
<programlisting role="apache-conf">
|
||||
<![CDATA[
|
||||
# Make all PHP code look like HTML
|
||||
|
@ -48,7 +48,7 @@ AddType application/x-httpd-php .htm .html
|
|||
]]>
|
||||
</programlisting>
|
||||
</example>
|
||||
For this to work effectively, you must rename your PHP files with
|
||||
For this to work effectively, you must rename your <acronym>PHP</acronym> files with
|
||||
the above extensions. While it is a form of security through
|
||||
obscurity, it's a minor preventative measure with few drawbacks.
|
||||
</para>
|
||||
|
|
|
@ -5,7 +5,7 @@
|
|||
&warn.deprecated.feature-5-3-0.removed-6-0-0;
|
||||
<para>
|
||||
Magic Quotes is a process that automagically escapes incoming data to the
|
||||
PHP script. It's preferred to code with magic quotes off and to instead
|
||||
<acronym>PHP</acronym> script. It's preferred to code with magic quotes off and to instead
|
||||
escape the data at runtime, as needed.
|
||||
</para>
|
||||
|
||||
|
@ -26,8 +26,8 @@
|
|||
<link linkend="ini.magic-quotes-gpc">magic_quotes_gpc</link>
|
||||
</simpara>
|
||||
<simpara>
|
||||
Affects HTTP Request data (GET, POST, and COOKIE). Cannot be set at
|
||||
runtime, and defaults to <emphasis>on</emphasis> in PHP.
|
||||
Affects <acronym>HTTP</acronym> Request data (GET, POST, and COOKIE). Cannot be set at
|
||||
runtime, and defaults to <emphasis>on</emphasis> in <acronym>PHP</acronym>.
|
||||
</simpara>
|
||||
<simpara>
|
||||
See also <function>get_magic_quotes_gpc</function>.
|
||||
|
@ -41,7 +41,7 @@
|
|||
If enabled, most functions that return data from an external source,
|
||||
including databases and text files, will have quotes escaped with a
|
||||
backslash. Can be set at runtime, and defaults to <emphasis>off</emphasis>
|
||||
in PHP.
|
||||
in <acronym>PHP</acronym>.
|
||||
</simpara>
|
||||
<simpara>
|
||||
See also <function>set_magic_quotes_runtime</function> and
|
||||
|
@ -74,7 +74,7 @@
|
|||
<listitem>
|
||||
<simpara>
|
||||
There is no reason to use magic quotes because they are no longer
|
||||
a supported part of PHP. However, they did exist and did help a
|
||||
a supported part of <acronym>PHP</acronym>. However, they did exist and did help a
|
||||
few beginners blissfully and unknowingly write better (more secure)
|
||||
code. But, when dealing with code that relies upon this behavior
|
||||
it's better to update the code instead of turning magic quotes on.
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
<chapter xml:id="security.variables" xmlns="http://docbook.org/ns/docbook">
|
||||
<title>User Submitted Data</title>
|
||||
<para>
|
||||
The greatest weakness in many PHP programs is not inherent in the
|
||||
The greatest weakness in many <acronym>PHP</acronym> programs is not inherent in the
|
||||
language itself, but merely an issue of code not being written with
|
||||
security in mind. For this reason, you should always take the time
|
||||
to consider the implications of a given piece of code, to ascertain
|
||||
|
@ -74,7 +74,7 @@ exec ($evil_var);
|
|||
You may also want to consider turning off register_globals,
|
||||
magic_quotes, or other convenience settings which may confuse
|
||||
you as to the validity, source, or value of a given variable.
|
||||
Working with PHP in error_reporting(E_ALL) mode can also help warn
|
||||
Working with <acronym>PHP</acronym> in error_reporting(E_ALL) mode can also help warn
|
||||
you about variables being used before they are checked or
|
||||
initialized (so you can prevent unusual data from being
|
||||
operated upon).
|
||||
|
|
Loading…
Reference in a new issue