Перезагружаем мозг. Продолжаем решать задачки по информационной безопасности web-серверов. Сегодня задачка с портала root-me.org, называется "API - Broken Access". За решение задачки дают 15 баллов, лёгкий уровень.
Забегая вперёд, оставляю подсказку. Сегодня мы встретимся с простой но опасной уязвимостью типа IDOR.
IDOR (Insecure Direct Object Reference, небезопасные прямые ссылки на объекты) — уязвимость, которая позволяет получить несанкционированный доступ к веб-страницам или файлам. Самый распространенный случай IDOR — когда злоумышленник перебирает предсказуемый идентификатор и получает доступ к чужим данным.
Читаем описание. История задачки:
Ваш друг разработал платформу для регистрации и создания приватных заметок. Всё работает через API. Перед тем как приступить к разработке фронтенда, друг попросил вас проверить что всё безопасно.
Т.е. у нас должно быть некое API, которое позволяет регистрироваться, логиниться, писать заметки, читать свои заметки. Как я понимаю, задача сводится к тому, чтобы прочитать чужую заметку. Это как раз и покажет то, что бэкэнд написан небезопасно.
Имеется ссылка на видеоролик, в котором как раз рассматриваются уязвимости API, однако, ролик на французском, не стал вникать.
Ссылки
Решение
Переходим на страницу задания:
http://challenge01.root-me.org:59088/
И мы сразу видим интерфейс Swagger.
Swagger — это фреймворк от компании SmartBear, который используется при тестировании RESTful API и проектировании интеграции веб-приложений.
Swagger позволяет:
- интерактивно просматривать спецификацию и отправлять запросы;
- генерировать документацию на основе существующего кода на основе Java Annotation;
- создавать клиентов для неё.
В визуальном веб-GUI Swagger можно:
- просмотреть типы поддерживаемых HTTP-методов и описание схемы используемых данных;
- протестировать их.
Имеется редактор, который позволяет специфицировать REST API, то есть получить документацию OpenAPI версии 3 в YAML или JSON форматах.
Т.е. предполагается, что мы можем найти уязвимость без использования каких-то сложных инструментов. По идее будет достаточно самого браузера.
Имеем четыре функции API:
- /api/signup — регистрация пользователя
- /api/login — вход в приложение
- /api/user — получение информации о пользователе
- /api/note — редактирование заметки
Давайте попробуем. Регистрируем нового пользователя, здесь же в GUI. Подставляем свой логин и пароль:
{
"username": "internet",
"password": "lab"
}
User created successfully.
Пользователь зарегистрирован. Мы видим путь, куда отправляется POST запрос и результат выполнения. Пока ничего опасного не видно.
Выполним вход.
{
"username": "internet",
"password": "lab"
}
Logged in successfully.
Тоже пока всё неплохо.
Попробуем отредактировать свою заметку. Судя по описанию, нам нужно просто отправить значение note.
{
"note": "Hello from internet-lab.ru!"
}
Отправляем. Note updated successfully.
Всё хорошо.
Прочитаем данные о своём пользователе.
И сразу замечаем интересную вещь: /api/user имеет параметр user_id. Странно, зачем он нам, если мы и так залогинены? Ладно, просто запомним. На вход ничего не подаём, просто выполняем запрос и получаем ответ.
{
"note": "Hello from internet-lab.ru!",
"userid": 5,
"username": "internet"
}
Получаем нашу заметку, имя и идентификатор пользователя. Идентификатор тут тоже не в тему, кстати, он представляет собой целое число и равен пяти. До этого я ещё сгенерировал несколько пользователей, идентификатор самого первого был 2. Значит, в системе есть ещё какой-то пользователь с идентификатором 1.
Ладно, возвращаемся к нашей функции /api/user и параметру user_id. Этот параметр имеет приписку (path). Т.е. он используется в пути. Давайте прочитаем свои данные напрямую:
http://challenge01.root-me.org:59088/api/user/5
И получаем тот же JSON. А в URL-то у нас идентификатор пользователя, подставим единицу:
http://challenge01.root-me.org:59088/api/user/1
Видим флаг. Ларчик просто открывался. Валидируем.
И зарабатываем 15 очков.
Безопасность
Уязвимость IDOR очень простая, но при этом весьма опасная. Она может привести к разным нежелательным последствиям:
- Разглашению конфиденциальной информации. Злоумышленник может получить доступ к личным данным пользователей, как в нашей задачке.
- Обходу аутентификации: можно получить доступ сразу ко всем учётным записям с этой уязвимостью.
- Изменению данных: редактируя вашу информацию, злоумышленник может использовать её в своих целях. Например, сменить ваши банковские данные на свои.
- Захвату учётной записи. В некоторых случаях таким способом можно увести аккаунты пользователей, например, изменить телефон или e-mail и восстановив пароль аккаунта. Или похитить деньги с баланса. Или ещё что-нибудь.
Даже если всё настроено безопасно, но имеется возможность получить доступ к данным по ссылке, злоумышленники могут путём перебора паролей вытащить всю базу данных пользователей. Неприятно. Ещё более неприятно если там окажутся персональные данные пользователей.
