security — Удалить пароли из сообщений об ошибках (PHP)?

На производственных серверах вывод ошибок, безусловно, будет отключен как рутина. Тем не менее, я чувствую нервозность, когда вижу подобные сообщения об ошибках даже на моем экране разработчика:

stat(): stat failed for ftp://user:[email protected]:21/dir-de-nada

Это в контексте класса, который я написал вокруг ftp:// поток. Конечно, PHP не может отфильтровать пароли из любого произвольного места. Но в этом случае (как в случае с обёртками URL-адресов и так далее) наличие пароля является стандартным и очевидным.

Я уже ловлю ошибки. Однако я подумал, не нужно ли мне самому разобраться с этим, просто чтобы быть в безопасности во всех контекстах, или если есть способ, которым у меня может быть PHP, чтобы сделать это автоматически и глобально. (Это вопрос здесь.) Я думаю, нет, но нет никакого вреда в том, чтобы бросать здесь зонд.

Что касается того, что меня беспокоит, это только на моем экране разработчика. Однако отчеты об ошибках также будут полезны менеджерам сайтов и т. Д., Которым может не понадобиться знать пароль FTP. Врезка пароля FTP в журнал ошибок не представляет особой проблемы, но для отчетов, сохраняемых в базе данных и т. Д., Я действительно не хочу, чтобы такая информация распространялась где-либо, когда-либо, по очевидным причинам. Профилактические указатели, пожалуйста?

И если кому-то захочется внести соответствующие заметки о том, чтобы PHP не вымывал пароли и т. Д. Конфиденциальную информацию в любом контексте, это тоже приветствуется. Помимо «ничего не выводить никуда».

Редактировать: В ожидании лучших параметров обработчик сообщений и ошибок теперь выполняет следующее:

$msg = preg_replace('#((ftp|http)://)([^@]+?)@#', '$1*:*@', $msg);

Если вы работаете с потоками SSH2, добавьте регулярное выражение для ssh2\.(shell|exec|sftp|scp) в случае заинтересованности. И для хорошей меры, если вы используете трассировки стека, которые показывают аргументы, их также следует дезинфицировать.

Edit2: Об общей заметке об опыте работы с PHP-оберткой потока FTP.

1. В частности, работает паршиво, если есть какие-либо сбойные запросы, давая повторяющиеся тайм-ауты сценария.
2. Обратный вызов потока (определен в create_stream_context / $param['notification']) регистрирует в основном пустые / неполные данные вместо полных ответов от FTP-сервера.
3. Функции файловой системы, использующие потоковые контексты, могут возвращать или не возвращать правильные / непротиворечивые ошибки или регистрировать что-либо в обратном вызове. (Если кто-то хочет устранить неисправности, попросите об этом.)
4. Кажется, нет никакой возможности для постоянного соединения: PHP повторно входит в систему для каждого вызова файловой системы в одном и том же скрипте, даже если я перезагружаю stream_context_create ресурс.

Предположим, что контексты потока FTP хороши для одноразовых базовых транзакций, но серьезное «нет» для попыток сделать что-то большее за один раз, похоже на незрелый альт. установка для работы с файлами. Следующий…