Boo🧨

Асап, так получилось, что я отсутствовал полтора года. Но вроде как, теперь есть вариант писать сюда. Пробуем новый, тестовый формат, где я описываю обезличенные случаи из своей практики AppSec.

В рамках такого формата, хотелось бы поговорить про самую частую уязвимость, которую я находил в своих проектах. Это broken access control.

Стоит отметить, что понятие уязвимости, которое может вписываться в эту категорию всегда будет разным. Так например одна уязвимость, которую можно "занести" на Bug Bounty и уяза, которую можно зарепортить во время тестирования безопасности сервиса - может иметь разную оценку по критичности.

Теперь когда с этим разобрались можно приступать к основной части.

По идее нарушенный контроль доступа или же B.A.C. (почти как ACAB) это уязвимость в веб-приложении которая позволяет злоумышленнику получить доступ к функциональности, для эксплуатации которой у него нет прав. Для этого очевидно, в приложении должна быть реализована ролевая модель. Или нет? Давайте разберем два случая. Когда она есть и когда ее нет.

В рамках тестирования сервиса X на Bug Bounty, удалось использовать уязвимость нарушенного контроля доступа чтобы запостить новость в афише от имени администратора, прикрепив туда изображение в формате svg, которое содержит в себе полезную нагрузку для триггера XSS уязвимости. Получается, что тут 2 проблемы. Это небезопасная загрузка файлов и IDOR. Если первая уяза совершенно не по теме, давайте разберемся с нашим контролем доступа.

В моем случае сервис посылал POST запрос на создание новости в афише. Изучив api, я смог посмотреть какие параметры передются в JSON через этот POST запрос и подметил для себя тот факт, что в запросе передаётся user id и другой параметр, который проверял прошла ли новость модерацию. Изменив user id на id администратора и исправив другой параметр с false на true, я получил IDOR на стероидах, который из-за отсутствия корректной валидации данных параметров со стороны обычного пользователя, без привилегий позволяет нам создать фейковую новость с кликбейтным названием, плюс ко всему еще и тригерит наш Stored XSS.

Если ролевая модель толком не реализована и сервис не позволяет нам работать через POST, PUT и PATCH запросы - имеет смысл провести разведку API для выявления "подозрительных ручек". Например сервис X не позволяет пользователям вносить изменения на стороне сервера, однако это еще не значит, что вектор нарушенного контроля доступа надо вычеркивать из флоу тестирования. В рамках тестирования, уязвимостью нарушенного контроля доступа может считаться страница, где производиться вход в админку, получаются данные дургих пользователей сервиса (критичность уязы в таком случае зависит от контекста приватности информации) или даже доступ в /metrics, где будут разглашены внутренние хосты и весь api.