Сообщение об ошибке

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

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

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

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

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

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

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

Есть три основных способа решения этой проблемы:

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

В зависимости от используемой вами политики безопасности, вы может применить все три способа в вашей ситуации.

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