Уязвимости API в новой оболочке

Сегодня речь пойдет об условно новой подборке от OWASP. В наше время API стали неотъемлемой частью современных приложений, и их роль с течением времени только увеличивается. Однако, как и во многих других сферах, технологические новшества продвигаются вперед намного быстрее, чем осознание важности обеспечения их безопасности. Именно поэтому мы считаем необходимым продолжать активно работать над повышением уровня осведомленности о распространенных уязвимостях в сфере безопасности API.

Этот документ о безопасности API был опубликован впервые в 2019 году. С тех пор индустрия безопасности API стала более зрелой и развитой. Мы считаем, что этот документ положительно внёс вклад в индустрию, так как он быстро стал эталоном в этой области.

Оглавление

1. Настройка лаборатории
2. OWASP API Security Top 10
1. API1:2023 Broken Object Level Authorization
2. API2:2023 Broken Authentication
3. API3:2023 Broken Object Property Level Authorization
4. API4:2023 Unrestricted Resource Consumption
5. API5:2023 Broken Function Level Authorization
6. API6:2023 Unrestricted Access to Sensitive Business Flows
7. API7:2023 Server Side Request Forgery
8. API8:2023 Security Misconfiguration
9. API9:2023 Improper Inventory Management
10. API10:2023 Unsafe Consumption of APIs
3. Отступление для разъяснений

Настройка лаборатории:

• Скачайте коллекцию Postman и файл среды (environment) vAPI из общедоступного рабочего пространства vAPI.

• Перейдите в Postman и импортируйте коллекции.

• Настройте переменные для коллекции.

OWASP API Security Top 10

API1:2023 Broken Object Level Authorization

Для демонстрации этого примера мы попробуем получить доступ к данным других пользователей, изменив значение ID в Burp Suite.

Также давайте попробуем перейти к пользователю с ID 1, который, вероятно, представляет собой администратора.

Эти снимки экрана показывают, что мы можем просматривать данные других пользователей, к которым у нас нет авторизации, просто изменив значение ID. Это подтверждает уязвимость vAPI в отношении нарушения авторизации на уровне объекта.

Как предотвратить

1. Внедрите правильный механизм авторизации, который зависит от политик и иерархии пользователей.
2. Используйте механизм авторизации для проверки, имеет ли вошедший в систему пользователь доступ к выполнению запрошенного действия с записью в каждой функции, которая использует ввод от клиента для доступа к записи в базе данных.
3. Предпочтительно использовать случайные и непредсказуемые значения в качестве идентификаторов записей (GUID) вместо последовательных или простых чисел.
4. Напишите тесты для оценки уязвимости механизма авторизации. Не развертывайте изменения, которые могут вызвать сбои в тестах.

API2:2023 Broken Authentication

Для демонстрации этой уязвимости у нас нет начальной электронной почты или пароля, установленных во время создания пользователя. Поэтому мы произвольно вводим адрес электронной почты и пароль, отправляем запрос в Burp и затем отправляем запрос в инструмент Intruder.

Мы видим, что позиция для загрузки данных (payload position) уже установлена для электронной почты и пароля.

Кроме того, vAPI содержит список адресов электронной почты и соответствующих паролей, разделенных запятыми. В моем случае этот список находится по пути ~/lab/vapi/Resources/API2_CredentialStuffing/creds.csv. Поэтому я переместил его в каталог vAPI.

Мы также выбираем тип атаки "Pitchfork" в этом случае. Атака "Pitchfork" перебирает разные наборы данных для каждой определенной позиции. Поддерживаются одновременные варианты данных для каждой позиции. Общее количество запросов, создаваемых в ходе атаки, равно количеству данных в наименьшем наборе данных. Атака "Pitchfork" полезна, когда атака требует вставки разных, но связанных данных в несколько мест внутри запроса.

Затем мы загружаем файл creds.csv в качестве данных для атаки.

