Перейти к основному содержанию

CTF — API - Broken Access

CTF

Перезагружаем мозг. Продолжаем решать задачки по информационной безопасности web-серверов. Сегодня задачка с портала root-me.org, называется "API - Broken Access". За решение задачки дают 15 баллов, лёгкий уровень.

ctf

Забегая вперёд, оставляю подсказку. Сегодня мы встретимся с простой но опасной уязвимостью типа IDOR.

IDOR (Insecure Direct Object Reference, небезопасные прямые ссылки на объекты) — уязвимость, которая позволяет получить несанкционированный доступ к веб-страницам или файлам. Самый распространенный случай IDOR — когда злоумышленник перебирает предсказуемый идентификатор и получает доступ к чужим данным.

Читаем описание. История задачки:

Ваш друг разработал платформу для регистрации и создания приватных заметок. Всё работает через API. Перед тем как приступить к разработке фронтенда, друг попросил вас проверить что всё безопасно.

Т.е. у нас должно быть некое API, которое позволяет регистрироваться, логиниться, писать заметки, читать свои заметки. Как я понимаю, задача сводится к тому, чтобы прочитать чужую заметку. Это как раз и покажет то, что бэкэнд написан небезопасно.

Имеется ссылка на видеоролик, в котором как раз рассматриваются уязвимости API, однако, ролик на французском, не стал вникать.

Ссылки

Решение

Переходим на страницу задания:

http://challenge01.root-me.org:59088/

ctf

И мы сразу видим интерфейс 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"
}

ctf

User created successfully.

ctf

Пользователь зарегистрирован. Мы видим путь, куда отправляется POST запрос и результат выполнения. Пока ничего опасного не видно.

Выполним вход.

{
  "username": "internet",
  "password": "lab"
}

Logged in successfully.

ctf

Тоже пока всё неплохо.

Попробуем отредактировать свою заметку. Судя по описанию, нам нужно просто отправить значение note.

{
  "note": "Hello from internet-lab.ru!"
}

ctf

Отправляем. Note updated successfully.

ctf

Всё хорошо.

Прочитаем данные о своём пользователе.

ctf

И сразу замечаем интересную вещь: /api/user имеет параметр user_id. Странно, зачем он нам, если мы и так залогинены? Ладно, просто запомним. На вход ничего не подаём, просто выполняем запрос и получаем ответ.

{
  "note": "Hello from internet-lab.ru!",
  "userid": 5,
  "username": "internet"
}

ctf

Получаем нашу заметку, имя и идентификатор пользователя. Идентификатор тут тоже не в тему, кстати, он представляет собой целое число и равен пяти. До этого я ещё сгенерировал несколько пользователей, идентификатор самого первого был 2. Значит, в системе есть ещё какой-то пользователь с идентификатором 1.

Ладно, возвращаемся к нашей функции /api/user и параметру user_id. Этот параметр имеет приписку (path). Т.е. он используется в пути. Давайте прочитаем свои данные напрямую:

http://challenge01.root-me.org:59088/api/user/5

ctf

И получаем тот же JSON. А в URL-то у нас идентификатор пользователя, подставим единицу:

http://challenge01.root-me.org:59088/api/user/1

ctf

Видим флаг. Ларчик просто открывался. Валидируем.

ctf

И зарабатываем 15 очков.

Безопасность

Уязвимость IDOR очень простая, но при этом весьма опасная. Она может привести к разным нежелательным последствиям:

  • Разглашению конфиденциальной информации. Злоумышленник может получить доступ к личным данным пользователей, как в нашей задачке.
  • Обходу аутентификации: можно получить доступ сразу ко всем учётным записям с этой уязвимостью.
  • Изменению данных: редактируя вашу информацию, злоумышленник может использовать её в своих целях. Например, сменить ваши банковские данные на свои.
  • Захвату учётной записи. В некоторых случаях таким способом можно увести аккаунты пользователей, например, изменить телефон или e-mail и восстановив пароль аккаунта. Или похитить деньги с баланса. Или ещё что-нибудь.

Даже если всё настроено безопасно, но имеется возможность получить доступ к данным по ссылке, злоумышленники могут путём перебора паролей вытащить всю базу данных пользователей. Неприятно. Ещё более неприятно если там окажутся персональные данные пользователей.

Теги

 

Похожие материалы

CTF — HTTP Improper redirect

Продолжаем решать задачки по информационной безопасности web-серверов. Сегодня задачка с портала root-me.org, называется "HTTP - Improper redirect". За решение задачки дают 15 баллов, чуть посложнее начального уровня.

Теги

CTF — GraphQL - Introspection

Доброго времени суток. Прошлой ночью решал очередную интересную задачку на информационную безопасность web-серверов. Задачка с портала root-me.org, называется "GraphQL - Introspection". За решение задачки дают 20 баллов, ближе к среднему уровню.

Теги