Меня всегда беспокоило то, что многие PHP-программы требуют от пользователя хранить пароль mysql в виде обычного текста (в строке или константе) в файле конфигурации в корне приложения.
Есть ли лучший подход к этому после всех этих лет?
До сих пор я придумал два минимальных повышения безопасности:
сделать файл нечитаемым через Интернет с помощью правил в .htaccess (в случае неудачи php или наличия уязвимости безопасности для чтения источника php)
уничтожить пароль в памяти после того, как db connect сделан (unset) (чтобы предотвратить сброс строк из-за нарушения безопасности, инъекции и т. д.)
но, конечно, ни один из них не решает исходную проблему.
Спасибо за любые другие идеи!
Поскольку для вашего кода потребуется пароль, нет никакой надежной защиты. Но вы можете усложнить восстановление.
Я помещал некоторый хэш в свой веб-конфигуратор, как переменную среды, скажем, MYSQL_PASS_HASH
Затем я делаю что-то вроде md5(getenv('MYSQL_PASS_HASH').'gibberish$qwefsdf') который затем является паролем. Конечно, после этого вы должны unsetenv , если вы параноики.
Ваш пароль буквально не будет храниться где-нибудь, и его можно восстановить только тогда, когда у вас есть и ваша веб-конфигурация, и ваша база данных.
Это происходит в файле за пределами webroot (не доверяйте .htaccess ).
Лично я храню конфиденциальную информацию, такую как сведения о соединении с базой данных, в файле config.ini за пределами корня моей веб-папки. Тогда в моем index.php я могу сделать:
$config = parse_ini_file('../config.ini');
Это означает, что переменные не видны, если ваш сервер случайно запускает PHP-скрипты как обычный текст (что было раньше, печально на Facebook); и только PHP-скрипты имеют доступ к переменным.
Это также не зависит от .htaccess, в котором нет никакого непредвиденного обстоятельства, если ваш файл .htaccess перемещается или уничтожается.
Caveat, добавлено 14 февраля 2017 года: теперь я буду хранить параметры конфигурации, подобные этому, в качестве переменных среды. Я уже не использовал файл .ini- файла.
Сохранение ваших конфигурационных файлов за пределами корневого каталога является популярным способом повышения безопасности файлов конфигурации.
Помимо правильного хранения этих конфиденциальных данных, вы также должны создать отдельного пользователя MySQL, который имеет только необходимые привилегии и ограничивает доступ к базе данных / таблицам / представлениям, к которым у него должен быть доступ. И поскольку сервер базы данных часто запускается на том же компьютере, что и веб-сервер, также ограничивайте доступ к локальным доступам. Поэтому не используйте пользователя с привилегиями root, если ему просто нужно читать данные из одной базы данных / таблицы.
Конечно, вы никогда не должны хранить пароль в текстовом файле в корне документа. Какие дальнейшие шаги вы предпримете для его защиты, будет зависеть от уровня доступа, который вы должны настроить для своего веб-сервера.
Вы можете определить пароль в php.ini (или через ini-конфигурацию в Apache config или .htaccess). Или установите его в среде при запуске своего веб-сервера.
Нет смысла просто шифровать пароль – это означает, что вам нужно сохранить ключ дешифрования – если вы не используете пароль, предоставленный пользователем, с аутентификацией кворума для дешифрования пароля (но это предотвращает доступ к сеансам неидентифицированных сеансов связи с db и становится беспорядочным, когда вам нужно добавить новых пользователей к кворуму).
Если это дешевый пакет хостинга, и у вас нет доступного хранилища за пределами корня документа, тогда сохранение пароля в файле с включенным php-файлом должно помешать его экспонированию (файл будет проанализирован с помощью php-файла). Альтернативно простое имя файла с «.ht» в начале может препятствовать удалённому доступу.
Обратите внимание, что ваш второй вариант несколько избыточен – если кто-то может нанести столько ущерба вашему коду, тогда им не нужно извлекать пароль из текущего кода.
На самом деле нет решения проблемы.
C.
Это не должно быть в веб-корне. Вы можете переместить файл за пределы веб-сайта и вызвать его таким образом. Это просто означает, что файл нельзя вызывать непосредственно из Интернета.
Если у вашего кода есть недостатки безопасности, такие как включение файлов без фильтрации из данных GET, этот файл все еще находится под угрозой. Настоящий ключ гарантирует, что ваше приложение также безопасно.
Если вы готовы отменить доступность для защиты файлов, вы можете извлечь пароль из файла конфигурации и потребовать от администратора ввести его при загрузке и сохранить его в глобальной переменной.
Вам все равно нужно убедиться, что вы в безопасности от инъекционных атак, которые могут вывести эту переменную, и, конечно же, у вас есть ручной шаг в процессе перезагрузки.