Для раздела обработки данных для атаки выберите опцию "Соответствие/замена" (Match/replace) и добавьте ,([^\s,]+) в поле "Соответствие" (Match regex), а в поле "Замена" (Replace) оставьте пустым. Для второго набора данных добавьте ([\w.-]+@[a-zA-Z\d.-]+.[a-zA-Z]{2,}) в поле "Соответствие" (Match) и также оставьте поле "Замена" пустым. Затем запустите атаку. Также не забудьте снять флажок "Кодировать символы в URL" (URL-encode these characters) для обоих позиций перед началом атаки.

Отсортируйте результаты в соответствии со статусом и просмотрите адрес электронной почты и пароль, где адрес электронной почты и пароль совпадают.

Используя учетные данные, мы можем получить токен, как показано ниже:

Также,

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

Как предотвратить

1. Убедитесь, что вы знаете все возможные способы аутентификации в API (мобильные/веб-ссылки, реализующие одноразовую аутентификацию и т. д.). Обсудите с инженерами, какие способы вы упустили.
2. Изучите ваши механизмы аутентификации. Убедитесь, что вы понимаете, что и как они используются. OAuth не является механизмом аутентификации, и таковыми не являются API-ключи.
3. Не изобретайте велосипед в вопросах аутентификации, генерации токенов или хранения паролей. Используйте стандарты.
4. Эндпоинты восстановления учетных данных/восстановления пароля должны рассматриваться как точки входа для аутентификации в терминах защиты от перебора, ограничения частоты запросов и блокировки.
5. Требуйте повторной аутентификации для выполнения чувствительных операций (например, изменение адреса электронной почты владельца учетной записи/номера телефона для двухфакторной аутентификации).
6. Используйте OWASP Authentication Cheatsheet (шпаргалку по аутентификации OWASP).
7. При возможности реализуйте многофакторную аутентификацию.
8. Внедрите механизмы борьбы с перебором, чтобы предотвратить атаки на перебор учетных данных, словарные атаки и атаки перебором на ваших конечных точках аутентификации. Этот механизм должен быть строже, чем обычные механизмы ограничения частоты запросов в ваших API.
9. Реализуйте механизмы блокировки аккаунта/капчи, чтобы предотвратить атаки перебором для конкретных пользователей. Реализуйте проверку на слабые пароли.
10. API-ключи не должны использоваться для аутентификации пользователей. Они должны использоваться только для аутентификации клиентов API.

API3:2023 Broken Object Property Level Authorization

Нарушение уровня авторизации свойств объекта (Broken object property level authorization) относится к уязвимости в безопасности API, при которой управление доступом к отдельным свойствам объекта недостаточно или некорректно применяется. Другими словами, это означает, что API позволяет несанкционированным пользователям получать доступ к определенным чувствительным или приватным свойствам объекта, которые должны быть доступны только определенным пользователям или ролям.

Эта категория объединяет API3:2019 - Избыточное раскрытие данных и API6:2019 - Массовое присвоение, сосредотачивая внимание на корневой причине: отсутствии или неправильной проверке авторизации на уровне свойств объекта. Это приводит к раскрытию или манипулированию информацией со стороны несанкционированных лиц.

Давайте сначала создадим пользователя и попробуем получить информацию о созданном пользователе.

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

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

В контексте API объект - это структура данных, которая содержит различные свойства или атрибуты. В данном случае "кредит" - это свойство пользователя, которое не должно было редактироваться самим пользователем, но здесь пользователь может определить свойство и установить ему значение при создании пользователя. Уровень авторизации должен был обеспечить, чтобы пользователи имели доступ только к тем свойствам, к которым им разрешен доступ, но в данном случае пользователь смог успешно просматривать кредит при получении данных о пользователе и редактировать его. В результате пользователь смог успешно изменить это свойство и увеличить свой кредит.

Как предотвратить

