Я не знаком с PHP, поэтому мой ответ не будет отображаться непосредственно в практических рекомендациях, но я думаю, что вы работаете над некоторыми неправильными представлениями о том, какую защиту обеспечивают различные функции системы, из-за чего вы отказались от действительнойрешения в пользу решений, которые имеют точно такие же свойства безопасности.Из ваших комментариев я понимаю, что вы используете Linux;большая часть моего ответа относится к другим устройствам, но не к другим системам, таким как Windows.
Насколько я понимаю, вас беспокоят три сценария атаки:
- злоумышленник получает физический доступ к машине, выключает ее, вытаскивает диск и читает его содержимое для своего досуга.(Если злоумышленник может прочитать вашу оперативную память, вы уже потеряли ее.)
- Злоумышленник может запустить код на компьютере как пользователь.
- Ошибка в сценариях CGI позволяет процессучитать временные файлы, созданные другими процессами.
Первый тип злоумышленника может прочитать все, что не зашифровано на диске, и все, что зашифровано с ключом, которого у нее нет .
То, что может сделать злоумышленник второго типа, зависит от того, сможет ли он запустить код под тем же пользователем, который выполняет ваши CGI-скрипты.
Если он может запускать код только как другие пользователи, тогда инструментдля защиты файлов есть разрешения .У вас должен быть каталог с режимом 700 (= drwx------), то есть доступный только пользователю и принадлежащий пользователю, выполняющему сценарии CGI.Другие пользователи не смогут получить доступ к файлам в этом каталоге.Вам не нужно никакого дополнительного шифрования или другой защиты.
Если она может запускать код в качестве пользователя CGI (который, конечно, включает в себя запуск кода от имени root), то вы уже потеряли.Вы можете увидеть память другого процесса, если запускаете код от имени того же пользователя - отладчики делают это постоянно!Под Linux вы можете легко увидеть это сами, исследуя /proc/$pid/mem.По сравнению с чтением файла чтение памяти процесса немного сложнее с технической точки зрения, но с точки зрения безопасности нет никакой разницы.
Таким образом, наличие данных в файлах само по себе не является проблемой безопасности .
Давайте теперь рассмотрим третью проблему.Беспокойство заключается в том, что ошибка в CGI позволяет злоумышленнику отслеживать файлы, но не запускать произвольный код .Это связано с проблемой надежности - если процесс CGI умирает, он может оставить временные файлы.Но он более общий: файл может быть прочитан одновременно выполняющимся сценарием.
Лучший способ защититься от этого - вообще не хранить данные в файле.Это должно быть сделано на уровне PHP или его библиотек, и я не могу с этим поделать.Если это невозможно, то nullfs как , предложенный Филом Лелло , является разумным обходным решением: процесс PHP будет думать, что записывает данные в файл, нофайл никогда не будет содержать никаких данных.
Есть еще один распространенный трюк Unix, который может быть полезен здесь: после создания файла вы можете отсоединить (удалить) и продолжить работу сЭто.Как только он не связан, файл не может быть доступен по его прежнему имени, но данные остаются в файловой системе, пока файл открыт хотя бы в одном процессе.Тем не менее, это в основном полезно для надежности, чтобы заставить ОС удалять данные, когда процесс умирает по любой причине.Злоумышленник, который может открыть произвольные файлы с разрешениями процесса, может получить доступ к данным через /proc/$pid/fd/$fd.А у злоумышленника, который может открывать файлы в любое время, есть небольшое окно между созданием файла и его отменой связи: если он может открыть файл, он может наблюдать за данными, которые впоследствии добавляются к нему.Тем не менее, это может быть полезной защитой, поскольку она превращает атаку в чувствительную ко времени и может потребовать много одновременных подключений, поэтому может быть нейтрализована или, по крайней мере, значительно затруднена ограничителем скорости соединения.