Русский
Русский
English
Статистика
Реклама

Yii 2

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

23.07.2020 08:17:50 | Автор: admin


10 июня компания Digital Security провела онлайн-встречу по информационной безопасности Digital Security ON AIR. Записи докладов можно посмотреть на Youtube-канале.


По материалам докладов мы выпустим цикл статей, и первая из них об уязвимостях PHP-фреймворков уже ждет под катом.


Что такое MVC


Большинство PHP фреймворков использует MVC Model-View-Controller концепцию разделения проекта на три отдельных компонента:


  • модели, отвечающие за данные;
  • представления, отвечающие за интерфейс;
  • контроллеры, отвечающие за логику.

image


Компоненты независимы друг от друга, то есть внесение изменений в один из них не затронет другие.


Полезные уязвимости в PHP


Итак, что же искать в типичном проекте, созданном на PHP-фреймворке? Искать нужно все! Как ни удивительно, встретить можно любую уязвимость, так как ответственность за безопасность лежит в большей степени на разработчике проекта. Прежде всего нужно проверить, не включен ли режим отладки (исследователю это будет на руку; но если вы забыли выключить его на своем сайте, то поспешите это сделать). Режим отладки сильно поможет как в дальнейшем поиске уязвимостей, так и в их эксплуатации. Кроме режима отладки в любом проекте на PHP обязательно используются операторы сравнения для описания логики приложения. И тут скрывается еще одна уязвимость, типичная для PHP.


Речь идет о type juggling. Она возникает, когда в коде используется оператор сравнения == вместо ===. Оператор сравнения == сравнивает объекты в PHP по-особому, предварительно преобразовывая типы данных, из-за чего логика при сравнении пользовательских данных может быть нарушена. Например, можно войти под учетной записью администратора, используя пароль null. Оператор сравнения === сравнивает объекты без преобразования типов, рекомендуется использовать его в качестве основного оператора сравнения. Примеры сравнения приведены в табличке ниже из доклада о type juggling от OWASP.



Рекомендую ознакомиться и с самим докладом, чтобы подробнее узнать об уязвимости.


Не менее распространенная уязвимость, из-за которой возможны большинство RCE, это десериализация потенциально опасных данных. Дело в том, что в PHP можно сериализовать любой объект преобразовать объект в строку, из которой его можно восстановить. Для восстановления строчку нужно десериализовать с помощью функции unserialize(). Уязвимость возникает, когда на вход этой функции подаются данные, контролируемые пользователем. Так он может собрать цепочку из классов, которые приведут к выполнению кода или чтению файлов на сервере. Тут стоит упомянуть phpggc сборник уже готовых гаджетов (gadgetchains, цепочек из классов) для популярных PHP-фреймворков. Узнать больше об эксплуатации десериализации можно из доклада Павла Топоркова.


Каждый фреймворк состоит из набора пакетов, которые нужно как-то компоновать. На помощь приходит Composer, управляющий всеми зависимостями, который используется во всех фреймворках и сильно упрощает жизнь: все зависимости прописаны в одном файле composer.json. Все зависимые пакеты можно проверить на уязвимости с помощью сайта snyk.io просто передав ему composer.json. Также можно проверить только PHP-уязвимости с помощью специального инструмента Security Checker.


Laravel


Перейдем к главному к анализу PHP-фреймворков. Самым популярным PHP-фреймворком считается Laravel: он очень простой и достаточно безопасный сам по себе. Вся его логика описана в контроллерах. Middleware находится рядом с контроллерами и нужна для проверки шаблонных условий: например, является ли пользователь администратором или является ли введенный e-mail валидным. Также middleware может лежать в kernel.php. Все маршруты лежат в одной папке. Web маршруты лежат в web.php, а api маршруты в api.php. Представления лежат в отдельной папке и обычно являются blade-шаблонами. Конфигурационный файл сайта находится в корне, в файле .env. В нем хранятся учетные данные от базы данных и APP_KEY, включается режим отладки и прописываются другие настройки сервера.