1. При предоставлении доступа к объекту через конечную точку API всегда убедитесь, что пользователь имеет доступ к свойствам объекта, которые вы разглашаете.
2. Избегайте использования общих методов, таких как to_json() и to_string(). Вместо этого выбирайте конкретные свойства объекта, которые вы хотите вернуть.
3. При возможности избегайте использования функций, которые автоматически связывают входные данные клиента с переменными кода, внутренними объектами или свойствами объекта ("Mass Assignment").
4. Разрешайте изменения только свойствам объекта, которые должны обновляться клиентом.
5. Реализуйте механизм валидации ответа на основе схемы как дополнительный уровень безопасности. В рамках этого механизма определите и обеспечьте возврат данных всеми методами API.
6. Сократите структуры возвращаемых данных до минимума, в соответствии с бизнес-функциональными требованиями для конечной точки.

API4:2023 Unrestricted Resource Consumption

Для демонстрации этой уязвимости перейдите к API4 в коллекции, и мы попробуем запросить отправку ОТР-кода на мобильный телефон. Это войдет в учетную запись пользователя, чей номер мобильного телефона мы предоставили. В теле ответа мы видим, что на устройство этого пользователя был отправлен 4-значный код. Поскольку у нас нет доступа к устройству пользователя, у нас нет ОТР-кода.

Но мы можем обойти это с помощью Burp, чтобы получить ОТР-код.

Однако, просматривая ответ на запрос, мы видим, что ОТР-код недействителен.

Теперь мы должны попробовать провести фаззинг с помощью Intruder-а.

Теперь мы выбираем атаку Snipper и редактируем раздел с данными payloads, как показано ниже:

Теперь мы запускаем атаку и ожидаем ответа, в котором OTP дает статус 200.

Теперь мы возвращаемся в Postman и выбираем запрос "Get Details" из списка. Вставляем найденное выше значение ключа в поле "Authorization Token" и отправляем запрос.

Приложение должно иметь какое-то ограничение, которое бы остановило нас от отправки тысяч запросов для поиска ОТР-кода, который соответствует. Это доказывает, что vAPI уязвим для неограниченного потребления ресурсов.

Эксплуатация подобной уязвимости может привести к DoS из-за истощения ресурсов, а также к увеличению операционных затрат, таких как затраты на инфраструктуру из-за повышенного спроса на CPU, увеличения потребности в облачном хранилище и так далее.

Как предотвратить

1. Используйте решение, которое упрощает ограничение потребления памяти, CPU, количества перезапусков, дескрипторов файлов и процессов, такие как контейнеры или серверный код без сервера (например, Lambda-функции).
2. Определите и обеспечьте максимальный размер данных для всех входных параметров и полезных нагрузок, такой как максимальная длина строк, максимальное количество элементов в массивах и максимальный размер загружаемого файла (независимо от того, хранится ли он локально или в облачном хранилище).
3. Реализуйте ограничение на частоту взаимодействия клиента с API в заданный промежуток времени (ограничение частоты).
4. Настройте ограничение частоты в соответствии с бизнес-потребностями. Некоторые конечные точки API могут потребовать более строгих политик.
5. Ограничивайте, сколько раз или как часто один клиент/пользователь API может выполнять одну операцию (например, проверку OTP или запрос восстановления пароля без посещения одноразового URL).
6. Добавьте должную серверную проверку параметров строки запроса и тела запроса, в частности тех, которые управляют количеством записей, возвращаемых в ответе.
7. Настройте ограничения расходов для всех поставщиков услуг/API-интеграций. Если установка ограничений расходов невозможна, настройте оповещения о биллинге.

API5:2023 Broken Function Level Authorization

Для начала создадим пользователя и попробуем получить его данные.

Для демонстрации этой уязвимости мы попробуем получить сведения об администраторе, угадывая несколько конечных точек. Вот некоторые из конечных точек, которые я попытался угадать.

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

Как предотвратить

1. Ваше приложение должно иметь последовательный и легко анализируемый модуль авторизации, который вызывается из всех ваших бизнес-функций. Часто такая защита предоставляется одним или несколькими компонентами, находящимися за пределами кода приложения.
2. Механизм(ы) обеспечения должны по умолчанию отклонять все запросы, требуя явного предоставления разрешений для конкретных ролей на доступ к каждой функции.
3. Проверьте ваши конечные точки API на наличие уязвимостей уровня функции авторизации, учитывая бизнес-логику приложения и иерархию групп.
4. Убедитесь, что все ваши административные контроллеры наследуют от административного абстрактного контроллера, который реализует проверки авторизации на основе группы/роли пользователя.
5. Убедитесь, что административные функции внутри обычного контроллера реализуют проверки авторизации на основе группы и роли пользователя.

