Риск безопасности при хранении информации для входа в SQL в коде PHP?

Question

Первый читатель, первый постер (добро!)

Итак, я реализую свои сценарии входа на неофициальный сайт. Вряд ли это будет скомпрометировано, но просто для обеспечения безопасности, я хотел бы спросить, существует ли угроза безопасности, если мой логин базы данных MySQL хранится в виде открытого текста в коде php.

Насколько я знаю, сам код анализируется Apache, поэтому конечный пользователь не видит его (только вывод), что означает, что его следует хранить безопасно ... но я бы хотел второе мнение.

Резюме: Доступ к базе данных через mysql_connect, mysql_select_db, mysql_query. Информация для входа хранится в локальных переменных, определенных на каждой итерации скрипта, и (я думаю) сбрасывается после завершения скрипта.

Уязвимость в безопасности?

Answer 1

Вы также можете переместить комбинацию имени пользователя и пароля в отдельный файл конфигурации, который находится вне webroot. Убедитесь, что это место не доступно напрямую со стороны веб-сервера.

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

В качестве дополнительного бонуса, если вы используете в веб-корне что-либо, создающее копию файла .php (редакторы, SVN или что-то еще), вы не рискуете, чтобы кто-то обошел выполнение .php.

Answer 2

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

Я рекомендую забрать разрешения на чтение из файла для пользователей, отличных от веб-сервера и для вас самих - если у вас есть другие пользователи, которые могут следить за файлом, они смогут получить доступ к вашему серверу mysql. *

Кроме того, вы должны настроить разрешение для исполняемого файла в верхнем каталоге, так как это не позволит неавторизованным пользователям даже войти в него.

Укрепите разрешенный хост вашего пользователя mysql, чтобы к нему могли подключиться только те коробки, которые вам нужны.

Конечно, если ваш ящик взломан и злоумышленник получает root-доступ, мало что защитит вас.

Answer 3

Я не знаю, как вы подключаетесь к базе данных MySQL, но если вы используете PDO, есть вероятность, что конструктор PDO выдает исключение. Если вы не поймете это исключение, Zend Engine по умолчанию покажет обратную трассировку и покажет детали вашего соединения!

Обычно кредиты подключения хранятся в файле / переменной php или, в этом случае, вы используете PDO, в DSN (имя источника данных). Я бы даже посоветовал вам поместить его в php-файл, потому что он будет проанализирован и не будет отправляться в сеть ...

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

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

Answer 4

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

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

Глубокая защита

<?php  // simplest /index.php, as the only .PHP file in the public-accessible webroot
require '../bootstrap.php';

Answer 5

Вы можете добавить дополнительный уровень безопасности, поместив все ваши файлы php (за исключением, конечно, index.php) в отдельный каталог и защитите их с помощью файла .htaccess. Это охватывает случаи, когда парсер php не вызывается и apache возвращает файлы в виде открытого текста. Еще одна вещь, которая может быть полезной: <?php defined('some_id_here') or die(); ?>. Вы можете поместить это в начало каждого php-файла, кроме index.php (где вы определяете some_id_here), чтобы не было прямого доступа к вашим файлам базы данных.

Answer 6

Любой, кто может войти в систему с правами суперпользователя на этом веб-сервере (или, возможно, также с более низкими привилегиями), сможет увидеть ваш пароль - но тогда, по существу, невозможно защититься от суперпользователя (где бы вы ни остались Ваш пароль, они могут взломать и найти его). Помимо этого риска, вы должны быть в безопасности.

Редактировать: резервные копии сервера также могут быть использованы (если они не зашифрованы, или кем-то, кто может их расшифровать), чтобы восстановить ваш пароль, если он не понятен в вашем .php-скрипте. Эта возможная атака может быть смягчена (к большим неудобствам / затратам), если хранить пароль в другом безопасном месте и отправлять его (надежно) только в строго ограниченных обстоятельствах. Вы боитесь такой атаки?