Всего было найдено четыре довольно критичных уязвимости в Laravel:


  • CVE-2017-9303 специфичная утечка учетных данных;
  • CVE-2017-16894 утечка файла .env через прямое обращение к нему (http://example.com/.env);
  • CVE-2018-6330 error-based SQLI в GET-параметре dhx_user (пример вызова версии базы данных представлен на рисунке ниже);
  • CVE-2018-15133 полноценная RCE через десериализацию хедера.

Рассмотрим возможность получения RCE.



В качестве примера был создан блог, уязвимый к этой CVE. Эксплуатация данной уязвимости возможна при соблюдении двух условий: нужно знать APP_KEY из .env, и сервер должен принимать POST-запросы. Если версия Laravel очень старая, то можно воспользоваться имеющейся уязвимостью CVE-2017-16894 и достать .env (http://example.com/.env). Второй способ вызвать ошибку, чтобы перейти в режим отладки, и из него получить необходимый APP_KEY. Далее генерируем заголовок со встроенной полезной нагрузкой. Если отправить POST запрос на сервер с таким заголовком, то полезная нагрузка десериализуется на сервере, что спровоцирует выполнение кода. В данном случае выполнится команда, которую мы первым аргументом передали в скрипт. Скрипт состоит из двух частей: скрипта подписи заголовка, доступного по ссылке, и phpggc-модуля, с помощью которого генерируется полезная нагрузка. Остается отправить POST-запрос с этим заголовком и получить результат выполнения команды на сервере.


Symfony


В PHP-фреймворке Symfony маршруты располагаются в директории config. Контроллеры находятся в директории src, представления в директории templates.


У Symfony на cvedetails можно найти наибольшее количество CVE по сравнению с другими фреймворками. Среди них есть и пара очень старых RCE. Одна возможна из-за того, что при эксплуатации XSS в тэге script в параметре language можно указать язык PHP, и тогда PHP-код, указанный внутри тэга, выполнится на сервере. Вторая RCE, еще более старая, позволяет поместить PHP-код в специально сконфигурированный yaml-файл. При парсинге yaml-файла PHP-код выполнится на сервере.


Интересна история с обходом аутентификации. Сразу оговоримся, что CVE 2016 и 2018 года относятся к одному и тому же модулю аутентификации через LDAP. В 2016 году обнаружили, что процесс аутентификации можно обойти, используя пустой пароль (CVE-2016-2403). Уязвимость исправили, но допустили ошибку.



В 2017 году в другом модуле аутентификации нашли ту же проблему (CVE-2017-11365). В этот раз действительно исправили: введенный пользователем пароль сверяется не только с пустой строкой, но и с null. Это необходимо, потому что в языке PHP null не считается за пустую строку.



В 2018 году все-таки нашли ошибку в исправлении 2016 года (да-да, и такое бывает), которая позволяла обойти аутентификацию с помощью null, и закрыли ее (CVE-2018-11407).



Вот так можно было 2 года обходить LDAP с помощью null.


За последний год нашли еще несколько разнообразных уязвимостей на любой вкус. Некоторые из них легко эксплуатировать, например, уязвимости, заключающиеся в возможности header injection. Другие например RCE эксплуатировать довольно-таки сложно. Они новые, и модулей для них в phpggc нет, а работать с классами во фреймворках надо уметь. Так что если встретились с Symfony, уязвимым к этим багам, желаю удачи :)


Yii


Перейдем к фреймворку Yii. У него все не так, как у других, поэтому рассмотрим его более внимательно.


В Yii помимо типичных для MVC моделей, представлений и контроллеров, есть виджеты, модули и фильтры. Модули это законченные приложения со своими данными, интерфейсами, логикой. В отличие от самих приложений, модули не могут быть развернуты отдельно: они должны находиться внутри приложений.



Фильтр та же middleware, которая используется для шаблонных действий. Например, чтобы проверить, является ли пользователь администратором или является ли введенный e-mail валидным. Виджеты служат для создания сложных настраиваемых элементов пользовательского интерфейса. Например, с помощью виджета можно сгенерировать интерфейс выбора дат. Кроме того, в Yii нет конкретного файла с маршрутами. Все дело в том, что он сам строит маршрутизацию внутри сайта, используя контроллеры и действия. Соответственно, нам нужно либо вручную искать все контроллеры и все действия, либо писать чудо-скрипт, который сгенерирует файлик с маршрутами.


Из уязвимостей следует отметить три CVE:


  • CVE-2014-4672 RCE, позволяющая выполнять любые PHP-методы;
  • CVE-2018-6010 утечка информации через ошибки;
  • CVE-2018-7269 SQLi.

Остановимся на первых двух поподробнее.



Утечка информации возникает, когда режим отладки выключен и исключения ловятся стандартной функцией. Так вышло, что при переходе на страницу About срабатывает исключение, режим отладки выключен, и мы не можем получить никакой дополнительной информации из этой ошибки. Но если на эту же страницу обратиться при помощи ajax-запроса, то внезапно мы получаем содержимое конфигурационного файла. Как же так? Все дело в том, что при ajax-запросе выдается сообщение, прописанное в исключении. Для наглядности мы поместили туда конфигурационный файл сайта. Однако, через такую уязвимость могут просочиться достаточно чувствительные данные (пароли или ключи), которые помогут при исследовании сайта.



Если вам повезло встретить проект, использующий Yii версии 1.1.14 и виджет CDetailView, в который передаются пользовательские данные, то вы сможете выполнять любой метод на сервере. На Github'е пишут, что таким образом можно выполнить любой PHP-файл в системе, но когда я попробовал это сделать, он не проходил условие, прописанное в функции run класса CDetailView, если не был явно подключен в коде.


$value=is_callable($attribute['value']) ? call_user_func($attribute['value'],$this->data) : $attribute['value'];

Так мы передаем название класса и метода в запросе и видим содержимое конфигурационного файла сайта при помощи заранее добавленной секретной функции. Это все происходит потому, что параметр value проверяется функцией is_callable(), и если результат сравнения положительный, то он вызывается функцией call_user_func().


CakePHP


Фреймворк CakePHP структурно мало чем отличается от Laravel. Понятно, где искать модели, представления и контроллеры.


В нем так бы и были только лишь древние уязвимости (CVE-2010-4335, CVE-2012-4399), если бы не недавняя CVE-2019-11458 на десериализацию, при помощи которой можно перезаписывать файлы на сервере. Гаджетов пока что нет, поэтому будем ждать обновления phpggc.


Codeigniter


И, наконец, Codeigniter. Структура приложения понятная, все компоненты находятся на своих местах.


Из интересных уязвимостей можно выделить две старых (CVE-2014-8684, CVE-2016-10131) и одну относительно новую (CVE-2017-1000247). Первая из них настолько старая, что для нее есть модуль для Metasploit. Вторая встречается не только в этом фреймворке, но и во многих других PHP-фреймворках и PHP-приложениях. Более свежая CVE 2017 года обычная header injection в функции set_status_header(). Рассмотрим поподробнее две старые уязвимости.



Первая уязвимость связана с сессией: зная ключ шифрования можно расшифровать cookie-файл и поставить себе права админа. Кроме того, можно загрузить полезную нагрузку, которая выполнится на сервере. Все это возможно из-за слабой криптографии (всего лишь XOR) и использования дефолтного ключа во многих проектах. В данном случае, эксплуатируя уязвимость, мы получаем права админа.



В этом примере рассмотрим вторую уязвимость в функции mail(). Она передает параметры в программу Sendmail, пятый аргумент которой опционален. Этим пятым аргументом в нее можно передать адрес отправителя, чтобы почтовый сервер получил сообщение об ошибке, если сообщение не будет доставлено. Но передает он его в Sendmail с помощью флага -f, благодаря чему можно вставить через пробел свои аргументы и получить RCE. Существует много техник эксплуатации, но обычно используется два основных метода. В первом случае при помощи флага -С (использовать другой конфигурационный файл) читаем содержимое любого файла на сервере; его можно сохранить в какой-нибудь файл при помощи флага -Х (записывать весь траффик). Это нужно для того, чтобы открыть файл напрямую через сайт, записав содержимое файла в корень веб-сервера. Во втором случае с помощью флага -OQueueDirectory перемещаем письмо в очередь в указанную папку и сохраняем его полностью с PHP-кодом внутри тела письма. Далее выполняем его, например, добавив в корень веб-сервера.


Заключение


Подводя итог, стоит сказать, что PHP-фреймворки просты и лаконичны. Наиболее критичные уязвимости существуют в старых версиях фреймворков, так что необходимо регулярно обновлять их, иначе пентест продукта может сразу выявить парочку RCE. Я разобрал и перечислил далеко не все уязвимости, и далеко не во всех фреймворках. Кто знает, сколько еще удивительных уязвимостей они хранят в себе. Увлекательных пентестов!

Подробнее..

Новости Yii 2020, выпуск 7

12.11.2020 02:22:21 | Автор: admin

Новости Yii 2020, выпуск 7


Всем привет! Это очередной выпуск новостей Yii. Как обычно, в выпуске вас ждут релизы Yii 2, прогресс Yii 3, важные вести о Yii 1 и другие новости. Приятного чтения и будьте здоровы. Александр Макаров


Фонд


С прошлого выпуска пришлось прилично отвлечься на фонд, а именно на то, как средства перебрасываются из GitHub Sponsors в OpenCollective. С GitHub они уходили нормально, а вот куда большой вопрос. Потребовалось время, чтобы разобраться, но проблему удалось решить.


Ещё одна новость, частично связанная с фондом. Автор httpsoft/http-message, Евгений Зюбин, вероятно присоединится к команде фулл-тайм если/когда это позволит пополнение фонда. Если вы или ваша компания хотите получить Yii 3 раньше, можете помочь.


Инфраструктура


Мы постоянно улучшаем процесс тестирования пакетов:


  • В пакеты со стабильной версией добавлена проверка Roave backwards compatibility.
    Она проверяет что публичный API не сломан по-сравнению с предыдущим стабильным релизом.
  • Мы продолжили перевод тестов с Travis на GitHub actions как для Yii 2, так и для Yii 3. Actions классные, а Travis не так давно порезал поддержку OpenSource. Хорошо что мы начали переход заранее.
  • Мы решили не собирать покрытие кода через PHPUnit с последующей отсылкой его в Scrutinizer CI и теперь генерируем отчёт о покрытии средствами Scrutinizer. Это значительно быстрее, а результат тот же.
  • Отлично себя показал Psalm. Рекомендуем, в том числе, для ваших проектов.
  • В консоль GitHub actions теперь всё выводится в цвете. Выглядит значительно лучше!

Немного правок были сделаны на сайте. Прежде всего это переход на новый метод аутентификации GitHub API. Также был сделан ряд небольших улучшений фронтенда.


Патчи для совместимости с PHPUnit для Yii 2 и Yii 1 переехали в отдельный репозиторий. Если вдруг вам понадобится тестировать приложение на версиях PHP с 5.3 по 8, репозиторий будет определённо полезен.


Yii 1



Yii 2


Был выпущен Yii 2.0.39. В нём есть улучшения DI-контейнера и дополнительные исправления для работы с PHP 8.


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


Были выпущены новые версии следующих расширений:



Yii 3


С прошлого выпуска были сделаны следующие релизы:



На данный момент мы готовим пакеты из списка в карточке Trello.


Был принят ряд интересных решений:


  • Все стабильные релизы будут начинаться с версии 1.0.0. Ранее рассматривался вариант начинать с 3.0.0.
  • Пакеты Yii 3.0 буду поддерживать PHP 7.4.
  • В большинство пакетов добавлена конфигурация по-умолчанию. Они будут работать сразу после установки без дополнительной конфигурации или с очень минимальной конфигурацией.
  • Провайдеры конфигурации были удалены почти из всех пакетов и приложений.

В Trello есть доска с задачами, над которыми мы работаем, включая не отражённые в GitHub issue.


Почти каждый из пакетов был серьёзно почищен, получил совместимость с PHP 8 и исправления. Ниже представлено самое интересное.


Новые пакеты


Был создан ряд новых пакетов. Часть из них появились в результате выделения общего кода из других пакетов, а часть нет.



Инструменты для разработки


  • Были актуализированы зависимости и добавлен Dockerfile.
  • Реализована возможность полу-автоматического выпуска релизов.

Composer config plugin


Была добавлена временная поддержка PHP 8. Она не заменяет вариант с переписыванием плагина на AST и нужна для того, чтобы облегчить тестирование под PHP 8 в то время как мы занимаемся версией с AST.


Контейнер и фабрика



Кеш



Bulma


  • Больше документации, улучшено именование.
  • Добавлена возможность использовать значки в выпадающем меню.
  • Все виджеты сделаны иммутабельными.

Роутер


  • Внутренности и конфигурация упрощены путём выделения коллекции маршрутов в отдельный класс.
  • Метод UrlMatcherInterface::getLastMatchedRequest() удалён, добавлен getCurrentUri().
  • UrlMatcher теперь является опциональным, что хорошо сочетается с консольными приложениями.

Шаблоны приложений и демо


  • Больше не требуется NodeJs. Ресурсы забираются через asset packagist.
  • Конфиги значительно почищены. В app мы поделили их по разным пакетам.
  • Убрана ссылка контейнера на себя.
  • В yii-demo добавлен Swagger. Открывается через /swagger.
  • yii-demo подвергся рефакторингу.
  • Заменили в yii-demo реализацию PSR-7 на httpsoft/http-message.

Var dumper



Files



Cycle


  • В файловую схему теперь можно писать. Также в неё добавлена поддержка чтения из нескольких файлов.
  • Был задействованы наши DI контейнер / фабрика, так что интеграция с Cycle теперь работает на PHP 8.

Data



DBAL и ActiveRecord


Как DBAL, так и ActiveRecord, портированные с Yii 2, ещё рефакторить и рефакторить несмотря на то, что их серьёзно почистили и они, по большей части, работают.


Arrays



HTML



Debugger



Очереди



Translator


Пакеты i18n помечены как устаревшие, добавлены пакеты translator с новым дизайном.


Новая и изменённая документация



Рекомендации к чтению и другие новости



Спасибо!


Хочу сказать спасибо всем спонсорам и разработчикам, благодаря которым стала возможна разработка Yii 3. Вместе у нас всё получится.


Отдельное спасибо тем, кто помог Yii 3 кодом:


Подробнее..
Категории: Php , Framework , Yii , Php 8 , Yii 2 , Yii 3 , Phpunit

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru