Защита БД и данных сеанса на общем хосте PHP

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

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

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

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

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

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

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

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

«вы можете поместить свои переменные подключения к БД в файл ниже корневого веб-сайта. это, по крайней мере, защитит его от веб-доступа. если вы также собираетесь использовать сеансы на основе файлов, вы можете установить путь сеанса в каталоге вашего пользователя и снова за пределами веб-корня».

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

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

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

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

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