archived-doc-ru/security/errors.xml

<?xml version="1.0" encoding="windows-1251"?>
<!-- $Revision: 1.3 $ -->
<!-- splitted from ./index.xml, last change in rev 1.66 -->
  <sect1 id="security.errors">
   <title>Сообщения об ошибках</title>
   <para>
    С точки зрения безопасности вывод сообщений об ошибках несет в себе
    как плюсы, так и минусы.
   </para>
   <para>
    Одна из стандартных методик, применяемых в атаках - ввод некорректных данных с 
    последующим анализом содержания и характера сообщений об ошибках. Это дает
    взломщику возможность проверить скрипты и данные сервера на наличие 
    потенциальных дыр. Например, если взломщик получил некоторую информацию о 
    странице на основании отправки формы, он попробует предопределить некоторые 
    передаваемые значения или модифицировать их:
    <example>
     <title>Атака на переменные в HTML-странице</title>
     <programlisting role="html">
<![CDATA[
<form method="post" action="attacktarget?username=badfoo&amp;password=badfoo">
<input type="hidden" name="username" value="badfoo" />
<input type="hidden" name="password" value="badfoo" />
</form>
]]>
     </programlisting>
    </example>
   </para>
   <para>
    Возникаемые во время работы скриптов ошибки являются достаточно ценной
    информацией для разработчика, содержащей такие данные, как функция или файл,
    а также номер строки, в которой возникла ошибка. Вся эта информация может
    быть использована для взлома. Для PHP-разработчика достаточно привычно пользоваться
    такими функциями, как <function>show_source</function>,
    <function>highlight_string</function> или
    <function>highlight_file</function> в целях отладки, но в живых сайтах
    это может открыть информацию о скрытых переменных, непроверяемом синтаксисе и 
    других потенциально опасных моментах. Особенно опасно наличие кода со встроенным	
    механизмом отладки в публичных частях сайта. Взломщик может попытаться 
    запустить отладочный механизм, подбирая основные признаки отладки:
    <example>
     <title>Использование стандартных отладочных переменных</title>
     <programlisting role="html">
<![CDATA[
<form method="post" action="attacktarget?errors=Y&amp;showerrors=1&amp;debug=1">
<input type="hidden" name="errors" value="Y" />
<input type="hidden" name="showerrors" value="1" />
<input type="hidden" name="debug" value="1" />
</form>
]]>
     </programlisting>
    </example>
   </para>
   <para>
    Независимо от метода обработки ошибок возможность проверки системы
    на наличие ошибок снабжает взломщика дополнительной информацией.
   </para>
   <para>
    Например, стандартный вывод об ошибке указывает операционную систему,
    в которой выполняются PHP скрипты.  Если взломщик анализирует обыкновенную
    HTML-страницу, пытаясь найти уязвимые места, используя 
    ввод неверных данных он может обнаружить использование PHP скриптов в данной системе.
   </para>
   <para>
    Также уведомление об ошибке может дать информацию о том, какая база данных
    используется, или, к примеру, как построена логика работы скриптов. Это, в свою очередь,
    может позволить взломщику подключиться к открытому порту базы данных либо найти
    специфичные ошибки в коде. Пробуя поочередно различные неверные блоки данных,
    злоумышленник может определить порядок аутентификации в скрипте (например,
    по номерам строк с ошибками) или проверять на наличие дыр различные участки кода.
   </para>
   <para>
    Вывод стандартных ошибок, связанных с файловой системой, может указать, с какими привелегиями
    запущен веб-сервер, и как организованы каталоги сайта. Обработка подобных ошибок,
    написанная разработчиками приложения, может только усугубить проблему, если 
    взломщиком будет найден способ обнаружить "скрытую" отладочную информацию.
   </para>
   <para>
    Существует три основныч способа решения этой проблемы. Первый заключается в том,
    чтобы структурировать все функции и попытаться компенсировать объем выдаваемых ошибок.
    Второй способ - полностью отключить в работающем коде вывод сообщений об ошибках.
    И, наконец, третий способ - использовать специальные средства PHP для создания
    собственного обработчика ошибок. В зависимости от используемой вами политики безопасности
    вы можете применять в вашей конкретной ситуации все три способа.
   </para>
   <para>
    Один из возможных способов обезопасить ваш код перед его публикацией 
    для общего доступа - индивидуальное  использование <function>error_reporting</function>,
    чтобы выявить потенциально опасные переменные. Тестируя код перед выпуском релиза
    при помощи значения E_ALL, вы достаточно легко можете обнаружить участки
    кода, в которых переменные могут быть подменены либо модифицированы.
    После окончания тестирования, установив значение E_NONE, вы можете полностью
    отключить вывод сообщений об ошибках.
    <example>
     <title>Поиск потенциально опасных переменных при помощи E_ALL</title>
     <programlisting role="php">
<![CDATA[
<?php
if ($username) {  // Переменная не инициализируется перед использованием
    $good_login = 1;
}
if ($good_login == 1) { // Если предыдущая проверка потерпела неудачу, переменная оказывается неинициализированной
    readfile ("/highly/sensitive/data/index.html");
}
?>
]]>
     </programlisting>
    </example>
   </para>
  </sect1>

<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"../../manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->