Как стать автором
Обновить

Комментарии 20

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

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

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

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


Если мы можем видеть env переменные, то у нас сильно больше проблем, так как там данные доступа к БД и тому подобное)
Этого файла в принципе не должно быть на сервере.
А где он должен быть?

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


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

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

опять же в случае работы через переменные окружения не все фреймворки будут уязвимыми от утечки кэша. симфони например не кэширует env переменные при дампе кэша, насколько я знаю
Верно ответили ниже, следует устанавливать переменные окружения. Этот файл стоит использовать только для локальной разработки
А можно упоминание об этом где-нибудь в ларавель документации? Не вижу смысла не использовать этот файл на продакшне. Да, естественно, не хранить его в гите. Но тем не менее.
Пробежался по доке, не нашел. Был уверен, что это упоминание есть. Могу разве что вспомнить один из факторов 12factor приложений. Что, конечно, тоже не является истиной в последней инстанции.
Этого файла в принципе не должно быть на сервере.

Не давайте вредных советов — этого файла просто не должно быть в веб доступе.
Как я выше сказал, я был уверен, что это офф рекомендация. Для себя все же считаю, что лучше его вообще не помещать на сервер, а использовать переменные окружения.
Впрочем, убедиться, что он не доступен для веб-сервера, должно быть достаточно для большинства
Да и вредным этот совет можно назвать с большой натяжкой
Т.е. сначала делаем из сервера проходной двор, а потом обвиняем фреймворки в дырявости?
Большинство PHP фреймворков использует MVC — Model-View-Controller — концепцию

Поправка: не использует, а может использовать. Но как правило в админках, фронт обычно делается в рамках отдельных проектов на JS уже лет семь.


Одна возможна из-за того, что при эксплуатации XSS в тэге script в параметре language можно указать язык PHP, и тогда PHP-код, указанный внутри тэга, выполнится на сервере.

Что, простите?

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

v1ru55 pOmelchenko
Почему 7.2, если этот функционал был доступен только до версии 5.6 включительно, которая умерла в 2018 году окончательно, при этом тег по умолчанию включен не был, а включить его можно было даже тогда только самостоятельно?


Раньше была потенциально, но не из-за фреймворка, а из-за целенаправленных действий эникейщика для её включения. Естественно про неё знали люди, связанные с разработкой и администрированием, но не включали.

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


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


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


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


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

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