[Информационная безопасность, Разработка веб-сайтов, PHP, Программирование] Слабые места PHP: думай как хакер
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Какие уязвимости можно найти в типичном PHP-проекте? Удивительно, но любые — от слабых мест и уязвимостей в коде никто не застрахован. Чем быстрее мы их найдем, тем меньше риск для компании. Но чем лучше будем понимать, как можно атаковать наше приложение и как взаимодействуют друг с другом наши фичи, тем легче будет защитить код еще на уровне разработки. Тем более, что в PHP есть свои специфичные уязвимости — те же type juggling, insecure deserialization и local file include.
Наиболее распространенные уязвимости из списка OWASP Top 10 (доля приложений)Чтобы повысить уровень безопасности кода, полезно думать как хакер и тестировщик одновременно, проверяя все возможные лазейки в коде. Сканеры уязвимостей, 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-инъекцию, то сейчас это уже гораздо реже происходит, обычно обнаруживаются более сложные баги и цепочки уязвимостей.
Доли сайтов с уязвимостями различной степени риска по версии OWASP— Пример цепочки можешь привести?— Например, приложение позволяет делать скриншоты веб-страниц: мы отправляем адрес страницы и в результате получаем картинку. Но при этом на сервере проверяется, что переданный нами адрес имеет домен 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), общайтесь с коллегами в чате.
===========
Источник:
habr.com
===========
Похожие новости:
- [Информационная безопасность, Сетевые технологии, Законодательство в IT, IT-компании] В Сети появился якобы список сервисов туннелирования трафика, для которых разработают меры блокировки
- [Информационная безопасность, Законодательство в IT, IT-компании] «Сбер» опроверг утечку данных 500 тыс. клиентов программы «СберПремьер»
- [Программирование, PowerShell, Разработка под Windows] Если вы пишете код в Windows, вы заслуживаете лучшего терминала (перевод)
- [Программирование, Разработка игр, DIY или Сделай сам, Игры и игровые приставки, Визуальное программирование] Признайтесь: вы в этом не ориентируетесь
- [Firefox, Информационная безопасность, Расширения для браузеров] Встроенная поддержка FTP будет удалена в Firefox 90
- [Разработка веб-сайтов, JavaScript, Совершенный код, Google Chrome] Почему консоль разработчика Chrome иногда лжет (перевод)
- [Разработка веб-сайтов, CSS, Совершенный код, HTML] Еще не используешь SVG фавиконки? (перевод)
- [Программирование, Научно-популярное] Языки программирования с однобуквенным названием (перевод)
- [Программирование, Совершенный код] Золотой век программирования окончен? (перевод)
- [Софт] Botfather: универсальный фреймворк для автоматизации
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_razrabotka_vebsajtov (Разработка веб-сайтов), #_php, #_programmirovanie (Программирование), #_php, #_php8, #_kiberbezopasnost (кибербезопасность), #_ujazvimosti (уязвимости), #_intervju (интервью), #_konferentsii (конференции), #_informatsionnaja_bezopasnost (информационная безопасность), #_hakery (хакеры), #_yiiframework, #_programmirovanie (программирование), #_blog_kompanii_konferentsii_olega_bunina_(ontiko) (
Блог компании Конференции Олега Бунина (Онтико)
), #_informatsionnaja_bezopasnost (
Информационная безопасность
), #_razrabotka_vebsajtov (
Разработка веб-сайтов
), #_php, #_programmirovanie (
Программирование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:30
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Какие уязвимости можно найти в типичном PHP-проекте? Удивительно, но любые — от слабых мест и уязвимостей в коде никто не застрахован. Чем быстрее мы их найдем, тем меньше риск для компании. Но чем лучше будем понимать, как можно атаковать наше приложение и как взаимодействуют друг с другом наши фичи, тем легче будет защитить код еще на уровне разработки. Тем более, что в PHP есть свои специфичные уязвимости — те же type juggling, insecure deserialization и local file include.  Наиболее распространенные уязвимости из списка OWASP Top 10 (доля приложений)Чтобы повысить уровень безопасности кода, полезно думать как хакер и тестировщик одновременно, проверяя все возможные лазейки в коде. Сканеры уязвимостей, 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-инъекцию, то сейчас это уже гораздо реже происходит, обычно обнаруживаются более сложные баги и цепочки уязвимостей.  Доли сайтов с уязвимостями различной степени риска по версии OWASP— Пример цепочки можешь привести?— Например, приложение позволяет делать скриншоты веб-страниц: мы отправляем адрес страницы и в результате получаем картинку. Но при этом на сервере проверяется, что переданный нами адрес имеет домен 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), общайтесь с коллегами в чате.
=========== Источник: habr.com =========== Похожие новости:
Блог компании Конференции Олега Бунина (Онтико) ), #_informatsionnaja_bezopasnost ( Информационная безопасность ), #_razrabotka_vebsajtov ( Разработка веб-сайтов ), #_php, #_programmirovanie ( Программирование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:30
Часовой пояс: UTC + 5