Уязвимости PHP-фреймворков

[Demisang]

По поводу Yii неправильный тест, да там было отключено отображение ошибок в самом PHP, но константа

YII_DEBUG=true

Это видно по значку в правом нижнем углу экрана, а этот режим как раз и служит для отображения ошибок разработчику. В production всегда должно быть YII_DEBUG=false, и это уже ошибка разработчика если он такое допустил.

И ко всему тот, кто использует в PHP суперглобальный массив $_GLOBALS сразу теряется доверие, это никак не влияет на тест, но говорит о том, что человек не очень то разбирается в фреймворке, и возможно в PHP.

[v1ru55]

Вы безусловно правы, значок есть. Но вы же не видите исходный код приложения. А в исходном коде прописана как раз таки константа YII_DEBUG=false. Если бы она имела значение true, то сообщение об ошибке при запросе было бы подробным, а так просто выскакивает ошибка 500 без информации. Однако, также прописана константа YII_ENV=dev, она как раз таки и отрисовывет значок в правом нижнем углу. Демо версия показывает уязвимость так, как и должна. Тем более, уязвимость не была бы уязвимостью, если бы дело было в том, что в дебаг режиме отображаются ошибки :) Использование массива $_GLOBALS очень некрасиво, но зато понятно абсолютно всем, даже тем, кто не разбирается в PHP.

[negasus]

Аналогично и про Laravel, как я понимаю. Уязвимость получения .env файла мне кажется к фреймворку вообще отношения не имеет. Этого файла в принципе не должно быть на сервере.

нужно знать APP_KEY из .env

Если мы можем видеть env переменные, то у нас сильно больше проблем, так как там данные доступа к БД и тому подобное)

[pOmelchenko]

Нигде, эти «секреты» должны передаваться через переменные окружения, а потом конфиг должен быть закеширован в виде огромного массива со статическими значениями https://laravel.com/docs/7.x/configuration#configuration-caching

Насколько помню файлик будет лежать в bootstrap/cache

[pbatanov]

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

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

[negasus]

Верно ответили ниже, следует устанавливать переменные окружения. Этот файл стоит использовать только для локальной разработки

[negasus]

Пробежался по доке, не нашел. Был уверен, что это упоминание есть. Могу разве что вспомнить один из факторов 12factor приложений. Что, конечно, тоже не является истиной в последней инстанции.

[bgBrother]

Можете почитать обсуждение здесь → https://github.com/symfony/symfony/issues/25643.

[oz0ne]

Этого файла в принципе не должно быть на сервере.

Не давайте вредных советов — этого файла просто не должно быть в веб доступе.

[negasus]

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

[negasus]

Да и вредным этот совет можно назвать с большой натяжкой

[smykov03]

Мы можем видеть файл .env, только если настроен неправильно сервер…
Лично я храню проект, например в папке laravel, а рядом с этой папкой есть символическая ссылка с именем моего домена, которая указывает на laravel/public… Таким образом, к файлу env нет доступа, потому что он находится выше уровнем… Также нужно настроить права доступа…
Но этот подход я придумал из-за особенностей хостинга jino, на других хостингах можно найти более хорошее решения…

[Zezst]

Т.е. сначала делаем из сервера проходной двор, а потом обвиняем фреймворки в дырявости?

[pOmelchenko]

Наверное речь об этом: <script language="php">, на очень древних проектах, которые дешевле просто «похоронить как есть», чем как-то переностить на 7.2+ версии

[v1ru55]

Так и есть, речь идет о CVE-2015-2308.

[pOmelchenko]

Потому что 7.1 и старше уже официально не поддерживаются, при этом 7.2 хоть и получает патчи безопасности, но в ноябре и она тоже прекратит поддерживаться.

https://www.php.net/supported-versions.php

По этому, можно было бы сказать о том, что «проект дорого переводить на 7+», но в комментариях о проблемах безопасности лучше уточнять, как мне кажется, что если и переезжать, то на актуальные версии. Это то что касается самого языка.

А по поводу эникейщиков это да. Фрэймворк может быть и без уязвимостей. Но это никак не защитит от эникейщика который может целенаправленно, по не знанию, включать что-то что станет той самой дырой, через которую и получится нанести какой либо ущерб.

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