<?php
include_once $_SERVER['DOCUMENT_ROOT'] . '/include/shared-manual.inc';
$TOC = array();
$TOC_DEPRECATED = array();
$PARENTS = array();
include_once dirname(__FILE__) ."/toc/security.inc";
$setup = array (
  'home' => 
  array (
    0 => 'index.php',
    1 => 'PHP Manual',
  ),
  'head' => 
  array (
    0 => 'UTF-8',
    1 => 'ru',
  ),
  'this' => 
  array (
    0 => 'security.variables.php',
    1 => 'Данные пользовательского ввода',
    2 => 'Данные пользовательского ввода',
  ),
  'up' => 
  array (
    0 => 'security.php',
    1 => 'Безопасность',
  ),
  'prev' => 
  array (
    0 => 'security.errors.php',
    1 => 'Сообщения об ошибках',
  ),
  'next' => 
  array (
    0 => 'security.hiding.php',
    1 => 'Сокрытие PHP',
  ),
  'alternatives' => 
  array (
  ),
  'source' => 
  array (
    'lang' => 'ru',
    'path' => 'security/variables.xml',
  ),
  'history' => 
  array (
  ),
);
$setup["toc"] = $TOC;
$setup["toc_deprecated"] = $TOC_DEPRECATED;
$setup["parents"] = $PARENTS;
manual_setup($setup);

contributors($setup);

?>
<div id="security.variables" class="chapter">
 <h1 class="title">Данные пользовательского ввода</h1>

 <p class="para">
  Наиболее опасные уязвимости в <abbr title="PHP: Hypertext Preprocessor">PHP</abbr>-скриптах
  часто возникают не столько из-за самого языка, сколько из-за кода,
  который написали с нарушением требований безопасности.
  Поэтому лучше потратить время на исследование
  разрабатываемого участка кода, чтобы оценить потенциальную
  угрозу от ввода переменной с нестандартным значением.
  <div class="example" id="example-1">
   <p><strong>Пример #1 Потенциально опасная обработка переменных</strong></p>
   <div class="example-contents">
<div class="phpcode"><code><span style="color: #000000"><span style="color: #0000BB">&lt;?php<br /><br /></span><span style="color: #FF8000">// Удалить файлы из домашней директории пользователя...<br />// а может, и ещё из какой-то?<br /></span><span style="color: #0000BB">unlink</span><span style="color: #007700">(</span><span style="color: #0000BB">$evil_var</span><span style="color: #007700">);<br /><br /></span><span style="color: #FF8000">// Записать в лог-файл выполняемое действие...<br />// а может, в файл /etc/passwd?<br /></span><span style="color: #0000BB">fwrite</span><span style="color: #007700">(</span><span style="color: #0000BB">$fp</span><span style="color: #007700">, </span><span style="color: #0000BB">$evil_var</span><span style="color: #007700">);<br /><br /></span><span style="color: #FF8000">// Выполнение тривиальных действий... или команды rm -rf *?<br /></span><span style="color: #0000BB">system</span><span style="color: #007700">(</span><span style="color: #0000BB">$evil_var</span><span style="color: #007700">);<br /></span><span style="color: #0000BB">exec</span><span style="color: #007700">(</span><span style="color: #0000BB">$evil_var</span><span style="color: #007700">);<br /><br /></span><span style="color: #0000BB">?&gt;</span></span></code></div>
   </div>

  </div>
 </p>
 <p class="para">
  Требуется тщательно проверять код и быть на 100 % уверенным в правильной
  проверке данных, которые передаёт браузер.
  Ответьте на следующие вопросы:
  <ul class="itemizedlist">
   <li class="listitem">
    <span class="simpara">
     Влияет ли скрипт только на предполагаемые данные?
    </span>
   </li>
   <li class="listitem">
    <span class="simpara">
     Обрабатываются ли некорректные или нестандартные данные?
    </span>
   </li>
   <li class="listitem">
   <span class="simpara">
     Получится ли использовать скрипт способом, который не предусмотрели?
    </span>
   </li>
   <li class="listitem">
    <span class="simpara">
     Возможно ли использовать скрипт в сочетании с другими скриптами
     в негативных целях?
    </span>
   </li>
   <li class="listitem">
    <span class="simpara">
     Правильно ли логируется каждая транзакция?
    </span>
   </li>
  </ul>
 </p>
 <p class="para">
  Лучше задуматься о безопасности при разработке скрипта,
  а не дорабатывать небезопасный код, когда потребуется исправлять последствия уязвимостей.
  Такой подход не гарантирует безопасность системы,
  но помогает значительно снизить количество уязвимостей.
 </p>
 <p class="para">
  Безопасность повышают путём отключения настроек, которые делают разработку удобной, но скрывают
  источник, достоверность или целостность данных. Уязвимости к атакам наподобие инъекций
  или жонглирования данными возникают, когда переменные создаются неявно или когда входные данные
  не проверяются.
 </p>
 <p class="para">
  Директива <code class="literal">register_globals</code>
  и директивы механизма <code class="literal">magic_quotes</code>, которые удалили в PHP 5.4.0, когда-то способствовали
  этим рискам, поскольку автоматически создавали переменные из пользовательского ввода
  и экранировали данные непоследовательно. Хотя директивы удалили из PHP, аналогичные риски сохраняются,
  когда входные данные обрабатывают неправильно.
 </p>
 <p class="para">
  Вызов <a href="function.error-reporting.php" class="link">error_reporting(E_ALL)</a> включает режим сообщения об ошибках всех уровней
  и помогает определять неинициализированные переменные и проверять входные данные. Инструкция
  <a href="language.types.declarations.php#language.types.declarations.strict" class="link">declare(strict_types=1)</a> включает режим строгой типизации,
  который появился в PHP 7 и который повышает безопасность за счёт строгой проверки типов,
  предотвращает непреднамеренное преобразование типов и повышает общую безопасность.
 </p>
</div>
<?php manual_footer($setup); ?>