Начинаем в багбаунти: доступно об уязвимостях типа Broken Access Control
Привет, меня зовут Александр (aka bytehope). Прежде чем прийти к багхантингу, я пять лет занимался коммерческой разработкой. Однако меня всегда больше интересовал поиск уязвимостей, поэтому сейчас свое свободное время я провожу на площадках багбаунти.
Эту статью я решил посвятить уязвимостям, связанным с недостатками контроля прав (Broken Access Control). Вы узнаете, что это очень распространенный баг, который может проявляться самыми разными способами. Конечно, особый акцент будет сделан на практике: я покажу, как отловить четыре разных вида этой уязвимости в лабах Web Security Academy. Начнем с самых простых примеров, поэтому статья подойдет для начинающих охотников. Смело заглядывайте под кат!
Статью можно послушать, если удобнее — включайте видео.
Советую посмотреть и предыдущие выпуски, в которых ребята из комьюнити Standoff Bug Bounty вспоминают свои первые шаги в багхантинге. Если вы уже на пути за наградами, не пропустите статью Олега Уланова про поиск уязвимостей SSRF с кучей ссылок на полезные ресурсы и инструменты.
Кто сломал access control
Access control — это процесс принятия решения о предоставлении прав доступа. Иначе говоря, какие пользователи могут просматривать информацию или совершать определенные действия в системе.
Соответственно, Broken Access Control мы получаем, когда этот механизм сломан: доступ к данным и действиям получает кто попало. Например, кто-то просматривает ваши скрытые посты в соцсетях или добавляет цитаты Джейсона Стейтема в ваш профиль.
Подобные баги встречаются в веб-приложениях отнюдь не редко. В 2021 году Broken Access Control стала самой распространенной уязвимостью по версии Open Web Application Security Project (OWASP). Ее можно встретить в самых разных обличьях, сегодня же я буду рассказывать в основном про подвид, известный как Insecure Direct Object Reference, или IDOR.
Элементарная кража данных
Наш первый пример будет совсем элементарным: все-таки в багбаунти мы только начинаем. Он связан с использованием в качестве ID объекта целочисленных значений, которые довольно легко подобрать наугад или методом перебора, он же brute force.
Допустим, вы зарегистрировались на каком-то сайте и получили свои логин и пароль. После их ввода в URL страницы вы видите свой ID, веб-приложение включает его в запрос к базе данных и предоставляет вам доступ, например, к списку товаров в корзине или балансу.
Если вы можете вписать ID другого пользователя вместо своего и сайт на это дает вам доступ к чужим данным, значит, он уязвим к самой простой уязвимости типа IDOR. Вот как мы реализовали ее в нашей лабе.
Демонстрация решения
Победа над святым UUID
Попробуем усложнить задачу, ведь разработчики знают об опасности целочисленных ID и стараются их не использовать. Вместо этого они присваивают объектам UUID (он же GUID) — universally unique identifier, всемирно уникальный идентификатор. Главное его отличие состоит в том, что UUID невозможно получить методом перебора, поскольку он представляет собой 128-битный номер и состоит из 32 символов.
Некоторые разработчики останавливаются на этом и считают, что использование UUID само по себе гарантирует защиту. Однако, даже если мы не можем узнать его методом перебора, существуют другие лазейки.
Один из способов узнать UUID мы показали на примере второй лабы.
Демонстрация решения
Интересная особенность этой уязвимости заключается в том, что шанс раскрытия UUID повышается вместе с продолжительностью жизни веб-приложения. Со временем любой сервис обрастает новыми функциями, и разработчикам все труднее следить за тем, чтобы идентификатор нигде не засветился. Это тоже типичный пример некорректной проверки прав доступа.
Пока что бесплатный кейс
Следующий пример еще чуть более замысловатый и связан не с переходом на страницу или получением чужих данных, а с доступом к файлам. В этом случае веб-приложение ограничивает доступ к объекту, но не к самому вложению.
Представим себе сайт по продаже курсов или социальную сеть, где для просмотра каких-то фото или видео нужна подписка. Иногда такие приложения ограничивают доступ только к самому объекту, например посту, но не к вложению в нем, то есть файлу. В этом случае мы тоже имеем дело с IDOR. Пример реализации подобной уязвимости доступен ниже (пока что бесплатно!).
Демонстрация решения
Прыжок за привилегиями
Заключительный пример основан на уязвимости многоэтапных процессов приложений. По такому принципу работают многие площадки, например, при размещении рекламы:
Пользователь загружает объявление.
Отправляет на проверку администратору.
Получает одобрение и публикует пост.
Иными словами, пользователь не может перейти к заключительному шагу, минуя первые два. Некоторые разработчики слишком полагаются на эту логику и обеспечивают контроль доступа только на этапах 1 и 2. Соответственно, цель злоумышленника заключается в том, чтобы сразу перескочить к третьему действию.
Вот как это может быть реализовано на примере повышения привилегий.
Демонстрация решения
Итоги
Может показаться, что уязвимости типа Broken Access Control слишком элементарные и не представляют большой опасности. Однако мы убедились, что они очень распространены и позволяют как красть чужие данные, так и повышать привилегии в системе. Доступ хакера к панели администратора способен не только разорить любую рекламную компанию, но и стать началом более разрушительной атаки. Многие организации заинтересованы в устойчивости своего бизнеса и готовы платить за найденные баги. Поэтому поиск уязвимостей — это не только вклад в нашу общую безопасность, но и шанс неплохо заработать. Вливайтесь!
Полезные ссылки
Напоследок хочу поделиться с вами материалами и инструментами, которые помогут искать уязвимости типа Broken Access Control:
