Не спешите прокручивать мой пост - дело совсем не в коде, не в пороге вхождения, фреймворках или отсутствия обратной совместимости.
Я отношусь к PHP с той стороны, которая занята его размещением и безопасностью. Конечно, сейчас никаких трудов не составит запихнуть код с интерпретатором в контейнер, но вот безопасность...
Смотрите - каждый раз, когда вы обращаетесь к своему коду через веб-интерфейс, вы запускаете интерпретатор, который считывает все файлы и формирует ответ. В том числе и файл, где вы так заботливо указали доступы к своей базе данных. И не спешите шифровать его - ведь ключ для расшифровки вам тоже надо где-то брать, верно?
Я просто уже вижу, как воспользовавшись одной из уязвимостей старых версий, злой хаккер ломает ваше приложение на древнем PHP5. Ведь его уже никто не поддерживает, а перейти на новую версию вам мешает отсутствие обратной совместимости.
И вот злой хакер стягивает файл с доступами базы, радостно читает и ухмыляясь, запускает на выполнение запрос, который вытягивает ваш дам с базы и покорно отдает его злодею на растерзание.
И не беда, если у вам там обычный блог или сайт-визитка. А если интернет-магазин? А если финансовое приложение?
Только не говорите, что в финтехе нет PHP. Есть. Я лично видел.
molchanoviv
А причем тут php? В других языках что нет уязвимости в древних версиях? Или они не считывают файлы в том числе с конфигами при выполнении? И то что ты не позаботился хотя-бы о выносе критичных конфигов в переменные окружения это уж ты сам себе злобный буратино. Я уж не говорю что эти конфиги должны быть за пределами рабочей папки твоего вебсервера.
Andrey_Rogovsky Автор
Спасибо, теперь я вижу средний уровень понимания аудитории хабра.
Matisumi
Нет, это МЫ видим твой уровень понимания
Sabubu
Это никак не поможет. Если злоумышленник может выполнять свой PHP-код на сервере, он сможет прочесть переменные окружения.
Почему тут каждый второй пишет про переменные окружения? Это неудобный способ хранить конфиги. Его придумали не для безопасности, а для поддержки хостингов, где используется read-only файловая система, и контейнерных систем вроде докера.
Иметь обычный конфиг-файл гораздо удобнее, чем в неудобной админке хостинга вбивать руками переменные окружения (особенно если у вас их десятки). Конфиг-файл вы можете редактировать любым редактором, версионировать с помощью git. Можете коментировать. Конфиг-файл валидируется и при опечатке в имени параметра выдается ошибка. А вот переменные окружения никто не валидирует, опечатались в названии и это незаметно.
При использовании переменных окружения нужны дополнительные шаги, например, при открытии консоли надо импортировать эти переменные перед выполнением команд. Лишнее неудобство.
Да, я в курсе про env-файлы, но это скорее возврат к конфигам, только извратным способом: вы пишете конфиг, потом он превращается в переменные окружения, потом их парсит приложение. Уж лучше сразу использовать нормальные конфиги. (кстати, название файла .env тоже выбрано максимально по-дурацки: с точки в линуксе начинаются скрытые файлы).
Я не вижу плюсов у переменных окружения. Дурацкая идея, которую все слепо используют, не взвешивая плюсы и минусы.
Lure_of_Chaos
> кстати, название файла .env тоже выбрано максимально по-дурацки: с точки в линуксе начинаются скрытые файлы
Это не баг, это фича: веб-сервер даже при неправильной настройке скрытые файлы не отдаст в веб.
А вообще, нужно помнить, что конфиги конфигам рознь. Например, у нас на несколько серверов развернуто приложение. При этом начальная конфига (хост, логин, пароль к бд) задается именно через параметры запуска в сервисе, так очень удобно деплоить — кодовая база собирается без изменений, а стандартная конфига лежит частично в бд, частично в файле свойств. Кроме того, продакшн значения начальной конфиги не утекут случайно при неосторожном коммите (было у меня такое когда-то давно: чтобы протестить локально, внес в файл данные от пре-прода, и забыл)
И в целом, наверное, «переменные окружения» следует понимать как «внешняя конфига»: это как и сами environment variables, так и файл в $USER_HOME, так и какой-нибудь, простихосподи, jndi.
Так что, золотое правило здесь «не хранить все яйца в одной корзине»
anonymous
theRavel
Попробуйте например так: https://frederic-hemberger.de/notes/kubernetes/manage-secrets-with-sops/
symbix
Наличие конфига ничем не противоречит переменным среды.
Никто же не запрещает держать только необходмые значения, типа доступов к базе данных или JWT secret-а, в vault, и подгружать в конфиг из env, а остальное хранить напрямую в конфиге.
А read only файловая система и контейнеры это вообще уже де-факто стандарт. Тут дело не только и не столько в безопасности, сколько в масштабируемости (см. 12 Factor App).