Check translation for security (#1018)

Co-authored-by: Luffy <52o@qq52o.cn>

Author: lacatoire

security/apache.xml

@@ -14,12 +14,12 @@
     等技术来设计自己的访问模型，并把这些代码作为 <acronym>PHP</acronym> 脚本的一部份。
    </simpara>
    <simpara>
-    通常，一但安全性达到可以使 <acronym>PHP</acronym> 用户（这里也就是 Apache
+    通常，一旦安全性达到可以使 <acronym>PHP</acronym> 用户（这里也就是 Apache
     用户）承担的风险极小的程度时候，可能 <acronym>PHP</acronym>
-    已经到了阻止向用户目录写入任何文件或禁止访问和修改数据库的地步了。这就是说，无论是正常的文件还是非正常的文件，无论是正常的数据库事务来是恶意的请求，都会被拒之门外。
+    已经到了阻止向用户目录写入任何文件或禁止访问和修改数据库的地步了。这就是说，无论是正常的文件还是非正常的文件，无论是正常的数据库事务还是恶意的请求，都会被拒之门外。
    </simpara>
    <simpara>
-    一个常犯的对安全性不利的错误就是让 Apache 拥有 root 权限，或者通过其它途径斌予 Apache 更强大的功能。
+    一个常犯的对安全性不利的错误就是让 Apache 拥有 root 权限，或者通过其它途径赋予 Apache 更强大的功能。
    </simpara>
    <simpara>
     把 Apache 用户的权限提升为 root

security/cgi-bin.xml

@@ -25,7 +25,7 @@
       </simpara>
       <simpara>
        在 URL 请求的问号（<literal>?</literal>）后面的信息会传给 CGI
-       接口作为命名行的参数。其它的解释器会在命令行中打开并执行第一个参数所指定的文件。
+       接口作为命令行的参数。其它的解释器会在命令行中打开并执行第一个参数所指定的文件。
       </simpara>
       <simpara>
        当作为 CGI 二进制文件调用时，<command>php</command> 会拒绝解释命令行参数。
@@ -132,7 +132,7 @@ AddHandler php-script .php
      就是唯一能控制在哪里打开文件的选项。访问如
      <filename role="url">http://my.host/~user/doc.php</filename>
      这个 URL 时，并不会打开用户主目录下文件，而只会执行
-     <parameter>user_dir</parameter> 目录下的
+     <parameter>doc_root</parameter> 目录下的
      <filename role="uri">~user/doc.php</filename>（这个子目录以
      [<literal>~</literal>] 作开头）。
     </simpara>

security/current.xml

@@ -10,7 +10,7 @@
   每个新版本常常将会包含主要和次要的改变以增强安全性、修复任何缺陷、配置问题以及将会影响整个系统安全性和稳定性的其他问题。
  </simpara>
  <simpara>
-  和其它系统级别的脚本语言和程序一样，最好的方法是经常更新，并保持对最新版本和及其更改的了解。
+  和其它系统级别的脚本语言和程序一样，最好的方法是经常更新，并保持对最新版本及其更改的了解。
  </simpara>
 </chapter>
 

security/database.xml

@@ -33,10 +33,6 @@
      <simpara>
       应该为程序的每个方面创建不同的数据库帐号，并赋予对数据库对象的极有限的权限。仅分配给能完成其功能所需的权限，避免同一个用户可以完成另一个用户的事情。这样即使攻击者利用程序漏洞取得了数据库的访问权限，也最多只能做到和该程序一样的影响范围。
      </simpara>
-     <simpara>
-      鼓励用户不要把所有的事务逻辑都用 web
-      应用程序（即用户的脚本）来实现。最好用视图（view）、触发器（trigger）或者规则（rule）在数据库层面完成。当系统升级的时候，需要为数据库开辟新的接口，这时就必须重做所有的数据库客户端。除此之外，触发器还可以透明和自动地处理字段，并在调试程序和跟踪事实时提供有用的信息。
-     </simpara>
    </sect1>
 
    <sect1 xml:id="security.database.connection">
@@ -70,24 +66,20 @@
     </simpara>
 
     <sect2 xml:id="security.database.storage.hashing">
-    <title>Hashing</title>
+    <title>散列</title>
      <simpara>
-      In the case of truly hidden data, if its raw representation is not needed
-      (i.e. will not be displayed), hashing should be taken into consideration.
-      The well-known example for hashing is storing the cryptographic hash of a
-      password in a database, instead of the password itself.
+      对于真正隐藏的数据，如果不需要其原始表示形式（即不需要显示），应该考虑使用散列。
+      散列的典型例子是将密码的加密散列值存储在数据库中，而不是存储密码本身。
      </simpara>
      <simpara>
-      The <link linkend="ref.password">password</link> functions
-      provide a convenient way to hash sensitive data and work with these hashes.
+      <link linkend="ref.password">password</link> 函数提供了一种便捷的方式来对敏感数据进行散列处理，并使用这些散列值进行验证。
      </simpara>
      <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.
+      <function>password_hash</function> 用于使用当前可用的最强算法对给定字符串进行散列，
+      <function>password_verify</function> 用于检查给定密码是否与存储在数据库中的散列值匹配。
      </simpara>
      <example>
-      <title>Hashing password field</title>
+      <title>对密码字段进行散列</title>
       <programlisting role="php">
 <![CDATA[
 <?php
@@ -231,8 +223,7 @@ $query = "UPDATE usertable SET pwd='hehehe', trusted=100, admin='yes' WHERE
      </informalexample>
     </para>
     <simpara>
-     虽然攻击者必须具备至少一些关于数据库架构的知识才能进行成功的攻击，但获取这些信息通常非常简单。例如代码可以是开源软件的一部分并且公开可用。这些信息也可能通过闭源代码泄露——即使它经过了编码、混淆或编译——甚至通过自己的代码显示错误消息来泄露。其他方法包括使用典型的
-     table 和列名。例如，使用“users” table 和列名“id”、“username”和“password”的登录表单。
+     虽然攻击者必须具备至少一些关于数据库架构的知识才能进行成功的攻击，但获取这些信息通常非常简单。例如代码可以是开源软件的一部分并且公开可用。这些信息也可能通过闭源代码泄露 —— 即使它经过了编码、混淆或编译 —— 甚至通过自己的代码显示错误消息来泄露。其他方法包括使用典型的表名和列名。例如，使用 ”users” 表以及列名”id”、 ”username” 和 ”password” 的登录表单。
     </simpara>
     <para>
      <example>
@@ -307,12 +298,12 @@ $result = mssql_query($query);
 <![CDATA[
 <?php
 
-// The dynamic SQL part is validated against expected values
+// 动态 SQL 部分根据预期值进行验证
 $sortingOrder = $_GET['sortingOrder'] === 'DESC' ? 'DESC' : 'ASC';
 $productId = $_GET['productId'];
-// The SQL is prepared with a placeholder
+// 使用占位符准备 SQL
 $stmt = $pdo->prepare("SELECT * FROM products WHERE id LIKE ? ORDER BY price {$sortingOrder}");
-// The value is provided with LIKE wildcards
+// 使用 LIKE 通配符提供值
 $stmt->execute(["%{$productId}%"]);
 
 ?>

security/errors.xml

@@ -29,7 +29,7 @@
     或者 <function>highlight_file</function>
     函数来调试代码，但是在正式运行的网站中，这种做法可能会暴露出隐藏的变量、未检查的语法和其它的可能危及系统安全的信息。在运行一些具有内部调试处理的程序，或者使用通用调试技术是很危险的。如果让攻击者确定了程序是使用了哪种具体的调试技术，他们会尝试发送变量来打开调试功能：
     <example>
-     <title>利用变量打开调式功能</title>
+     <title>利用变量打开调试功能</title>
      <programlisting role="html">
 <![CDATA[
 <form method="post" action="attacktarget?errors=Y&amp;showerrors=1&amp;debug=1">

security/general.xml

@@ -11,8 +11,8 @@
     最好的安全机制应该能在不防碍用户，并且不过多地增加开发难度的情况下做到能满足需求。实际上，一些安全问题往往会发生在这种过度强化安全机制的系统上。
    </simpara>
    <simpara>
-    不要忘记著名的等强原则：一个系统的的强度是由它最薄弱的环节决定的（译者注：相当于木桶原理）。如果所有的事务都基于时间、地点、事务种类进行详细的记录，而用户验证却只依靠一个
-    cookie，那么用户所对应的事务记录的可信度就被大大剥弱了。
+    不要忘记著名的等强原则：一个系统的强度是由它最薄弱的环节决定的（译者注：相当于木桶原理）。如果所有的事务都基于时间、地点、事务种类进行详细的记录，而用户验证却只依靠一个
+    cookie，那么用户所对应的事务记录的可信度就被大大削弱了。
    </simpara>
    <simpara>
     调试代码的时候一定要记住，就算是一个简单的页面也很难对所有可能发生的情况进行检测：对你不满的雇员不一定会输入如你所愿的东西，黑客也有足够的时间研究你的系统，当然，你的宠物猫也会跳到你的键盘上。这就是为什么必须检查所有的代码，去发现哪里可以引入不正当的数据，然后对代码改进、简化或者增强。