Всем привет. С вами супер игрок. Сегодня разберём прикольный плагин для Burp Suite — Autorize. Посмотрим, что он умеет, и заодно попробуем найти пару IDOR’ов в OWASP Juice Shop, чтобы не заскучать. Погнали!
Что такое Autorize?
На github’е написано так:
Как он работает?
На просторах интернета мне удалось найти вот такую схему. По ней можно отлично описать работу плагина.
От лица пентестера:
Интерфейс
Процесс установки пропустим — с этим любой школьник разберётся за пять минут. А вот про интерфейс пару слов скажу:
Для новичков интерфейс может показаться чутка стрёмным, но не парьтесь! Большинство функций вы, скорее всего, не будете использовать. Вот самая главная часть интерфейса:
Тут всё довольно просто, без заморочек. Есть офигенно полезная вкладка — Interception Filters. На GitHub про неё пишут так:
Как показано выше, я настроил плагин так, чтобы он перехватывал все URL, в которых НЕТ socket.io — и это реально удобно. Есть ещё другие вкладки в интерфейсе, но, если честно, я ими никогда не пользовался, так что разбирайтесь с ними сами, если любопытно. А теперь давай к самому вкусному — к практике
У меня заготовлено два аккаунта для теста. Запросы от одного в Burp Suite, во вкладке HTTP History, будут подсвечиваться красным, а от второго — фиолетовым. Оба аккаунта — обычные юзеры с одинаковыми правами, ничего особенного. Давай возьмём куки фиолетового юзера и кинем их в плагин Autorize.
В нашем случае у нас два заголовка для авторизации. Но, честно говоря, на практике, редко когда для сессии используют сразу пару заголовков — обычно разработчики используют только Cookie. Добавляем эти два заголовка в плагин Autorize: одна строка — один заголовок
Теперь берём нашего красного юзера и от его имени пишем комментарий к товару, а потом кидаем этот товар в корзину. Всё по классике, просто пользуемся интерфейсом
Вот что мы видим в плагине. Давай разберёмся с этой цветовой палитрой, чтобы всё было по полочкам:
Если взять этот запрос, вот что мы увидим:
Я поменял ID корзины с 9 на 1, и, о чудо, уязвимость реально есть! Давай по-быстрому разберём ещё пару запросов. Смотрим на запрос №8:
Тут мы можем заглянуть, что лежит в корзинах других юзеров.
Запрос под номером 4:
В запросе №4 мы можем писать комменты от имени любого юзера. Ну, это уже прям баг с большой буквы
На этом у меня всё. Думаю, интересная статейка получилась. Зацените заодно мои прошлые статьи. Всем добра
Что такое Autorize?
На github’е написано так:
Ну, в целом, звучит понятно, правда? Я вот тоже так думаю. Добавить нечего
Как он работает?
На просторах интернета мне удалось найти вот такую схему. По ней можно отлично описать работу плагина.
От лица пентестера:
- 1. Логинимся как юзер А. Заходим на сайт, получаем сессию первого пользователя.
- 2. Кидаем заголовки в плагин. Берём все заголовки, которые отвечают за авторизацию: Cookie, Authorization, какие-то кастомные штуки — всё, что может пригодиться.
- 3. Открываем новый браузер или режим инкогнито и логинимся как юзер B. Это наш второй тестовый юзер.
- 4. Тестим CRUD-операции от имени юзера B. Ну, то есть, серфим сайт, тыкаем кнопки, особенно там, где могут прятаться баги авторизации или контроля доступа (например, изменение профиля, доступ к чужим данным и т.д.).
- 4.1: Отправляет оригинальный запрос юзера B. Плагин шлёт запрос с заголовками юзера B (те самые куки и прочее, что вы указали).
- 4.2: Отправляет изменённый запрос. Здесь заголовки юзера B заменяются на заголовки юзера A. Проверяем, а не даст ли сайт доступ к чему-то, чего юзер B видеть не должен.
- 4.3: Отправляет запрос без заголовков. Это чтобы проверить, может даже без авторизации можно получить доступ к чувствительным данным. Ну тут понятно.
Интерфейс
Процесс установки пропустим — с этим любой школьник разберётся за пять минут. А вот про интерфейс пару слов скажу:
Для новичков интерфейс может показаться чутка стрёмным, но не парьтесь! Большинство функций вы, скорее всего, не будете использовать. Вот самая главная часть интерфейса:
Тут всё довольно просто, без заморочек. Есть офигенно полезная вкладка — Interception Filters. На GitHub про неё пишут так:
Вот таким вот образом:
Как показано выше, я настроил плагин так, чтобы он перехватывал все URL, в которых НЕТ socket.io — и это реально удобно. Есть ещё другие вкладки в интерфейсе, но, если честно, я ими никогда не пользовался, так что разбирайтесь с ними сами, если любопытно. А теперь давай к самому вкусному — к практике
У меня заготовлено два аккаунта для теста. Запросы от одного в Burp Suite, во вкладке HTTP History, будут подсвечиваться красным, а от второго — фиолетовым. Оба аккаунта — обычные юзеры с одинаковыми правами, ничего особенного. Давай возьмём куки фиолетового юзера и кинем их в плагин Autorize.
В нашем случае у нас два заголовка для авторизации. Но, честно говоря, на практике, редко когда для сессии используют сразу пару заголовков — обычно разработчики используют только Cookie. Добавляем эти два заголовка в плагин Autorize: одна строка — один заголовок
Теперь берём нашего красного юзера и от его имени пишем комментарий к товару, а потом кидаем этот товар в корзину. Всё по классике, просто пользуемся интерфейсом
Вот что мы видим в плагине. Давай разберёмся с этой цветовой палитрой, чтобы всё было по полочкам:
- Bypassed! (красный) — пахнет багом! Может быть False Positive, а может и нет — тут уже вам копать.
- Enforced! (зелёный) — всё чисто, бага нет.
- Is enforced??? (оранжевый) — плагин в раздумьях, баг или не баг. Придётся вам самим оценить ситуацию.
Если взять этот запрос, вот что мы увидим:
- Если вы аутентифицированный юзер — пахнет багом!
- Если вы неаутентифицированный юзер — бага нет, всё чисто.
Я поменял ID корзины с 9 на 1, и, о чудо, уязвимость реально есть! Давай по-быстрому разберём ещё пару запросов. Смотрим на запрос №8:
Тут мы можем заглянуть, что лежит в корзинах других юзеров.
Запрос под номером 4:
В запросе №4 мы можем писать комменты от имени любого юзера. Ну, это уже прям баг с большой буквы
На этом у меня всё. Думаю, интересная статейка получилась. Зацените заодно мои прошлые статьи. Всем добра