API6:2023 Unrestricted Access to Sensitive Business Flows

Эта уязвимость не может быть эксплуатирована в лабораторных условиях. Поэтому я просто попробую объяснить это простыми словами.

Последствия этой уязвимости могут быть значительными и разнообразными. Поскольку злоумышленники могут получить доступ к чувствительным бизнес-потокам, они могут использовать их таким образом, что это наносит ущерб бизнесу. Распространенность этой проблемы считается "широкой", что означает, что это общая проблема, с которой сталкиваются многие API. Обнаружимость этой уязвимости оценивается как "средняя", что указывает на то, что она может не быть сразу очевидной или легко идентифицируемой.

Когда злоумышленники эксплуатируют эту уязвимость, им typically нужно понимать бизнес-модель, поддерживаемую API. Затем они выявляют чувствительные бизнес-потоки и автоматизируют доступ к ним, нанося ущерб бизнесу. Отсутствие всестороннего понимания бизнес-требований API способствует распространенности этой уязвимости, так как разработчики могут не полностью понимать последствия разглашения чувствительных потоков.

Что касается влияния на бизнес, эксплуатация этой уязвимости может повредить организацию разными способами. Например:

• Предотвращение законных пользователей от покупки продукта: Злоумышленники могут манипулировать чувствительным бизнес-потоком, связанным с покупками, что может вызвать сбои в процессе покупки для настоящих клиентов и потенциальные потери доходов для бизнеса.
• 
  Инфляция внутренней экономики игры: Если API связан с игровой платформой, злоумышленники могут использовать чувствительные потоки для создания искусственных ресурсов или игровой валюты, что вызовет дисбаланс в экономике игры и негативно повлияет на игровой опыт других пользователей.

Как предотвратить

Планирование мер по смягчению должно выполняться на двух уровнях:

1. Бизнес — определение бизнес-процессов, которые могут нанести ущерб бизнесу, если их будут чрезмерно использовать.
2. Инженерное — выбор правильных механизмов защиты для смягчения бизнес-риска.

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

• Идентификация устройства: отказ в обслуживании неожидаемым клиентским устройствам (например, безголовым браузерам) склоняет злоумышленников использовать более сложные решения, что делает их более затратными.
• Обнаружение человека: использование CAPTCHA или более продвинутых биометрических решений (например, анализа структуры набора текста) для определения человека.
• Обнаружение нечеловеческих паттернов: анализ потока пользователя для обнаружения нечеловеческих паттернов (например, пользователь выполнил функции "добавить в корзину" и "завершить покупку" менее чем за одну секунду).
• Рассмотрите блокировку IP-адресов выходных узлов Tor и известных прокси-серверов.

Обеспечьте безопасность и ограничьте доступ к API, которые используются напрямую машинами (например, API разработчиков и B2B API). Они часто становятся легкой мишенью для атакующих, потому что часто не реализуют все необходимые механизмы защиты.

API7:2023 Server Side Request Forgery

Для этого перейдем в папку Arena и подпапку ServerSurfer, а затем отправим GET-запрос.

Здесь я попробовал переключиться наhttps://webhook.site. Здесь мы установим текст, который будет отправлен обратно, когда будет сделан запрос на определенный веб-адрес. Приложение vAPI отображает данные, возвращаемые любым URL, который мы устанавливаем в качестве значения GET-параметра в этом запросе. В данном случае это была просто строка. В другом сценарии это могло бы быть вредной нагрузкой. Это уязвимость SSRF.

Как предотвратить

