[doc-en] master: Fix typos and grammars in the security directory (#5897)

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