Какие уязвимости можно найти в типичном PHP-проекте? Удивительно, но любые — от слабых мест и уязвимостей в коде никто не застрахован. Чем быстрее мы их найдем, тем меньше риск для компании. Но чем лучше будем понимать, как можно атаковать наше приложение и как взаимодействуют друг с другом наши фичи, тем легче будет защитить код еще на уровне разработки. Тем более, что в PHP есть свои специфичные уязвимости — те же type juggling, insecure deserialization и local file include.
Чтобы повысить уровень безопасности кода, полезно думать как хакер и тестировщик одновременно, проверяя все возможные лазейки в коде. Сканеры уязвимостей, SSL-сертификаты, аудиты и прочие многочисленные инструменты защиты будут хорошим дополнением. О том, как всё это совместить, Антон Прохоров рассказал в нашем интервью. На конференции PHP Russia 2021 Антон представит в докладе уязвимости PHP-приложений и способы их эксплуатации.
— Антон, как ты вообще попал в такую интересную сферу, как безопасность?
— Еще в МИФИ на факультете информационной безопасности я увлекся практическими кейсами, а на старших курсах мы с однокурсниками стали бывать на профильных конференциях (Positive Hack Days, ZeroNights). А потом увидели финал соревнований CTF по практической информационной безопасности, заинтересовались и тоже создали команду для участия.
— Как ты встретился с PHP? И чем занимаешься сейчас?
— С PHP была связана моя первая работа — я разрабатывал модули для сайта на Drupal. Но безопасность не завязана на один язык программирования, поэтому и на соревнованиях они были совершенно разные — так что я никогда не был привязан ни к PHP, ни к другому конкретному языку. Участие в соревнованиях в итоге так меня увлекло, что я захотел работать в кибербезопасности — и так пришел в BI.ZONE.
— Что именно ты делаешь в BI.ZONE? Как участвуешь в анализе?
— BI.ZONE предлагает много разных услуг: анализ защищенности приложений, инфраструктуры, реагирование на инциденты безопасности, и еще множество всего. Я занимаюсь поиском уязвимостей в приложениях заказчиков, а также участвую в тестированиях на проникновение. В случае с приложениями, нам предоставляют доступ, исходный код, какие-то тестовые стенды, учетные записи. Мы всё это смотрим, стараясь обеспечить полное покрытие всех функций, и в конце выдаем отчет: какие уязвимости нашли, и как можно их исправить. При тестировании на проникновение заказчик дает нам большой список внешних ресурсов компании, мы анализируем их, пытаемся найти уязвимости и с помощью них проникнуть во внутреннюю сеть компании. В таких проектах мы не стараемся полностью все проверить, а ищем самые уязвимые сервисы и используем баги в них.
— И ты, помимо PHP, для каждого нового проекта изучаешь новый язык?
— Приходится. Конечно, не на том уровне, на котором его знают разработчики, но какие-то базовые штуки надо знать, чтобы просто понимать где что находится в коде. То есть, когда я вижу HTTP-запрос на сайте, я должен примерно представлять, где найти код, который обрабатывает этот запрос. Такие вещи нужно знать, как и какие-то уязвимые конструкции в каждом языке. Приходится, конечно, достаточно часто менять стек — сегодня ты с PHP разбираешься, завтра с .NET, послезавтра с Java, и т.д.
— Насколько больше или меньше уязвимостей у PHP по сравнению с другими языками? Какие они?
— Если говорить про интерпретатор языка и стандартные библиотеки, то так как они написаны на C, то в их коде часто обнаруживаются баги, связанные с управлением памятью и различными переполнениями, которые иногда могут приводить к уязвимостям. Больше их или меньше чем в интерпретаторах других языков — я не возьмусь сравнивать. Из примеров можно вспомнить уязвимость PHP-FPM и unserialize. Но это довольно редкие и специфичные случаи.
Что касается приложений, написанных на PHP, то тут, наверное, ответ простой. Если пишешь безопасно, то будет безопасно. Если программист в курсе обо всех нюансах языка, что-то читал о безопасной разработке и знает, какие уязвимости есть в PHP (и как их избежать) — его код, скорее всего, будет безопасным. Но это не зависит от конкретного языка. Просто в PHP исторически так сложилось, что нюансов много, и о них стоит знать.
— Например?
— Например, до 8 версии PHP, если при обращении к любому файлу использовать схему "phar://", интерпретатор будет воспринимать содержимое файла как Phar-архив: попытается найти в нем метаданные и десериализовать их. Если ваше приложение принимает от пользователей путь до файла и не проверяет схему, то это может в некоторых случаях привести к возможности исполнения произвольного кода на вашем сервере. Про такие нюансы я и хочу рассказать на конференции, показав примеры.
— Если в PHP таких нюансов много, можно ли сказать, что он в целом более уязвим, чем другие языки?
— Возможно, из-за того, что PHP в целом популярный язык, создается впечатление, что в приложениях, написанных на нем, уязвимостей больше. Но это, отчасти, обусловлено статистически: по различным данным около 50% сайтов из топ миллион используют PHP, никакой другой язык по этим показателям с ним не сравнится.
Также PHP имеет более низкий порог вхождения: не нужен никакой фреймворк, достаточно создать PHP файл и вот уже можно обрабатывать запросы и запрашивать данные из базы. Это привлекает большое количество разработчиков, многие из которых, не обладая достаточными знаниями в области безопасности, могут написать уязвимый код. В целом, из-за всего этого, наверное, и кажется, что уязвимостей в приложениях на PHP больше.
— По твоему опыту, насколько PHP-разработчики заботятся о безопасности?
— Я читаю, по большей части, только тот код, который нам предоставляют заказчики. И они уже, в основном, что-то знают о безопасности, раз хотят, чтобы их проверили. Но в целом мне кажется, что тенденция на более безопасный код. Если раньше еще можно было найти простейшую SQL-инъекцию, то сейчас это уже гораздо реже происходит, обычно обнаруживаются более сложные баги и цепочки уязвимостей.
— Пример цепочки можешь привести?
— Например, приложение позволяет делать скриншоты веб-страниц: мы отправляем адрес страницы и в результате получаем картинку. Но при этом на сервере проверяется, что переданный нами адрес имеет домен example.com. А теперь, предположим, что мы нашли на сайте example.com уязвимость Open Redirect, позволяющую сформировать ссылку с доменом example.com, которая при открытии будет перенаправляться на произвольный адрес, например, localhost. И вот у нас уже есть возможность делать скриншоты страниц с localhost.
— Что-то еще может помочь коду быть безопасным, кроме самообразования программистов?
— Здесь, наверное, ничего нового не скажу. Нужно, чтобы заказчики и разработчики заботились о безопасности еще на этапе проектирования приложения, чтобы тестирование безопасности было включено в жизненный цикл разработки ПО. Проверки безопасности нужно внедрять в процесс разработки новых фич, чтобы не было так, что разработали все приложение, а после этого провели только аудит. Безопасность — это все-таки процесс. Поэтому тестирование нужно проводить чаще и как можно раньше.
— То есть и после того, как сдали проект, нужно время от времени проводить тестирование?
— Да, можно добавить одну фичу и проверить ее — уязвимостей нет. Добавить другую, и там их нет. Но, возможно, комбинация этих фич может привнести какую-то уязвимость. Проверки — там, где это возможно — нужно автоматизировать, добавлять в CI/CD сканеры уязвимостей и т.п. И конечно, обучать разработчиков, рассказывать, как писать безопасный код. Все это в совокупности, я думаю, приведет к тому, что приложение будет безопаснее. Но это не я придумал, это известная вещь — Security Software Development Lifecycle.
— Можно ли полностью автоматизировать проверки по безопасности?
— Какие-то вещи — да, но не полностью и не всё. Мы, конечно, используем сканеры кода и подобные утилиты, но они несовершенны. Во-первых, у них очень много ложных срабатываний, как false positive, так и false negative — то есть они могут и найти то, что не является уязвимостью, и не найти какую-то уязвимость. Поэтому мы всегда проверяем его результаты — насколько это вообще уязвимость, и если уязвимость, то можно ли ее эксплуатировать.
А во-вторых, некоторые категории уязвимостей сканеры вообще не находят, и пока нет даже предпосылок, что это когда-нибудь произойдет. Это уязвимости, связанные с конкретной бизнес-логикой приложения. Например, в интернет-магазине есть процесс — пользователь кладет в корзину товар и оплачивает его. Только здесь может быть уже множество уязвимостей, которые не являются типовыми, вроде SQL-инъекций или XSS-атак. Это может быть, например, связано с передачей отрицательной суммы или неправильной обработкой скидок и т.п. Такое сканер пока что не может обнаружить, потому что здесь нужно знать контекст: что это за приложение и какие там могут быть угрозы. Таких вариантов может быть много и в других процессах — так что нам всегда найдется, что делать.
— То есть когда ты читаешь код, то проверяешь также все возможные варианты развития по какому-то процессу?
— Во-первых, я пользуюсь уже готовыми методологиями, вроде OWASP. Во-вторых, какие-то типовые атаки я уже знаю из опыта. Плюс я интересуюсь тем, что другие находят — так складывается мой справочник «Что еще можно проверить?» Да и в общем, да — я пытаюсь думать как злоумышленник.
— Если мы нашли уязвимость и хотим сообщить об этом, как заказчику наладить работу с такими сторонними исследователями безопасности?
— В первую очередь, нужно на видное место на сайте добавить контакты или форму для связи: чтобы человек мог обратиться по поводу уязвимости, и чтобы это можно было легко найти. Чтобы не приходилось писать на какой-нибудь ящик компании support@ или sales@ и пытаться связаться с разработчиками или безопасниками — это бывает и сложно, и долго.
А второе, если уже компания довольно большая и действительно думает о том, как сделать так, чтобы её продукты постоянно тестировали — можно использовать Bug Bounty платформы, те же Hackerone и Bugcrowd. Суть в том, что компания договаривается с платформой, оговаривает скоуп ресурсов, которые будут исследоваться, принимаемые уязвимости и вознаграждение за них. В Bug Bounty участвуют уже много российских компаний — Киви, Майл.ру, Яндекс. Можно посмотреть на их примере.
— Что не стоит делать в таких случаях при работе со сторонними исследователями?
— Я думаю, если вам написали, что у вас уязвимость, не стоит игнорировать такое сообщение. Лучше разобраться в проблеме и ответить.
— А правда ли, по твоему опыту, что простые уязвимости самые страшные, а сложные никому особо не нужны?
— Думаю, это не так, потому что обычно уязвимости оцениваются по тому, что с их помощью можно сделать. Например, с помощью уязвимости мы можем прочитать данные любого пользователя или получить исполнение команд на сервере и т.п. Чем больше потенциальный ущерб, который может принести эксплуатация уязвимости, тем она и ценнее, за нее больше заплатят на Bug Bounty. А уж сложная она или простая — это другое дело. Но, конечно, если она простая, то, возможно, больше людей ее могут найти. И она этим страшнее. Может быть, пока ее обрабатывали на платформе Bug Bounty, уже кто-то из злоумышленников научился ее эксплуатировать. Но в целом, я думаю, что важен именно ущерб от уязвимости, а не простота или сложность.
— То есть если большой ущерб ожидается от сложной уязвимости, ее все равно могут использовать?
— Да, конечно. Из последнего здесь можно привести в пример довольно сложную цепочку уязвимостей в Microsoft Exchange под названием Proxylogon, которая, как известно, эксплуатировалась злоумышленниками.
— А много ли тех, кто может самостоятельно найти новую уязвимость без использования готовых наборов или сканеров?
— Если имеется в виду новая уязвимость как класс, то, наверное, единицы. Мы обычно изучаем уже известные классы уязвимостей и применяем эти знания для анализа приложений заказчика. Если же под новой уязвимостью подразумевается просто уязвимость в каком-либо приложении, которую еще не находили, то в целом это как раз то, чем занимаются люди моей профессии.
— Какие уязвимости, найденные за твою практику, запомнились тебе больше всего?
— Наверное, здесь стоит упомянуть уязвимость, из-за которой я попал на PHP Russia. Я нашел цепочку гаджетов для десериализации в PHP, которая позволяет исполнять код, используя только классы фреймворка Yii2. Это в общем-то проблема не самого фреймворка, а приложения, которое его использует. Но если программисты в приложении десериализуют пользовательские данные, то используя только классы фреймворка, можно получить исполнение команд на их сервере.
Хоть это и не сильно относится к самому фреймворку, я все равно написал разработчикам. Меня порадовало, что откликнулись и исправили. Я как раз общался с Александром Макаровым, как одним из разработчиков фреймворка, и после того общения он пригласил меня выступить на конференции.
— На конференции ты собираешься рассказывать как раз о безопасности в коде. Можешь рассказать об этом подробней?
— Я расскажу о нюансах PHP, которые стоит учитывать, если мы хотим писать безопасный код. Это специфичные уязвимости конкретно для PHP, не для других языков. Например, в PHP нестрогая типизация, поэтому строки приводятся к числам, числа к строкам, и т.п. Это может вести к разным интересным уязвимостям при сравнении, так как иногда приведение типов происходит не самым очевидным образом. Расскажу и про другие классы уязвимостей, которые есть в PHP. Покажу на примере, как это эксплуатировать, чтобы разработчики знали, что такая конструкция уязвима, и не стоит так писать.
— А сам ты впервые выступаешь на конференциях, или у тебя уже есть опыт? Тебе нравится?
— Я выступал, но не очень много. Это довольно волнительно для меня. Но зато приходится более глубоко разбираться в теме, чтобы быть готовым к разным вопросам. Получается, что когда готовишься к выступлению, сам много всего нового узнаешь.
— И сам доклад получается по-настоящему классный.
— Надеюсь, это будет полезно тем, кто прослушает доклад.
PHP Russia 2021 пройдёт в гибридном формате —будет и офлайн, и онлайн. Онлайн-зрители смогут задавать вопросы спикерам в зале, принимать участие в дискуссиях и участвовать в активностях на стендах партнёров.
Мы с нетерпением ждём нашу встречу в офлайне 28 июня 2021 года. До 30 апреля стоимость очного участия составит 27 000 рублей
Подписывайтесь на наши соцсети, чтобы быть в курсе новостей (FB,VK,Telegram-канал,Twitter), общайтесь с коллегами в чате.
В статье использованы диаграммы «Наиболее распространенные уязвимости из списка OWASP Top 10 (доля приложений)» и «Доли сайтов с уязвимостями различной степени риска по версии OWASP» из исследования Positive Technologies.
