Fix typos and grammars in the security directory

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>

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>]).

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>

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>

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

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) {

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>

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;

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>

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