• Изолируйте механизм получения ресурсов в вашей сети: обычно эти функции направлены на получение удаленных ресурсов, а не внутренних.
• Всякий раз, когда это возможно, используйте списки разрешенных элементов:
• Удаленные источники, с которых ожидается, что пользователи будут загружать ресурсы (например, Google Drive, Gravatar и т. д.).
• Схемы URL и порты.
• Принимаемые типы медиафайлов для конкретной функциональности.
• Отключите HTTP-перенаправления.
• Используйте хорошо протестированный и поддерживаемый парсер URL, чтобы избежать проблем, вызванных несогласованностью разбора URL.
• Проверяйте и очищайте все данные, предоставленные клиентом.
• Не отправляйте клиентам сырые ответы.

API8:2023 Security Misconfiguration

Мы заметим следующие заголовки ответа:

Access-Control-Allow-Origin: *

Access-Control-Allow-Credentials: true

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

Для демонстрации этого мы отправляем запрос в Repeater и добавляем пользовательский заголовок запроса Origin: request header.

Здесь наличие Origin: * (звёздочка) сделало эксплуатацию уязвимости легкой, так как мы можем использовать любой адрес сайта и отправить запрос. Это представляет собой нарушение конфигурации безопасности.

Как предотвратить

• Жизненный цикл API должен включать в себя:
• Повторяемый процесс закрепления, который приводит к быстрому и легкому развертыванию должной защищенной среды.
• Задачу по обзору и обновлению конфигураций во всем стеке API. Обзор должен включать в себя файлы оркестрации, компоненты API и облачные службы (например, разрешения для хранилища S3).
• Автоматизированный процесс для непрерывной оценки эффективности конфигурации и настроек во всех средах.
• Кроме того:
• Убедитесь, что всего API-коммуникации от клиента к серверу API и любых компонентов вниз и вверх происходит через зашифрованный канал связи (TLS), независимо от того, является ли это внутренним или общедоступным API.
• Уточните, какие HTTP-глаголы могут использоваться для доступа к каждому API, и отключите все остальные HTTP-глаголы (например, HEAD).
• API, ожидающие доступ из браузерных клиентов (например, веб-приложения на фронтенде), должны, по крайней мере:
• Реализовывать корректную политику Cross-Origin Resource Sharing (CORS).
• Включать соответствующие заголовки безопасности.
• Ограничивать входящие типы контента/форматы данных только теми, которые соответствуют бизнес- и функциональным требованиям.
• Убедитесь, что все серверы в цепочке HTTP-серверов (например, балансировщики нагрузки, обратные и прямые прокси-серверы и серверы внутренней части) обрабатывают входящие запросы единообразно, чтобы избежать проблем с несинхронизацией.
• При необходимости определите и обеспечьте соблюдение всех схем ответных данных API, включая ошибки, чтобы предотвратить отправку атакующим детализации ошибок и другой ценной информации.

API9:2023 Improper Inventory Management

Для демонстрации этой уязвимости мы переходим к API9 в коллекции, выполняем вход и отправляем запрос в Burp. Пересылая его в Repeater и просматривая ответ, мы видим, что API имеет ограничение на количество запросов в 5 и оставшийся лимит 4, что означает, что мы можем попытаться ввести PIN-код только 4 раза.

Попытка просмотра v1 API путем редактирования запроса дала мне данные предыдущей версии v2 API. Кроме того, в этом случае мы не видим ограничений по количеству запросов. Поэтому мы можем отправить столько запросов, сколько захотим для этого API. Для легкого перебора пин-кода в этом случае я использовал инструмент ffuf и этот словарь для предсказания пин-кода.

Результатом выполнения ffuf был пин-код '1655' с кодом состояния 200 в ответе. Позднее я попробовал использовать этот пин-код в запросе, в результате чего мне удалось получить доступ к данным пользователя.

vAPI уязвим для неправильной оценки инвентаря, так как разработчик API не управлял предыдущей версией API, и мы, как пользователи, можем получить к ней доступ и просматривать информацию.

Как предотвратить

