Действительно ли подробным исключением/сообщениями об ошибках является угроза безопасности?
Я в настоящее время проверяю каждый ДОБИРАЕМЫЙ и переменная POST с isset() и выдайте исключения когда isset() возвращает false.
Пример 1:
if(!isset($_GET['some_var']))
throw new Exception('GET variable [some_var] is not set.');
$someVar = $_GET['some_var'];
Пример 2:
if(!isset($_GET['some_num']))
throw new Exception('GET variable [some_num] is not set.');
if(!ctype_digit($_GET['some_num']))
throw new Exception('GET variable [some_num] is not a number.');
$someNum = $_GET['some_num'];
В моем производственном приложении у меня есть глобальный обработчик исключений, который отправляет исключения и ошибки к файлу журнала и затем перенаправляет к универсальной странице извинения.
Действительно ли это хорошо практика? Таковы описательное исключение и сообщения об ошибках как те выше угроз безопасности (действительно ли возможно, что хакер смог бы прочитать уведомление исключения и затем использовать ту информацию для управления моими сценариями)?
Спасибо!
4 ответа
Отображение подробных сведений об ошибках пользователю может представлять угрозу безопасности. Поскольку в этом случае они записываются только в файл журнала, а единственные данные, которые получает пользователь, - это общая страница, которая ничего не показывает, вы можете быть настолько информативными, насколько хотите, и ничего не раскрывать, если журнал не скомпрометирован.
«Возможно ли, что хакер сможет прочитать уведомление об исключении и затем использовать эту информацию для управления моими скриптами?»
Возможно.
Обычно вы хотите предоставить как можно меньше информации конечному пользователю в состоянии ошибки. В этом случае, если вы скажете кому-то, что конкретная переменная get не существует, он может попытаться предоставить случайные значения этой переменной, чтобы увидеть, как ведет себя приложение.
Конечно, вы также должны уравновесить это с потребностями ваших реальных пользователей. Если это переменная, которую они обычно контролируют, то ответ о проблеме со значением вполне приемлемо.
ОБНОВЛЕНИЕ
Недавно столкнувшись с потоком веб-API, которые, кажется, думают, что выдача общих сообщений об ошибках - это выход, я хочу немного обновить это.
Очень важно, чтобы веб-API возвращали соответствующий объем информации потребляющей системе, чтобы они могли выяснить, что не так, и исправить это.
В одном недавнем случае с API обработки платежей их документация была просто неверной. Данные тестовой транзакции, которые они показывали, постоянно возвращались с сообщением «Ошибка сервера 500», и у нас не было другого выхода, кроме как позвонить одному из их разработчиков и кропотливо пройти через каждый элемент в их XML. Из 50 элементов только один имел то же имя, что и в «документах разработчика»
В другой интеграции нам выдали «Ошибка сервера 402». - Этот НЕ был платежным шлюзом. Хотя это сообщение никогда не упоминалось в их документах, очевидно, что это сообщение означало, что параметр JSON отсутствовал.Между прочим, этот параметр не упоминается в их документации, и разработчику снова потребовалось время, чтобы его идентифицировать.
В обоих вышеупомянутых случаях было бы невероятно полезно, если бы в ответ на сообщение об ошибке был добавлен пример действительной публикации документа. Подобно тому, как старые команды Unix / DOS возвращались со справочной информацией, когда вы передавали неверные параметры. Я действительно не хочу разговаривать с другими программистами. Я знаю, что их время стоит дорого, и они предпочли бы заняться чем-нибудь другим, чем ответить на звонок в службу поддержки; но, что более важно, если я работаю в 22:00 и мне нужен ответ RFN, то ожидание, пока программист сможет позвонить на следующий день, редко бывает вариантом.
Регистрация ошибок и подавление вывода - это в точности то, что вы должны делать. Отчеты об ошибках могут быть неприятными.
В топ-10 OWASP за 2007 год есть утечка информации и неправильная обработка ошибок , однако это было удалено в 2010 году. Установив dispaly_errors = On в ваш php.ini становится уязвимым для CWE-200 . Полный путь к вашему веб-приложению будет раскрыт злоумышленнику. Что еще хуже, включение отчетов об ошибках упрощает поиск SQL-инъекций путем поиска сообщений об ошибках sql.
При объединении этого в приложении PHP / MySQL вы можете выполнить очень серьезную атаку
$vuln_query="select name from user where id=".$_GET[id];
Если
http://localhost/vuln_query.php?id=1 union select "<?php eval($_GET[e])?>" into outfile "/path/to/web/root/backdoor.php"
Что делает этот полный запрос:
select name from user where id=1 union select "<?php eval($_GET[e])?>" into outfile "/path/to/web/root/backdoor.php"
Я бы удостоверился, что display_errors = Off и что file Привилегии FILE были отозваны для учетной записи пользователя MySQL вашего веб-приложения.
Обычно считается небезопасным распечатывать сообщения об ошибках системы PHP на производственном сервере вместо того, чтобы молча их регистрировать.
Хотя я не могу найти ничего опасного на общей странице извинений.