Защита базы данных и данных сеанса на общем хосте PHP - PullRequest
7 голосов
/ 25 сентября 2008

Я написал PHP-приложение, используя SQLite и сеансы, хранящиеся в filesystem.

Это функционально хорошо и привлекательно мало обслуживания. Но теперь он должен работать на общем хосте.

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

Многие рекомендуют хранить сеансы в DBMS, например, MySQL в этой ситуации. Сначала я подумал, что просто сделаю это и перенесу данные SQLite в MySQL. Но потом я понял, что учетные данные MySQL должны быть доступны для чтения пользователю веб-приложения, поэтому я вернулся к исходной точке.

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

В противном случае, что я могу сделать для защиты своей базы данных и данных сеанса в этой ситуации?

Ответы [ 5 ]

4 голосов
/ 25 сентября 2008

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

Если ваш хостинг-провайдер разрешит это, то поможет PHP в качестве CGI под другим пользователем, но я ожидаю, что произойдет значительное снижение производительности, поскольку каждый запрос потребует создания нового процесса. (Вы можете посмотреть на FCGI как на более эффективную альтернативу.)

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

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

1 голос
/ 25 сентября 2008

Я не рассматриваю безопасность как все или ничего. Есть шаги, которые вы можете предпринять. Дайте пользователю web db только те разрешения, которые ему необходимы. Храните пароли в виде хэшей. Используйте открытый вход, чтобы пользователи предоставляли свои учетные данные через SSL.

PHP на cgi может работать медленнее, и некоторые хосты могут просто не захотеть поддерживать более одной среды.

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

0 голосов
/ 25 сентября 2008

Я бы решил проблему с изменением инфраструктуры вместо кода. Рассмотрите возможность обновления до сервера VPS. В настоящее время вы можете получить их очень недорого. Я видел, как VPS запускается на 10 $ / мес.

0 голосов
/ 25 сентября 2008

"Вы можете поместить переменные соединения с БД в файл ниже корневого веб-каталога. Это по крайней мере защитит его от веб-доступа. Если вы также собираетесь использовать файловые сеансы, вы можете установить путь сеанса в каталог пользователя и снова вне корня сети. "

У меня нет аккаунта, поэтому я не могу его опровергнуть ... но серьезно, это даже не имеет отношения к вопросу.

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

Для OP я думаю, что PHP как CGI является наиболее безопасным решением, как вы уже сами предложили. Но, как сказал кто-то другой, это сказывается на производительности.

Что-то, на что вы могли бы обратить внимание, это перемещение ваших сессий и базы данных в MySQL и использование safe_mode и / или open_basedir.

0 голосов
/ 25 сентября 2008

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

...