Предотвращение кражи пароля скриптами в проекте PHP с открытым исходным кодом? - PullRequest
5 голосов
/ 28 августа 2011

Я сейчас разрабатываю фреймворк PHP. Другие разработчики могут создавать модули для фреймворка. Исходный код этих модулей должен находиться в каталоге framework.

Поскольку проект с открытым исходным кодом, модули знают местоположение файла конфигурации, в котором есть пароль базы данных. Как защитить пароли от вредоносных модулей? Пожалуйста, проверьте, что модули могут просто require_once файл конфигурации и делать вредные вещи!

В настоящее время я храню пароли базы данных в каталоге с именем config и защищаю его с помощью файла .htaccess:

<Directory config>
order allow,deny
deny from all
<Directory>

Но этого недостаточно, чтобы скрипты не украли пароль?

Я прочитал ветку Как защитить пароли базы данных в PHP? , но это не помогло мне найти ответ.

Ответы [ 8 ]

3 голосов
/ 28 августа 2011

В PHP вы не можете. Это не песочница; любой код, который вы запускаете, получает все разрешения пользователя, под которым он работает. Он может читать и записывать файлы, выполнять команды, устанавливать сетевые подключения и т. Д. Вы должны абсолютно доверять любому коду, который вы вносите в свой проект, чтобы вести себя хорошо.

Если вам нужны границы безопасности, вам придется реализовать их самостоятельно через разделение привилегий. Каждый модуль должен запускаться в своем собственном процессе как пользователь с очень низкими привилегиями. Тогда вам нужно какое-то межпроцессное взаимодействие. Это может быть использование каналов на уровне ОС или запуск отдельных файлов .php от имени разных пользователей, работающих в качестве веб-служб, к которым обращаются пользовательские сценарии. В любом случае, он не вписывается в привычный способ работы PHP-приложений.

Или используйте другой язык, например Java, который может предлагать ограниченный код с более строгими гарантиями относительно того, что ему разрешено делать (см. SecurityManager и др.).

2 голосов
/ 28 августа 2011

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

Одна идея: Что вы можете сделать (но, вероятно, более ресурсоемким), так это прочитать каждый модуль, как текстовый файл. Затем вам нужно идентифицировать везде, что читает файл в своем скрипте. У вас есть такие вещи, как fopen для file_get_contents, чтобы рассмотреть. Вероятно, я бы сказал пользователям, что они могут только читать и записывать файлы, используя file_get_contents и file_put_contents, а затем использовать инструмент для удаления любых других функций записи / чтения файлов из своего скрипта (например, fopen). Затем напишите свою собственную функцию для замены file_get_contents и file_put_contents, заставьте их скрипт использовать вашу функцию, а не PHP file_get_contents и file_put_contents. В вашей функции file_get_contents вы будете проверять права доступа; получают ли они доступ к вашему файлу конфигурации, да или нет, а затем возвращают строку с надписью «доступ запрещен», если они есть, или вы используете реальное file_get_contents для чтения и возврата файла, если нет. Что касается вашего file_put_contents, вам просто нужно убедиться, что они не записывают файлы на ваш сервер (они не должны быть разрешены, представьте, что они могут сделать!), В качестве альтернативы, вы могли бы использовать CHMOD, чтобы остановить это. Как только вы по существу перезаписали модуль в памяти, чтобы обеспечить его безопасность, вы затем используете функцию «exec» для его выполнения.

Это заняло бы значительный объем работы - но это единственный чистый способ PHP, о котором я могу думать.

2 голосов
/ 28 августа 2011

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

1 голос
/ 28 августа 2011

Ну, я не вижу здесь никаких проблем.Если это модуль, он может делать вредные вещи по определению, с доступом к базе данных или без нее.Он может удалять файлы, читать файлы cookie и т. Д. И т. Д.

Таким образом, вы должны либо довериться этим модулям (возможно, после их просмотра), либо вообще отказаться от использования модулей.

1 голос
/ 28 августа 2011

Очень хороший вопрос без хорошего ответа, который я знаю, однако ...

Вы видели runkit ? Это позволяет для песочницы в PHP.

Официальная версия, по-видимому, больше не поддерживается, но есть версия GitHub, которая довольно популярна: zenovich / runkit на GitHub

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

Удачи с вашим проектом

1 голос
/ 28 августа 2011

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

Однако в конце концов это не должно быть вашей ответственностью.

0 голосов
/ 28 августа 2011

Я не думаю, что есть какой-то способ запретить модулю собирать разумные данные из фактической конфигурации фреймворка и отправлять их кому-то незнакомому.С другой стороны, я не думаю, что это должна быть ваша ответственность, чтобы защитить пользователя от этого.В конце концов, именно пользователь решит установить любой модуль, верно?Теоретически, именно он должен проверить намерения модуля.Drupal, например, ничего не делает в этом направлении.В любом случае, существует наихудшая проблема: что помешает неприятному модулю уничтожить всю базу данных после ее установки?И, кстати, что может сделать злоумышленник с паролем вашей базы данных?По крайней мере, в любом случае вам необходимо защитить соединение базы данных, чтобы только доверенные хосты могли подключаться к серверу базы данных (например, проверка на основе IP / хоста).

0 голосов
/ 28 августа 2011

Не включайте ваш фактический файл конфигурации в ваш проект с открытым исходным кодом.Для этого я просто создаю файл конфигурации шаблона config.ini.dist

Когда пользователь загружает ваш проект, он должен переименовать его в config.ini и ввести свою собственную информацию о конфигурации.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...