Отчеты об ошибках

В случае настройки безопасности PHP у отчета об ошибках есть две стороны. Одна - плюс в сторону безопасности, другая - наоборот.

Стандартная техника атаки включает в себя тестирование системы путем указания заведомо неверных данных и получения деталей всех возвращенных ошибок. Это позволяет взломщику получить информацию о сервере, о возможных слабостях системы защиты. К примеру, если злоумышленнику доступна информация о странице, использующей предварительный ввод данных в форму, то он может попытаться изменить передаваемые переменные:

Пример 5-11. Атака на переменные с помощью собственной страницы HTML <form method="post" action="attacktarget?username=badfoo&password=badfoo"> <input type="hidden" name="username" value="badfoo"> <input type="hidden" name="password" value="badfoo"> </form>

Ошибки, которые обычно возвращаются PHP, очень помогают в отладке программ, указывая на файл или функцию, а также номер строки где произошла ошибка. Однако, вся эта информация может быть использована. Очень часто разработчики используют функции show_source(), highlight_string() или highlight_file(), как отладочные, но в реальном случае они могут показать скрытые переменные, неотлаженные участки кода и другую опасную информацию. Особенно опасен запуск кода с встроенными отладочными частями или с использованием технологий отладки. Если злоумышленник определит вашу схему отладки, он может просто послать вашему коду отладочные команды для произведения своих действий.

Пример 5-12. Использование отладочных переменных <form method="post" action="attacktarget?errors=Y&amp;showerrors=1"&debug=1"> <input type="hidden" name="errors" value="Y"> <input type="hidden" name="showerrors" value="1"> <input type="hidden" name="debug" value="1"> </form>

Независимо от способа обработки ошибок, возможность тестирования системы приводит к получению взломщиком дополнительной информации.

К примеру, сам стиль отображения ошибок PHP обозначает, что в системе запущен PHP. Если злоумышленник, видящий .html страницу захочет проверить сервер на слабые места в безопасности путем ввода неверных данных, он, таким образом, узнает, что система построена с использованием PHP.

Ошибки функций могут указать на запущенный в системе сервер баз данных или дать информацию о том, как написана эта Web-страница. Это позволяет вести дальнейшее исследование открытых мест в базе данных или искать ошибки и слабые места в Web-странице. Путем посылки различных некорректных данных злоумышленник может, например, узнать последовательность аутентификации (из номеров строк), а также может попытаться обнаружить "дыры" в различных местах программы.

Ошибки файловой системы или общие ошибки PHP могут открыть заданные Web-серверу разрешения, а также структуру файлов сервера. Коды ошибок разработчика ухудшают ситуацию, приводя к весьма примитивному использованию "официально скрытой" информации.

Есть три основных пути решения проблемы. Первый - отладить все функции и попытаться компенсировать наличие ошибок. Второй - полностью отключить отчет об ошибках. Третий - использовать собственный обработчик ошибок PHP. Выбор зависит от вашего желания и структуры вашей системы безопасности.

Еще один способ решения проблемы "досрочно" - использование встроенной опции PHP error_reporting(), для того, чтобы обезопасить программу и найти уязвимые переменные. Тестируя программу до развертывания с E_ALL можно быстро найти места, где переменные могут быть открыты для модификации. Как только программа готова к развертыванию, E_NONE предотвращает исследование.

Пример 5-13. Нахождение небезопасных переменных с помощью E_ALL <?php if ($username) { // не инициализирована и не проверяется перед использованием $good_login = 1; } if ($good_login == 1) { // если предыдущий тест не прошел, значит $username не инициализирована fpassthru ("/highly/sensitive/data/index.html"); } ?>