Author: Chun-Sheng, Li (peter279k)
Committer: GitHub (web-flow)
Pusher: lacatoire
Date: 2026-09-30T13:56:46+02:00
Commit: https://github.com/php/doc-en/commit/f5b71e9150fddd14fa56c3c8f7197ef08e966c0b
Raw diff: https://github.com/php/doc-en/commit/f5b71e9150fddd14fa56c3c8f7197ef08e966c0b.diff
Fix typos and grammars in the security directory (#5897)
Changed paths:
M security/apache.xml
M security/cgi-bin.xml
M security/current.xml
M security/database.xml
M security/errors.xml
M security/filesystem.xml
M security/general.xml
M security/hiding.xml
M security/intro.xml
M security/variables.xml
Diff:
diff --git a/security/apache.xml b/security/apache.xml
index 5c682a179ebc..98e69851d076 100644
--- a/security/apache.xml
+++ b/security/apache.xml
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
-<!-- splitted from ./index.xml, last change in rev 1.66 -->
+<!-- split from ./index.xml, last change in rev 1.66 -->
<chapter xml:id="security.apache" xmlns="http://docbook.org/ns/docbook">
<title>Installed as an Apache module</title>
<simpara>
@@ -18,16 +18,16 @@
that code as part of your <acronym>PHP</acronym> scripts.
</simpara>
<simpara>
- 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,
+ Often, once security is established to the point that the <acronym>PHP</acronym>
user
+ (in this case, the Apache user) has very little risk attached to it,
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.
</simpara>
<simpara>
- A frequent security mistake made at this point is to allow apache
- root permissions, or to escalate apache's abilities in some other
+ A frequent security mistake made at this point is to allow Apache
+ root permissions, or to escalate Apache's abilities in some other
way.
</simpara>
<simpara>
@@ -40,7 +40,7 @@
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 <acronym>PHP</acronym>. You can also set up
- apache-only areas, to restrict all web based activity to non-user,
+ Apache-only areas, to restrict all web based activity to non-user,
or non-system, files.
</simpara>
</chapter>
diff --git a/security/cgi-bin.xml b/security/cgi-bin.xml
index d46c5df085d8..eea554a8d008 100644
--- a/security/cgi-bin.xml
+++ b/security/cgi-bin.xml
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
-<!-- splitted from ./index.xml, last change in rev 1.66 -->
+<!-- split from ./index.xml, last change in rev 1.66 -->
<chapter xml:id="security.cgi-bin" xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink">
<title>Installed as CGI binary</title>
@@ -13,7 +13,7 @@
different kinds of <acronym>CGI</acronym> wrappers to create safe
<command>chroot</command> and <command>setuid</command>
environments for scripts. This setup usually involves installing
- executable <command>php</command> binary to the web server <filename
class="directory">cgi-bin</filename> directory.
+ the executable <command>php</command> binary in the web server <filename
class="directory">cgi-bin</filename> directory.
CERT advisory <link xlink:href="&url.cert;">CA-96.11</link>
recommends
against placing any interpreters into <filename
class="directory">cgi-bin</filename>.
Even if the <command>php</command> binary can be used as a standalone interpreter,
@@ -56,7 +56,7 @@
redirected request <filename
role="url">http://my.host/cgi-bin/php/secret/script.php</filename>.
Unfortunately, if the request is originally given in this form,
- no access checks are made by web server for file <filename
+ no access checks are made by the web server for file <filename
role="uri">/secret/script.php</filename>, but only for the
<filename role="uri">/cgi-bin/php</filename> file. This way
any user able to access <filename
@@ -150,7 +150,7 @@ AddHandler php-script .php
redirected, as described in the previous section, is not
available, it is necessary to set up a
script <link linkend="ini.doc-root">doc_root</link> that is
- different from web document root.
+ different from the web document root.
</simpara>
<simpara>
You can set the PHP script document root by the configuration
@@ -167,10 +167,10 @@ AddHandler php-script .php
<simpara>
Another option usable here is <link
linkend="ini.user-dir">user_dir</link>. When
<parameter>user_dir</parameter> is
- unset, only thing controlling the opened file name is
+ unset, the only thing controlling the opened file name is
<parameter>doc_root</parameter>. Opening a URL like <filename
role="url">http://my.host/~user/doc.php</filename>
does not
- result in opening a file under users home directory, but a file
+ result in opening a file under the user's home directory, but a file
called <filename role="uri">~user/doc.php</filename> under
<parameter>doc_root</parameter> (yes, a directory name starting with a tilde
[<literal>~</literal>]).
diff --git a/security/current.xml b/security/current.xml
index b9e3ab95c801..37a5e05da28e 100644
--- a/security/current.xml
+++ b/security/current.xml
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
-<!-- splitted from ./index.xml, last change in rev 1.66 -->
+<!-- split from ./index.xml, last change in rev 1.66 -->
<chapter xml:id="security.current" xmlns="http://docbook.org/ns/docbook">
<title>Keeping Current</title>
<simpara>
diff --git a/security/database.xml b/security/database.xml
index 7ff968a9a195..eb0b3dafb6d1 100644
--- a/security/database.xml
+++ b/security/database.xml
@@ -26,7 +26,7 @@
take action to increase the protection of your database, the less
probability of an attacker succeeding in exposing or abusing any stored
information. Good design of the database schema and the application
- deals with your greatest fears.
+ addresses your greatest concerns.
</simpara>
<sect1 xml:id="security.database.design">
@@ -47,11 +47,11 @@
</simpara>
<simpara>
You may create different database users for every aspect of your
- application with very limited rights to database objects. The most
- required privileges should be granted only, and avoid that the same user
+ application with very limited rights to database objects. Only the
+ required privileges should be granted, and avoid that the same user
can interact with the database in different use cases. This means that if
- intruders gain access to your database using your applications credentials,
- they can only effect as many changes as your application can.
+ intruders gain access to your database using your application's credentials,
+ they can only affect as many changes as your application can.
</simpara>
</sect1>
@@ -111,7 +111,7 @@
<simpara>
<function>password_hash</function> is used to hash a given string using the
strongest algorithm currently available and <function>password_verify</function>
- checks whether the given password matches the hash stored in database.
+ checks whether the given password matches the hash stored in the database.
</simpara>
<example>
<title>Hashing password field</title>
@@ -191,7 +191,7 @@ insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd)
]]>
</programlisting>
</informalexample>
- If it happened, the script would present a superuser access to the attacker.
+ If it happened, the script would grant superuser access to the attacker.
Note that <literal>0;</literal> is to supply a valid offset to the
original query and to terminate it.
</para>
@@ -258,7 +258,7 @@ $query = "UPDATE usertable SET pwd='$pwd' WHERE
uid='$uid';";
If a malicious user submits the value
<literal>' or uid like'%admin%</literal> to
<varname>$uid</varname> to
change the admin's password, or simply sets <varname>$pwd</varname> to
- <literal>hehehe', trusted=100, admin='yes</literal> to gain more
+ <literal>hehehe', trusted=100, admin='yes</literal> to gain more
privileges, then the query will be twisted:
<informalexample>
<programlisting role="php">
@@ -307,7 +307,7 @@ $result = mssql_query($query);
]]>
</programlisting>
</example>
- If attacker submits the value
+ If an attacker submits the value
<literal>a%' exec master..xp_cmdshell 'net user test testpass /ADD'
--</literal>
to <varname>$prod</varname>, then the <varname>$query</varname> will
be:
<informalexample>
@@ -418,7 +418,7 @@ $stmt->execute(["%{$productId}%"]);
<listitem>
<simpara>
Never connect to the database as a superuser or as the database owner.
- Use always customized users with minimal privileges.
+ Always use customized users with minimal privileges.
</simpara>
</listitem>
<listitem>
diff --git a/security/errors.xml b/security/errors.xml
index e5742c537b16..20aecc05f9ff 100644
--- a/security/errors.xml
+++ b/security/errors.xml
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
-<!-- splitted from ./index.xml, last change in rev 1.66 -->
+<!-- split from ./index.xml, last change in rev 1.66 -->
<chapter xml:id="security.errors" xmlns="http://docbook.org/ns/docbook">
<title>Error Reporting</title>
<para>
@@ -31,7 +31,7 @@
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 occurred in. This is all
+ and the line number on which the failure occurred. This is all
information that can be exploited. It is not uncommon for a php
developer to use <function>show_source</function>,
<function>highlight_string</function>, or
@@ -67,23 +67,23 @@
the system), by feeding it the wrong data they may be able to
determine that a system was built with PHP.
</para>
- <para>
+ <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
+ specific database engine, or how a web page is
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.
- </para>
- <para>
+ may be present in different locations in the script.
+ </simpara>
+ <simpara>
A filesystem or general PHP error can indicate what permissions
the web server has, as well as the structure and organization of
- files on the web server. Developer written error code can aggravate
+ files on the web server. Developer-written error code can aggravate
this problem, leading to easy exploitation of formerly "hidden"
information.
- </para>
+ </simpara>
<para>
There are three major solutions to this issue. The first is to
scrutinize all functions, and attempt to compensate for the bulk
diff --git a/security/filesystem.xml b/security/filesystem.xml
index 88c1807ab531..d2de0434b49d 100644
--- a/security/filesystem.xml
+++ b/security/filesystem.xml
@@ -1,13 +1,13 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
-<!-- splitted from ./index.xml, last change in rev 1.66 -->
+<!-- split from ./index.xml, last change in rev 1.66 -->
<chapter xml:id="security.filesystem" xmlns="http://docbook.org/ns/docbook">
<title>Filesystem Security</title>
<simpara>
<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
+ should be taken with any files which are world-readable to ensure
that they are safe for reading by all users who have access to that
filesystem.
</simpara>
@@ -46,8 +46,8 @@ echo "The file has been deleted!";
]]>
</programlisting>
</example>
- Since the username and the filename are postable from a user form,
- they can submit a username and a filename belonging to someone else,
+ Since the username and the filename are postable from a user form,
+ they can submit a username and a filename belonging to someone else,
and delete it even if they're not supposed to be allowed to do so.
In this case, you'd want to use some other form of authentication.
Consider what could happen if the variables submitted were
@@ -128,7 +128,7 @@ echo htmlentities($logstring, ENT_QUOTES);
<![CDATA[
<?php
-$username = $_SERVER['REMOTE_USER']; // using an authentication mechanisim
+$username = $_SERVER['REMOTE_USER']; // using an authentication mechanism
$userfile = $_POST['user_submitted_filename'];
$homedir = "/home/$username";
@@ -145,24 +145,24 @@ if (!ctype_alnum($username) ||
!preg_match('/^(?:[a-z0-9_-]|\.(?!\.))+$/iD', $us
</programlisting>
</example>
</para>
- <para>
- Depending on your operating system, there are a wide variety of files
+ <simpara>
+ Depending on your operating system, there is a wide variety of files
which you should be concerned about, including device entries
(<filename>/dev/</filename>
or <filename>COM1</filename>), configuration files
(<filename>/etc/</filename> files and
the <literal>.ini</literal> files), well known file storage areas
(<filename>/home/</filename>,
<filename>My Documents</filename>), etc. For this
reason, it's usually easier to create a policy where you forbid
everything except for what you explicitly allow.
- </para>
+ </simpara>
<sect1 xml:id="security.filesystem.nullbytes">
<title>Null bytes related issues</title>
<simpara>
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
+ 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.
- The following example shows a vulnerable code that demonstrates this problem:
+ The following example shows the vulnerable code that demonstrates this problem:
</simpara>
<example>
<title>Script vulnerable to null bytes</title>
@@ -193,7 +193,7 @@ if (file_exists('/home/wwwrun/' . $file . '.php')) {
<![CDATA[
<?php
-$file = $_GET['file'];
+$file = $_GET['file'];
// Whitelisting possible values
switch ($file) {
diff --git a/security/general.xml b/security/general.xml
index 6b9409b0eaba..225aae78397c 100644
--- a/security/general.xml
+++ b/security/general.xml
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
-<!-- splitted from ./index.xml, last change in rev 1.66 -->
+<!-- split from ./index.xml, last change in rev 1.66 -->
<chapter xml:id="security.general" xmlns="http://docbook.org/ns/docbook">
<title>General considerations</title>
<simpara>
diff --git a/security/hiding.xml b/security/hiding.xml
index 581c5bf55605..53b18f4a1393 100644
--- a/security/hiding.xml
+++ b/security/hiding.xml
@@ -1,18 +1,18 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
-<!-- splitted from ./index.xml, last change in rev 1.66 -->
+<!-- split from ./index.xml, last change in rev 1.66 -->
<chapter xml:id="security.hiding" xmlns="http://docbook.org/ns/docbook">
<title>Hiding PHP</title>
<para>
In general, security by obscurity is one of the weakest forms of security.
But in some cases, every little bit of extra security is desirable.
</para>
- <para>
+ <simpara>
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
+ system. By setting expose_php to <literal>off</literal> in your
&php.ini; file, you reduce the amount of information available to them.
- </para>
+ </simpara>
<para>
Another tactic is to configure web servers such as apache to
parse different filetypes through <acronym>PHP</acronym>, either with an
&htaccess;
diff --git a/security/intro.xml b/security/intro.xml
index eac078d661b8..9776f93213d8 100644
--- a/security/intro.xml
+++ b/security/intro.xml
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
-<!-- splitted from ./index.xml, last change in rev 1.66 -->
+<!-- split from ./index.xml, last change in rev 1.66 -->
<chapter xml:id="security.intro" xmlns="http://docbook.org/ns/docbook">
<title>Introduction</title>
<simpara>
@@ -17,7 +17,7 @@
</simpara>
<simpara>
As there are many different ways of utilizing PHP, there are many
- configuration options controlling its behaviour. A large
+ configuration options controlling its behavior. A large
selection of options guarantees you can use PHP for a lot of
purposes, but it also means there are combinations of these
options and server configurations that result in an insecure
@@ -34,7 +34,7 @@
<simpara>
This chapter starts with some general security advice, explains
the different configuration option combinations and the situations
- they can be safely used, and describes different considerations in
+ in which they can be safely used, and describes different considerations in
coding for different levels of security.
</simpara>
</chapter>
diff --git a/security/variables.xml b/security/variables.xml
index 8b0925e90b00..406af7fea646 100644
--- a/security/variables.xml
+++ b/security/variables.xml
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
-<!-- splitted from ./index.xml, last change in rev 1.66 -->
+<!-- split from ./index.xml, last change in rev 1.66 -->
<chapter xml:id="security.variables" xmlns="http://docbook.org/ns/docbook">
<title>User Submitted Data</title>
<para>
@@ -63,13 +63,13 @@ exec ($evil_var);
</listitem>
</itemizedlist>
</para>
- <para>
+ <simpara>
By adequately asking these questions while writing the script,
- rather than later, you prevent an unfortunate re-write when you
+ rather than later, you prevent an unfortunate rewrite when you
need to increase your security. By starting out with this mindset,
you won't guarantee the security of your system, but you can help
improve it.
- </para>
+ </simpara>
<para>
Improve security by disabling convenience settings that obscure input
data's origin, validity, or integrity. Implicit variable creation and
@@ -83,13 +83,13 @@ exec ($evil_var);
escaping data inconsistently. While no longer in PHP, similar risks persist
if input handling is mismanaged.
</para>
- <para>
+ <simpara>
Enable <link
linkend="function.error-reporting">error_reporting(E_ALL)</link> to
help detect uninitialized variables and validate input. Use strict types
(<link
linkend="language.types.declarations.strict">declare(strict_types=1)</link>,
introduced in PHP 7) to enforce type safety, prevent unintended type conversions,
- and improving overall security.
- </para>
+ and improve overall security.
+ </simpara>
</chapter>
<!-- Keep this comment at the end of the file