• Создайте инвентаризацию всех хостов API и документируйте важные аспекты каждого из них, сосредотачиваясь на среде API (например, производственной, тестовой, разработке), кто должен иметь сетевой доступ к хосту (например, общедоступный, внутренний, партнеры) и версию API.
• Сделайте инвентаризацию интегрированных служб и документируйте важные аспекты, такие как их роль в системе, какие данные обмениваются (поток данных) и их чувствительность.
• Документируйте все аспекты вашего API, такие как аутентификация, ошибки, перенаправления, ограничение скорости, политика Cross-Origin Resource Sharing (CORS), и конечные точки, включая их параметры, запросы и ответы.
• Автоматизируйте генерацию документации, применяя открытые стандарты. Включите построение документации в ваш конвейер непрерывной интеграции/непрерывной доставки (CI/CD).
• Делайте документацию API доступной только для тех, кому разрешено использовать API.
• Используйте внешние средства защиты, такие как специализированные средства безопасности API, для всех выставленных версий ваших API, а не только для текущей версии в производстве.
• Избегайте использования производственных данных в непроизводственных развертываниях API. Если это невозможно, такие конечные точки должны получать такое же обращение в плане безопасности, как и производственные.
• Когда новые версии API включают улучшения в безопасности, проводите анализ рисков, чтобы определить меры по их минимизации, необходимые для более старых версий. Например, возможно ли применить улучшения без нарушения совместимости API или требуется либо быстро убрать старую версию, либо заставить всех клиентов перейти на последнюю версию.

API10:2023 Unsafe Consumption of APIs

Это относится к небезопасной интеграции и использованию API, особенно при взаимодействии с API сторонних поставщиков. Чтобы эффективно проверить и продемонстрировать эту уязвимость, было бы идеально иметь доступ к API стороннего поставщика, о котором известно, что в нем есть некоторые уязвимости или нарушения конфигурации безопасности.

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

Основной уязвимостью в целевом API является то, что разработчики часто доверяют и не проводят тщательной проверки конечных точек, взаимодействующих с внешними или сторонними API. Это доверие основано на предположении, что у внешних API есть достаточные меры безопасности, такие как транспортная безопасность (шифрование), механизмы аутентификации/авторизации и проверка и очистка входных данных. Однако это доверие может привести к игнорированию потенциальных уязвимостей в этих интегрированных API или службах. Последствия этой уязвимости могут быть серьезными и разнообразными. Если злоумышленник успешно эксплуатирует эту слабость, он может получить несанкционированный доступ к чувствительной информации, которую целевое API извлекает из скомпрометированных внешних API или служб. Это может привести к утечкам данных и разглашению конфиденциальной информации.

Кроме того, злоумышленник может проводить различные виды атак внедрения на целевое API через скомпрометированные внешние API. Атаки внедрения могут включать в себя SQL-инъекции, инъекции команд или другие формы уязвимостей выполнения кода, которые могут привести к несанкционированному управлению целевым API или даже сервером, на котором оно работает. Кроме того, злоумышленники могут предпринимать атаки отказа в обслуживании (DoS) против целевого API, манипулируя или нарушая поток данных от скомпрометированных внешних API, что влияет на доступность и надежность услуг целевого API.

Как предотвратить

• При оценке поставщиков услуг оцените их уровень безопасности API.
• Гарантируйте, что все взаимодействия с API происходят через безопасный канал связи (TLS).
• Всегда проверяйте и правильно очищайте данные, полученные от интегрированных API, перед использованием.
• Ведите разрешенный список известных мест, куда могут перенаправлять вас интегрированные API: не следуйте перенаправлениям слепо.

Отступление для разъяснений

В документе от OWASP по каждому риску/угрозе приводится подробная информация:

• Threat agents/Attack vectors - определение источника угрозы или вектора атаки
• Security Weakness - описание недостатков, которые могут быть использованы
• Impacts - предположения о возможном вреде, который может быть нанесен организации в результате реализации риска
• Is the API Vulnerable? - описание почему эта угроза актуальна для API
• Example Attack Scenarios - примеры атак
• How To Prevent - возможный набор практик и мер безопасности для CI/CD
• References - ссылки на подобные уязвимости, утечки и рекомендации по защите