Update variables.xml to En + Infostyle

security/variables.xml

@@ -1,31 +1,32 @@
 <?xml version="1.0" encoding="utf-8"?>
-<!-- EN-Revision: ab6785b01ce1006e3a9761988575289f40c9b678 Maintainer: shein Status: ready -->
+<!-- EN-Revision: f0ed705e1ac34fed4c92979f63bee74c382f991b Maintainer: shein Status: ready -->
 <!-- Reviewed: no -->
 <chapter xml:id="security.variables" xmlns="http://docbook.org/ns/docbook">
- <title>Данные, введённые пользователем</title>
+ <title>Данные пользовательского ввода</title>
  <para>
-  Наиболее опасные уязвимости во многих <acronym>PHP</acronym>-скриптах
-  возникают не столько из-за самого языка, сколько из-за кода,
-  написанного без учёта соответствующих требований безопасности.
-  Как следствие, вы всегда должны выделять время на исследование
+  Наиболее опасные уязвимости в <acronym>PHP</acronym>-скриптах
+  часто возникают не столько из-за самого языка, сколько из-за кода,
+  который написали с нарушением требований безопасности.
+  Поэтому лучше потратить время на исследование
   разрабатываемого участка кода, чтобы оценить потенциальную
   угрозу от ввода переменной с нестандартным значением.
   <example>
-   <title>Потенциально опасное использование переменных</title>
+   <title>Потенциально опасная обработка переменных</title>
    <programlisting role="php">
 <![CDATA[
 <?php
-// удалить файлы из домашней директории пользователя...
-// а может, из ещё какой-нибудь?
-unlink ($evil_var);
 
-// записать в лог-файл выполняемое действие...
-// а может быть в /etc/passwd?
-fwrite ($fp, $evil_var);
+// Удалить файлы из домашней директории пользователя...
+// а может, и ещё из какой-то?
+unlink($evil_var);
 
-// выполнение тривиальных действий... или rm -rf *?
-system ($evil_var);
-exec ($evil_var);
+// Записать в лог-файл выполняемое действие...
+// а может, в файл /etc/passwd?
+fwrite($fp, $evil_var);
+
+// Выполнение тривиальных действий... или команды rm -rf *?
+system($evil_var);
+exec($evil_var);
 
 ?>
 ]]>
@@ -33,53 +34,63 @@ exec ($evil_var);
   </example>
  </para>
  <para>
-  Вы должны тщательно проверять ваш код и быть абсолютно уверены в том,
-  что все данные, передаваемые веб-браузером, проверяются надлежащим образом.
-  Попробуйте ответить для себя на следующие вопросы:
+  Требуется тщательно проверять код и быть на 100 % уверенным в правильной
+  проверке данных, которые передаёт браузер.
+  Ответьте на следующие вопросы:
   <itemizedlist>
    <listitem>
     <simpara>
-     Будет ли данный скрипт воздействовать исключительно на предполагаемые
-     данные?
+     Влияет ли скрипт только на предполагаемые данные?
     </simpara>
    </listitem>
    <listitem>
     <simpara>
-     Могут ли быть обработаны некорректные или нестандартные данные?
+     Обрабатываются ли некорректные или нестандартные данные?
     </simpara>
    </listitem>
    <listitem>
    <simpara>
-     Возможно ли использование скрипта непредусмотренным способом?
+     Получится ли использовать скрипт способом, который не предусмотрели?
     </simpara>
    </listitem>
    <listitem>
     <simpara>
-     Возможно ли его использование в сочетании с другими скриптами
+     Возможно ли использовать скрипт в сочетании с другими скриптами
      в негативных целях?
     </simpara>
    </listitem>
    <listitem>
     <simpara>
-     Будет ли каждая транзакция корректно логирована?
+     Правильно ли логируется каждая транзакция?
     </simpara>
    </listitem>
   </itemizedlist>
  </para>
  <para>
-  Ответив на эти вопросы во время написания скрипта, а не после, вы,
-  возможно, предотвратите последующую доработку скрипта в целях повышения
-  его безопасности. Начиная разработку с этих вопросов, вы не гарантируете
-  полную безопасность вашей системы, но сможете значительно повысить её.
+  Лучше задуматься о безопасности при разработке скрипта,
+  а не дорабатывать небезопасный код, когда потребуется исправлять последствия уязвимостей.
+  Такой подход не гарантирует безопасность системы,
+  но помогает значительно снизить количество уязвимостей.
  </para>
  <para>
-  Вы также можете рассмотреть отключение таких конфигурационных опций, как
-  register_globals, magic_quotes и некоторых других, которые могут приводить
-  к сомнениям относительно происхождения или значения получаемых переменных.
-  Использование при написании <acronym>PHP</acronym>-кода режима
-  error_reporting(E_ALL) может помочь предупредить вас об
-  использовании переменных до инициализации или проверки
-  (что предотвратит работу с данными, отличными от ожидаемых).
+  Безопасность повышают путём отключения настроек, которые делают разработку удобной, но скрывают
+  источник, достоверность или целостность данных. Уязвимости к атакам наподобие инъекций
+  или жонглирования данными возникают, когда переменные создаются неявно или когда входные данные
+  не проверяются.
+ </para>
+ <para>
+  Директива <literal>register_globals</literal>
+  и директивы механизма <literal>magic_quotes</literal>, которые удалили в PHP 5.4.0, когда-то способствовали
+  этим рискам, поскольку автоматически создавали переменные из пользовательского ввода
+  и экранировали данные непоследовательно. Хотя директивы удалили из PHP, аналогичные риски сохраняются,
+  когда входные данные обрабатывают неправильно.
+ </para>
+ <para>
+  Вызов <link linkend="function.error-reporting">error_reporting(E_ALL)</link> включает режим сообщения об ошибках всех уровней
+  и помогает определять неинициализированные переменные и проверять входные данные. Инструкция
+  <link linkend="language.types.declarations.strict">declare(strict_types=1)</link> включает режим строгой типизации,
+  который появился в PHP 7 и который повышает безопасность за счёт строгой проверки типов,
+  предотвращает непреднамеренное преобразование типов и повышает общую безопасность.
  </para>
 </chapter>
 <!-- Keep this comment at the end of the file