Десять наиболее критичных рисков безопасности APIСодержаниеОб OWASP

Содержание
Содержание...............................................................2Предисловие..............................................................3Введение....................................................................4Анонс выпуска..........................................................5Риски безопасности API..........................................6OWASP API Security Top 10 - 2019..........................7
API1:2019 Некорректная Авторизация на Уровне
Объектов.....................................................................8
API2:2019 Некорректная Аутентификация
Пользователей..........................................................10
API3:2019 Предоставление Излишних Данных. .12
API4:2019 Отсутствие Ограничений наКоличество Запросов и Потребляемые Ресурсы. .14
API5:2019 Некорректная Авторизация на Уровне
Функций...................................................................16
API6:2019 Массовое Переназначение Параметров
...................................................................................18
API7:2019 Ошибки Настроек Безопасности........20
API8:2019 Инъекции..............................................22
API9:2019 Ненадлежащее Управление Активами
...................................................................................24
API10:2019 Недостаточное Логирование иМониторинг..............................................................26Дальнейшие шаги для разработчиков..................28Дальнейшие шаги для DevSecOps........................29Методология и данные...........................................30Благодарность.........................................................31

Open Web Application Security Project (OWASP) - открытое
сообщество, нацеленное на предоставление возможности
организациям разрабатывать, покупать и поддерживать
приложения и API, которым можно доверять.
В OWASP вы найдёте открытые и бесплатные:
•
•
•
•
•
•
•
•
•

Инструменты и стандарты по безопасности
приложений.
Полноценные книги по тестированию
безопасности, разработке безопасного кода и кодревью на безопасность.
Презентации и видео.
Списки рекомендаций (Cheat sheets) на разные
темы.
Стандартизированные меры безопасности ибиблиотеки.
Локальные отделения по всему миру.
Современнейшие исследования.
Масштабные конференции по всему миру.
Списки рассылки.

Узнайте больше на https://www.owasp.org.
Все инструменты, документы, видео, презентации иотделения OWASP бесплатны и открыты для всех, ктозаинтересован в улучшении безопасности разработки
приложений.
Мы выступаем за подход к безопасности к разработке
приложений как к проблеме на уровне людей, процессови технологий, поскольку наиболее эффективные методы
обеспечения безопасности приложений требует
улучшения на всех этих уровнях.
OWASP - это новый вид организации. Наша свобода отдавления коммерческих организаций позволяет нампредоставлять беспристрастную, практичную иэкономически оправданную информацию о безопасности
приложений.
OWASP не аффилирован ни с какими технологическими
компаниям, однако мы поддерживаем информированное
использование коммерческих технологий побезопасности. OWASP создаёт множество материалов
коллективным, прозрачным и открытым способом.
OWASP Foundation - некоммерческая организация,обеспечивающая долговременный успех проекта. Почтивсе участники OWASP - волонтёры, включая
исполнительный комитет OWASP, руководителей
отделений, лидеров и участников проектов. Мыподдерживаем инновационные исследования побезопасности грантами и инфраструктурой.
Присоединяйтесь к нам!

https://owasp.org

Этот документ выпущен в соответствии с лицензиейCreative Commons Attribution ShareAlike 4.0 InternationalПредисловие
Программный интерфейс приложений (API) - фундаментальный элемент инноваций в современном,движимом приложениями мире. API - важная составляющая современных мобильных, SaaS и вебприложений, используемая в клиентских, партнерских и внутренних приложениях от банковской сферы,сфер розничных продаж и логистики до интернета вещей, автономных автомобилей и умных городов.
По своей природе API раскрывают логику приложения и критичные данные, например, персональные
данные, именно поэтому API все чаще становятся целью злоумышленников. Стремительные инновации
невозможны без безопасных API.
Несмотря на то, что более обширный Web Application Security Risks Top 10 по прежнему актуален, ввиду
специфики API, необходим отдельный список рисков безопасности специфичных для API. Безопасность
API фокусируется на стратегиях и решениях, направленных на понимание и предотвращение
уникальных уязвимостей и рисков безопасности, связанных с использованием API.
Если вы уже знакомы с OWASP Top 10 Project, то наверняка заметите сходства с настоящим документом,их основная цель - улучшение читаемости и повышение частоты использования настоящего документа.
Если вы не знакомы с семейством OWASP Top 10, то рекомендуем сначала ознакомиться с секциями
Риски Безопасности API и Методология и Данные перед погружением в список Top 10.
Вы можете посодействовать OWASP API Security Top 10 своими вопросами, комментариями и идеями внашем репозитории GitHub:•

https://github.com/OWASP/API-Security/issues•

https://github.com/OWASP/API-Security/blob/master/CONTRIBUTING.mdВы можете ознакомиться с OWASP API Security Top 10 здесь:•https://www.owasp.org/index.php/OWASP_API_Security_Project•

https://github.com/OWASP/API-SecurityМы хотим поблагодарить всех участников проекта, которые своим вкладом и стараниями помогли
проекту свершиться. Все они перечислены в секции Благодарность. Спасибо вам!

Введение
Добро пожаловать в OWASP API Security Top 10 - 2019!
Добро пожаловать в первую версию OWASP API Security Top 10. Если вы знакомы с семейством OWASPTop 10, то вы заметите сходства, их основная цель - улучшение читаемости и повышение частоты
использования настоящего документа. В противном случае посетите страницу OWASP API Security
Project wiki перед погружением в наиболее критичные риски безопасности API.
API играют важную роль в архитектуре современных приложений. Поскольку информированность всфере безопасности и инновации движутся с разной скоростью, важно сфокусироваться на общих
недостатках безопасности API.
Основная цель OWASP API Security Top 10 - предоставить информацию людям, вовлечённым вразработку и поддержание API, например, разработчикам, дизайнерам, архитекторам, менеджерам илицелым организациям.
В секции Методология и Данные вы можете более подробно ознакомиться с тем, как была создана
текущая версия. В будущих версиях мы хотим вовлечь индустрию безопасности путём публичного
сбора данных. А сейчас мы призываем всех внести свой вклад вопросами, комментариями и идеями внашем GitHub репозитории или Списке рассылки.

Анонс выпускаЭто первая версия OWASP API Security Top 10, которую мы планируем обновлять каждые три-четыре
года.
В будущих версиях, в отличие от этой, мы планируем публичный сбор данных, вовлекая индустрию
безопасности в эту активность. В секции Методология и Данные вы можете найти подробности о том,как эта версия была создана. Для дополнительной информации о рисках безопасности обратитесь ксекции Риски безопасности API.
Необходимо понимать, что за последние несколько лет архитектура приложений значительно
изменилась. В настоящий момент API играют очень важную роль в новой архитектуре микросервисов,одностраничных приложений (SPA), мобильных приложений, интернете вещей и так далее.
OWASP API Security Top 10 - попытка повысить информированность о проблемах безопасности
современных API. Он был возможен благодаря труду волонтёров, перечисленных в секции
Благодарность. Спасибо вам!

Риски безопасности APIДля анализа рисков была использована Методология оценки рисков OWASP.
Терминология, относящаяся к оценкам риска, приведена в таблице ниже.
Источники
угрозЗависит от APIСложность
эксплуатации

Распространенность

Сложность
обнаружения

Технические
последствия

Просто: 3Широкая 3Просто 3Значительные 3Средне: 2Обычная 2Средне 2Средние 2Сложно: 1Редкая 1Сложно 1Незначительные 1Последствиядля бизнеса
Зависит отбизнеса

Примечание: Этот подход не принимает во внимание источник угроз, а также различные технические
детали вашего конкретного приложения. Любой из этих факторов может значительно повлиять наобщую вероятность обнаружения и эксплуатации злоумышленником конкретной уязвимости. Этасистема оценки не принимает во внимание фактические последствия для вашего бизнеса. Вашей
организации необходимо решить, какие риски безопасности, создаваемые приложениями и API, онаготова принять с учётом её культуры безопасности, индустрии и требований регуляторов. Проведение
анализа рисков за вас не является целью OWASP API Security Top 10.

СсылкиOWASP•OWASP Risk Rating Methodology•

Article on Threat/Risk ModelingВнешние
•
•
•
•
•
•

ISO 31000: Risk Management Std
ISO 27001: ISMSNIST Cyber Framework (US)ASD Strategic Mitigations (AU)NIST CVSS 3.0
Microsoft Threat Modeling ToolOWASP API Security Top 10 - 2019
API1:2019 - Некорректная
Авторизация на Уровне
Объектов

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

API2:2019 - Некорректная
Аутентификация Пользователей

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

API3:2019 - Предоставление
Излишних Данных

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

API4:2019 - Отсутствие
ограничений на количество
запросов и потребляемые
ресурсы

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

API5:2019 - Некорректная
авторизация на уровне функций

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

API6:2019 - Массовое
переназначение параметров
(Mass assignment)Присвоение поступивших от пользователя данных, например в формате JSON,модели данных без надлежащей фильтрации параметров на базе белого списка
обычно приводит к массовому переназначению параметров. Злоумышленник
может изменить свойства объектов, к которым он не должен иметь доступ,угадав эти свойства, найдя их в других точках входа API или документации,или же отправив запрос с дополнительными свойствами.

API7:2019 - Ошибки настроек
безопасностиКак правило, ошибки настроек безопасности - результат небезопасных
настроек по умолчанию, неполных или временных настроек, незащищенного
облачного хранилища, некорректно настроенных заголовков HTTP, излишних
методов HTTP, нестрогой политики разделения ресурсов между источниками(CORS) и детальных сообщений об ошибках, содержащих критичные данные.

API8:2019 - Инъекции

Инъекции, такие как SQL, NoSQL, инъекции команд на операционной системеи другие, случаются, когда недоверенные данные отправляются винтерпретатор как часть команды или запроса. Злоумышленник может
вынудить интерпретатор выполнить команду или получить данные в обход
проверок авторизации.

API9:2019 - Ненадлежащее
управление активами

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

API10:2019 - Недостаточное
логирование и мониторинг

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

API1:2019 Некорректная Авторизация на Уровне Объектов
Источники
угрозВекторы
атакНедостатки
безопасности

Последствия

Зависит отСложность
РаспростраСложность
Технические Зависит отAPIэксплуатации: 3ненность: 3обнаружения: 2последствия: 3 бизнеса
Злоумышленник может
Данная атака на API наиболее
Неавторизованный доступ
проэксплуатрировать уязвимые краспространена и несет наибольшие может привести к потере илинекорректной авторизации напоследствия. Авторизация иманипуляции данными, ауровне объектов точки входа API, механизмы контроля доступа втакже разглашению данных
манипулируя идентификатором
современных приложениях
лицам, не имеющим права
объекта, отправляемого в запросе. повсеместны и зачастую запутаны. доступа к ним. Кроме тогоЭто может привести кДаже если проверки авторизации
неавторизованный доступ
неавторизованному доступу креализованы в приложении
может привести к получению
критичной информации. Это очень корректно, разработчики могут
полного контроля надраспространненая ситуация среди забыть добавить эти проверки перед учетными записями.
приложений базирующихся на API, доступом к критичным объектам.
потому что серверная часть неАвтоматизированное статическое иполностью отслеживает состояние динамическое тестирование, какклиента, а вместо это полагается на правило, не обнаруживает проблемы
отправляемые клиентом параметры, в управлении доступом.
например, идентификатор объекта,чтобы принять решение, к какому
объекту осуществляется доступ.

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

Пример сценария атаки
Сценарий #1
Торговая онлайн платформа для онлайн магазинов предоставляет страницу с графиками доходов длякаждого размещенного на платформе магазина. Злоумышленник, проанализировав отправляемые
браузером запросы, может найти точки входа API, предоставляющие данные для графиков и определить
формат запросов к ним /shops/{shopName}/revenue_data.json. Используя другую точку входа API,злоумышленник может получить список названий всех магазинов, размещенных на платформе.
Используя простой скрипт, заменяющий {shopName} в URL запроса на названия магазинов,злоумышленник может получить доступ к данным о продажах тысяч онлайн магазинов.

API1:2019 Некорректная Авторизация на Уровне Объектов
Сценарий #2
Злоумышленник анализирует сетевой трафик носимого устройства, и HTTP PATCH запрос, содержащий
нестандартный HTTP заголовок X-User-Id: 54796, привлекает его внимание. Изменив значение заголовка
X-User-Id на 54795, злоумышленник получает ответ сервера, означающий успешную обработку запроса.
Это означает, что злоумышленник может изменять данные учётных записей других пользователей.

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

•
•

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

Ссылки
Внешние
• CWE-284: Improper Access Control• CWE-285: Improper Authorization• CWE-639: Authorization Bypass Through User-Controlled Key

API2:2019 Некорректная Аутентификация Пользователей
Источники
угрозВекторы
атакНедостатки
безопасности

Зависит отСложность
РаспростраСложность
APIэксплуатации: 3ненность: 2обнаружения: 2Аутентификация в API Механизм аутентификации подвержен
сложный и запутанный
двум основным проблемам:механизм. Разработчики и
1. Отсутствие механизмов защиты:инженеры безопасности могут разработчики должны обращать особое
иметь неверное представление внимание на точки входа API,о том, что входит в понятие
отвечающие за аутентификацию, иаутентификации, и каквнедрять дополнительные уровни
правильно её внедрить. Кроме защиты.
того, механизм
2. Некорректная реализация механизма:аутентификации - простая цель механизм используется или реализован,для злоумышленников,не принимая во внимание основные
поскольку он общедоступен.
векторы атак, или используетсяВсе это приводит к тому, чтомеханизм, не подходящий под текущую
механизм аутентификации
ситуацию (например, механизм
потенциально содержит
аутентификации для IoT устройств
большое число уязвимостей.
зачастую не подходит для вебприложений).

Последствия

Технические Зависит отпоследствия: 3 бизнеса
Злоумышленник может
получить контроль надучетными записями других
пользователей в системе,получить доступ к ихперсональным данным, илиосуществить критичные
действия от их имени,например, отправить
денежные переводы илиперсональные сообщения.

Как определить, является ли API уязвимым?
Точки входа, отвечающие за аутентификацию и процесс аутентификации, - это активы, требующие
защиты. Необходимо относиться к функционалу восстановления пароля аналогично механизму
аутентификации.
API уязвим, если:
•
•
•
•
•
•
•
•

Позволяет перебор учётных данных, при условии, что у злоумышленника есть списки
существующих логинов и паролей.
Позволяет злоумышленнику подбирать пароль к одной и той же учетной записи путём перебора,не требуя ввода CAPTCHA или не блокируя учётную запись.
Допускает слабые пароли.
Передаёт критичные аутентификационные данные в URL, например, аутентификационные
токены или пароли.
Не проверяет подлинность токенов.
Допускает JWT токены не содержащие подпись ("alg":"none") или использующие уязвимые
алгоритмы подписи, не проверяет срок действия токена.
Хранит пароли в открытом виде или в хэшированном виде с использованием слабых алгоритмов
хеширования.
Использует слабые ключи шифрования.

Примеры сценариев атаки
Сценарий #1
Перебор учётных данных с использованием списка известных логинов и паролей - распространённая
атака. Если в приложении отсутствуют автоматизированные меры защиты от угроз или перебора
учётных данных, то оно может быть использовано для определения валидности учётных данных.

API2:2019 Некорректная Аутентификация Пользователей
Сценарий #2
Злоумышленник начине восстановление пароля, отправив POST запрос в точку входа
/api/system/verification-codes и указав имя пользователя в теле запроса. Затем одноразовый пароль из 6цифр отправляется на телефон жертвы. Поскольку API не ограничивает количество запросов,злоумышленник может за несколько минут подобрать корректный одноразовый пароль, перебирая всевозможные пароли с помощью скрипта, работающего в многопоточном режиме и отправляющего
запросы на /api/system/verification-codes/{smsToken}.

Как предотвратить?
Идентифицируйте все возможные способы аутентификации в API (для мобильных и веб клиентов, deep
links, обеспечивающих аутентификацию в одно нажатие, и так далее).
•
•

•
•

•
•
•

•

•

Спросите у разработчиков, какие способы аутентификации вы пропустили.
Изучите используемые механизмы аутентификации. Изучите, что они из себя представляют и какиспользуются. OAuth не используется для аутентификации пользователей, так же как и APIключи.
Не изобретайте велосипед, когда речь идёт об аутентификации, генерации токенов и хранении
паролей. Используйте стандарты.
Внедрите защиту от перебора, ограничение на количество единовременных запросов ивременную блокировку учётных записей на точках входа, отвечающих за восстановление
учётных данных и пароля, аналогично мерам защиты на точках входа, используемых дляаутентификации.
Ознакомьтесь с OWASP Authentication Cheatsheet.
Используйте многофакторную аутентификацию, где это возможно.
Используйте механизмы защиты от перебора учётных данных, перебора по словарю и перебора
всех возможных значений на точках входа, отвечающих за аутентификацию. Эти механизмы
должны использовать более строгие правила по сравнению с механизмом ограничивающим
количество запросов в остальных точках входа API.
Внедрите блокировку учётных записей или CAPTCHA для предотвращения перебора
аутентификационных данных, направленного на единичных пользователей. Внедрите защиту отслабых паролей.
Не используйте API ключи для аутентификации пользователей. Они должны использоваться дляаутентификации приложений и проектов, являющихся клиентами API.

СсылкиOWASP• OWASP Key Management Cheat Sheet• OWASP Authentication Cheatsheet• Credential StuffingВнешние
• CWE-798: Use of Hard-coded Credentials

API3:2019 Предоставление Излишних Данных
Источники
угрозВекторы
атакНедостатки
безопасности

Последствия

Зависит отСложность
РаспростраСложность
Технические Зависит отAPIэксплуатации: 3ненность: 2обнаружения: 2 последствия: 2бизнеса
Предоставление излишних
API рассчитывают, что клиентское
Предоставление излишних
данных легко эксплуатировать. приложение отфильтрует отображаемые данных обычно приводит кДля этого нужно перехватить пользователю данные. Поскольку APIразглашению
трафик и проанализировать
используются в качестве источника
конфиденциальных данных.
ответы API на предмет
данных, иногда разработчики пытаются
критичных данных, которые
сделать его универсальным для всехAPI не должно возвращать
клиентов, не думая о критичности
пользователю.
возвращаемых пользователю данных.
Автоматизированные инструменты
зачастую не обнаруживают этууязвимость, поскольку без детального
понимания логики приложения очень
трудно определить, должно ли APIвозвращать те или иные данные.

Как определить, является ли API уязвимым?
API уязвим, если он спроектирован так, что возвращает критичные данные клиентскому приложению,которое в свою очередь фильтрует их перед отображением пользователю, то злоумышленник слёгкостью может перехватить трафик и увидеть критичные данные.

Примеры сценариев атаки
Сценарий #1
Команда мобильного приложения использует точку входа /api/articles/{articleId}/comments/{commentId} дляотображения метаданных комментариев в представлении статей. Злоумышленник перехватывает трафикот мобильного приложения и находит в ответе дополнительные критичные данные об авторе
комментария. Точка входа реализована так, что использует стандартный метод toJSON() на объекте
модели User, содержащем персональные данные, для сериализации этого объекта.

Сценарий #2
Система видеонаблюдения, базирующаяся на IOT, позволяет администраторам создавать пользователейс различными привилегиями. Администратор создал учётную запись для нового охранника, которая
должна иметь доступ только к определенным зданиям на объекте. Когда охранник использует
мобильное приложение, оно отправляет запрос в точку входа /api/sites/111/cameras, чтобы получить данныео доступных камерах и отобразить их на панели управления. Ответ API содержит список данных окамерах в следующем формате:{"id":"xxx","live_access_token":"xxxx-bbbbb","building_id":"yyy"}. Клиентское
приложение показывает только те камеры, к которым охранник имеет доступ, однако ответ APIсодержит полный список камер на объекте.

API3:2019 Предоставление Излишних ДанныхКак предотвратить•Не рассчитывайте, что клиентская часть приложения отфильтрует критичные данные.

•Проверьте, что ответы API содержат только те данные, которые отображаются клиентским
приложением.

•Разработчики серверной части должны всегда задаваться вопросом "Кто получит данные?" перед
публикацией новых точек входа API.

•Избегайте использования стандартных методов, например, to_json() или to_string(). Вместо этого
вручную выбирайте свойства объектов, которые вы возвращаете в ответе.
Классифицируйте критичную информацию и персональные данные, с которыми работает
приложение, путём анализа всех вызовов API, возвращающих подобные данные, чтобы
определить, несут ли эти ответы риски безопасности.

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

Ссылки
Внешние
•CWE-213: Intentional Information ExposureAPI4:2019 Отсутствие Ограничений на Количество
Запросов и Потребляемые Ресурсы
Источники
угрозВекторы
атакНедостатки
безопасности

Зависит отСложность
РаспростраСложность
APIэксплуатации: 2ненность: 3обнаружения: 3
Для эксплуатации необходимы Часто API не ограничивают количество
простые запросы к API.
запросов, или эти ограничения
Аутентификация не требуется. настроены некорректно.
Злоумышленник может
единовременно отправить
большое количество запросов,используя локальный
компьютер или облачную
систему вычислений.

Последствия

Технические Зависит отпоследствия: 2 бизнеса
Эксплуатация может
привести к отказу вобслуживании,выражающемся в долгом
времени ответа или полной
недоступности API.

Как определить, является ли API уязвимым?
Запросы к API потребляют ресурсы, например, пропускную способность канала, процессорное время,оперативную память и место в хранилище данных. Количество ресурсов, потребляемых для ответа назапрос к API, во многом зависит от пользовательского ввода и бизнес логики точки входа. Кроме того,нужно принимать во внимание то, что запросы от различных клиентов API используют ресурсы
совместно. API уязвимо, если хотя бы одно из следующих ограничений отсутствует или имеет
некорректное значение (например, слишком высокое или низкое):•Максимальное время ожидания выполнения

•Максимальный объем выделяемой памяти

•Количество файловых дескрипторов

•Количество процессов

•Размер полезной нагрузки запроса (например, размер загружаемого файла)•Количество запросов на одного клиента или ресурс

•Количество записей из базы данных, возвращаемых в ответе на один запрос

Примеры сценариев атаки
Сценарий #1
Злоумышленник загружает большое изображение, отправив POST запрос на /api/v1/images. После
завершения загрузки, API создаёт миниатюры изображения разного размера. Во время создания
миниатюр приложение использует всю доступную память и перестаёт отвечать на запросы из-забольшого размера загруженного изображения.

Сценарий #2
Рассмотрим приложение, отображающее список пользователей в пользовательском интерфейсе сограничением 200 штук на страницу. Для получения списка пользователей приложение отправляет
следующий запрос на сервер: /api/users?page=1&size=200. Злоумышленник увеличивает size до 200 000, чтоприводит к проблемам производительности в базе данных. API перестаёт отвечать на запросы и большене может обработать запросы текущего или любого другого клиента (отказ в обслуживании).

API4:2019 Отсутствие Ограничений на Количество
Запросов и Потребляемые Ресурсы
Аналогичный сценарий может быть использован для обнаружения ошибок переполнения буфера илицелочисленного переполнения.

Как предотвратить
• Docker легко позволяет ограничить объем памяти, процессорное время, количество перезапусков,файловые дескрипторы и процессы.
• Установите ограничение на частоту вызовов метода API одним клиентом в заданный промежуток
времени.
• Уведомите клиента, когда ограничение превышено, предоставив ему значение ограничения ивремя, когда ограничение будет сброшено.
• Добавьте соответствующие проверки параметров строки запроса и тела запроса на стороне
сервера, особенно важно контролировать количество записей, возвращаемых в запросе.
• Определите и контролируйте максимальный размер данных, содержащихся во всех входных
параметрах и полезных нагрузках, например, максимальную длину строки или максимальное
количество элементов массива.

СсылкиOWASP• Blocking Brute Force Attacks• Docker Cheat Sheet - Limit resources (memory, CPU, file descriptors, processes, restarts)• REST Assessment Cheat SheetВнешние
• CWE-307: Improper Restriction of Excessive Authentication Attempts• CWE-770: Allocation of Resources Without Limits or Throttling• “Rate Limiting (Throttling)” - Security Strategies for Microservices-based Application Systems, NISTAPI5:2019 Некорректная Авторизация на Уровне Функций
Источники
угрозВекторы
атакНедостатки
безопасности

Последствия

Зависит отСложность
РаспростраСложность
Технические Зависит отAPIэксплуатации: 3ненность: 2обнаружения: 1последствия: 2 бизнеса
Эксплуатация уязвимости
Проверки авторизации к функции илиПодобные ошибки позволяют
предполагает, чторесурсу обычно определяются на уровне злоумышленнику получить
злоумышленник может
конфигурации, иногда на уровне кода.
доступ к функционалу, минуя
успешно отправить запросы в Проведение проверок надлежащим
авторизацию.
точки входа API, к которым у образом - непростая и неоднозначная
Административный
него не должно быть доступа. задача, поскольку современные
функционал - ключевая цельЭти точки входа могут бытьприложения могут использовать много атак этого типа.
доступны любому
типов ролей и групп, а также иметь
неаутентифицированному
сложную иерархию пользователей
пользователю или(например, под-пользователей илиаутентифицированному
пользователей с несколькими ролями).
пользователю, не имеющему
достаточных привилегий.
Подобную ошибку легче
обнаружить в API (посравнению с традиционными
приложениями), поскольку APIболее структурированы, апорядок доступа копределенным функциям более
предсказуем (например,изменив метод HTTP запроса с
GET на PUT, или изменив
строку “users” в URL запроса
на "admins").

Как определить, является ли API уязвимым?
Лучший способ найти проблемы с некорректной авторизацией на уровне объектов - провести глубокий
анализ механизма авторизации, учитывая иерархию пользователей, различные роли и группы внутри
приложения, а также задав себе следующие вопросы:••Может ли обычный пользователь получить доступ к административным точкам входа?
Может ли пользователь совершить критичные действия (например, создать, изменить илиудалить объект), к которым у него не должно быть доступа, просто изменив метод HTTP запроса
(например, с GET на DELETE)?
• Может ли пользователь из группы Х получить доступ к точке входа, доступной только
пользователям из группы Y, просто угадав URL и параметры этой точки входа (например,/api/v1/users/export_all)?
Неверно предполагать, что точка входа API является обычной или административной только наосновании пути URL.
Зачастую разработчики открывают доступ к административным точкам входа по определённому
относительному пути, например, api/admins. Однако очень часто административные точки входа находятсяпо другим относительным путям вместе с обычными точками входа, например, api/users.

API5:2019 Некорректная Авторизация на Уровне Функций
Примеры сценариев атаки
Сценарий #1
В ходе процесса регистрации в приложении, которое позволяет регистрироваться только приглашённым
пользователям, мобильное приложение отправляет следующий запрос к API GET/api/invites/{invite_guid}. Ответ содержит JSON с деталями приглашения, включая роль пользователя иего электронную почту.
Злоумышленник может дублировать запрос, изменив HTTP метод и точку входа на POST /api/invites/new.
Только администраторы должны иметь доступ к этой точке входа через интерфейс администрирования,однако он не проводит проверки авторизации на уровне функций.
Проэксплуатировав уязвимость, злоумышленник может отправить себе приглашение с ролью
администратора:POST /api/invites/new{“email”:”hugo@malicious.com”,”role”:”admin”}Сценарий #2
API содержит точку входа, которая должна быть доступна только администраторам GET/api/admin/v1/users/all. Эта точка входа возвращает данные всех пользователей и не проводит проверки
авторизации на уровне функции. Злоумышленник, изучив структуру API, подбирает URL и получает
доступ к точке входа, которая возвращает критичные данные пользователей приложения.

Как предотвратитьВ вашем приложении должен быть согласованный и легко анализируемый модуль авторизации,вызываемый всеми бизнес функциями. Зачастую такая защита предоставляется одной или несколькими
компонентами вне кода приложения.
•
•
•

•

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

СсылкиOWASP•OWASP Article on Forced Browsing•

OWASP Top 10 2013-A7-Missing Function Level Access Control•

OWASP Development Guide: Chapter on AuthorizationВнешние
•CWE-285: Improper Authorization

API6:2019 Массовое Переназначение Параметров
Источники
угрозВекторы
атакНедостатки
безопасности

Последствия

Зависит отСложность
РаспростраСложность
Технические Зависит отAPIэксплуатации: 2ненность: 2обнаружения: 2последствия: 2 бизнесаДля эксплуатации зачастую
Современные фреймворки предлагают Эксплуатация уязвимости
требуется понимание бизнес
разработчикам функции, которые
может привести клогики, связей между
автоматически присваивают переменным повышению привилегий,объектами и структуры API.
и внутренним объектам значения
злонамеренному изменению
Эксплуатация массового
соответствующих параметров изданных, обходу механизмов
переназначения параметров
пользовательского ввода.
защиты и так далее.
проще реализуема в API,Злоумышленник может использовать этупоскольку они изначально
методологию, чтобы обновить илипредусматривают
переназначить критичные свойства
общедоступность внутренней объектов, которые разработчик нереализации API и названий
намеревался делать доступными длясвойств объектов.
пользователя.

Как определить, является ли API уязвимым?
Объекты в современных приложениях могут иметь большое количество свойств. Некоторые из нихмогут быть изменены напрямую клиентом (например, user.first_name или user.address), в то время какизменение других не должно быть доступно (например, флаг user.is_vip).
Конечная точка API уязвима, если она автоматически присваивает предоставленные клиентом
параметры свойствам внутренних объектов, не учитывая критичность и уровень доступности этихсвойств. Это может позволить злоумышленнику изменить свойства объектов, к которым у него недолжно быть доступа.
Примеры критичных свойств:•Свойства, относящиеся к привилегиям: user.is_admin, user.is_vip должны устанавливаться
только администраторами.

•Свойства, зависящие от процесса: user.cash должны устанавливаться только внутри кода после
проверки платежа.

•Внутренние свойства: article.created_time должны устанавливаться только внутри кода самим
приложением.

Примеры сценариев атаки
Сценарий #1
Приложение для совместных поездок позволяет пользователю редактировать базовую информацию
своего профиля. В ходе редактирования отправляется следующий запрос PUT /api/v1/users/me скорректным JSON объектом в теле запроса:{"user_name":"inons","age":24}Запрос к GET /api/v1/users/me включает в себя дополнительное свойство credit_balance:{"user_name":"inons","age":24,"credit_balance":10}

API6:2019 Массовое Переназначение Параметров
Злоумышленник дублирует первый запрос со следующим телом запроса:{"user_name":"attacker","age":60,"credit_balance":99999}
Поскольку точка входа уязвима к массовому переназначению параметров, злоумышленник зачисляет
деньги на свой баланс, не совершив платежа.

Сценарий #2
Портал для обмена видео позволяет пользователям загружать и скачивать материалы в разных форматах.
Злоумышленник исследует API и обнаруживает, что точка входа GET /api/v1/videos/{video_id}/meta_dataвозвращает JSON объект с параметрами видео. Один из параметров "mp4_conversion_params":"-v codech264" даёт понять, что приложение использует консольную команду для конвертации видео.
Злоумышленник также обнаружил, что точка входа POST /api/v1/videos/new уязвима к массовому
переназначению параметров и позволяет клиенту установить значение любого свойства объекта видео.
Злоумышленник устанавливает следующее значение параметра: "mp4_conversion_params":"-v codec h264&& format C:/". Это значение приведёт к инъекции команды операционной системы, как только
злоумышленник скачает видео в формате MP4.

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

•Добавляйте в белые списки только те свойства, которые могут быть изменены клиентом.

•Используйте встроенный функционал по добавлению в чёрный список свойств, к которым
клиенты не могут иметь доступ.

•Если это возможно, явно определите схемы входящих данных и проверяйте входящие данные поним.

Ссылки
Внешние
•CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

API7:2019 Ошибки Настроек Безопасности
Источники
угрозВекторы
атакНедостатки
безопасности

Зависит отСложность
РаспростраСложность
APIэксплуатации: 3ненность: 3обнаружения: 3Злоумышленники часто
Ошибка настроек безопасности может
пытаются найти незакрытые
произойти на любом уровне API: отуязвимости, распространённые сетевого уровня до уровня приложения.
точки входа или незащищённые Существуют автоматизированные
файлы и папки, чтобы
инструменты для обнаружения иполучить информацию оэксплуатации таких ошибок
системе или неавторизованный конфигурации, как ненужные (забытые)доступ к ней.
сервисы или использование устаревших
параметров.

Последствия

Технические Зависит отпоследствия: 2 бизнеса
Ошибки настроек
безопасности могут не только
раскрыть конфиденциальные
данные пользователей, но иданные о системе, чтопотенциально может
привести к её полной
компрометации.

Как определить, является ли API уязвимым?
API уязвим, если:
•
•
•
•
•
•
•

Должные настройки безопасности отсутствуют на каком-либо уровне приложения, а также еслиправа доступа к облачным сервисам некорректно настроены.
Используется устаревшая система, или не установлены новейшие исправления по безопасности.
Активен излишний функционал (например, неиспользуемые HTTP методы).
Не используется протокол TLS (Transport Layer Security).
Директивы безопасности не отправляются клиентским приложениям (например, Заголовки
Безопасности).
Политика разделения ресурсов между источниками (Cross-Origin Resource Sharing) отсутствуетили некорректно настроена.
Сообщения об ошибках включают детальную информацию или раскрывают критичные данные.

Примеры сценариев атаки
Сценарий #1
Злоумышленник в корне директории сервера находит файл .bash_history, содержащий команды, которые
использовала команда DevOps для доступа к API:$ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic Zm9vOmJhcg=='Злоумышленник также может найти другие незадокументированные точки входа API, используемые
только командой DevOps.

Сценарий #2
Для атаки на конкретный сервис злоумышленник использует популярный поисковик, чтобы найти
компьютеры, напрямую доступные из сети Интернет. Злоумышленник находит сервер, на котором
запущена популярная система управления базой данных, доступная на стандартном порте. На сервере
используется стандартная конфигурация, не предполагающая аутентификации, что позволяет
злоумышленнику получить доступ к миллионам записей с персональными данными, личными
предпочтениями и аутентификационными данными.

Сценарий #3
Анализируя трафик мобильного приложения, злоумышленник обнаруживает, что не весь HTTP трафик
защищён (например, с помощью TLS). В частности, не защищено скачивание изображений профиля.
Поскольку взаимодействие пользователя с приложением бинарно (да или нет, свайп влево или вправо, итак далее), несмотря на шифрование трафика, злоумышленник может найти закономерности в

API7:2019 Ошибки Настроек Безопасности
параметрах ответов API (например, размер ответа на свайп влево больше, чем на свайп вправо), которыеон в свою очередь может использовать для отслеживания действий и предпочтений пользователя.

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

СсылкиOWASP•OWASP Secure Headers Project•

OWASP Testing Guide: Configuration Management•

OWASP Testing Guide: Testing for Error Codes•

OWASP Testing Guide: Test Cross Origin Resource SharingВнешние
•CWE-2: Environmental Security Flaws•

CWE-16: Configuration•

CWE-388: Error Handling•

Guide to General Server Security, NIST•

Let’s Encrypt: a free, automated, and open Certificate Authority

API8:2019 Инъекции
Источники
угрозВекторы
атакНедостатки
безопасности

Последствия

Зависит отСложность
РаспростраСложность
Технические Зависит отAPIэксплуатации: 3ненность: 2обнаружения: 3 последствия: 3 бизнеса
Злоумышленник может
Ошибки, приводящие к инъекциям,Инъекции могут привести котправить в API любые данные очень распространены и присущи SQL, разглашению иличерез любой доступный вектор LDAP и NoSQL запросам, командам на уничтожению данных, отказу
инъекции (например, прямой операционной системе, XML парсерам и в обслуживании иливвод, параметры,ORM. Подобные ошибки легко
получению
интегрированные сервисы иобнаруживаются в ходе анализа
злоумышленником полноготак далее), предполагая, чтоисходного кода. Злоумышленники могут контроля на сервером.
они будут перенаправлены виспользовать сканеры и фаззеры.
интерпретатор.

Как определить, является ли API уязвимым?
API уязвим к инъекциям, если:• Данные, поступившие от пользователя, не валидируются, не фильтруются или не очищаются настороне API.
• Данные, поступившие от пользователя, конкатенируются или используются в неизменном виде в
SQL/NoSQL/LDAP запросах, командах на операционной системе, XML парсерах, ORM (Object
Relational Mapping) или ODM (Object Document Mapper).
• Данные поступающие из внешних систем (например, интегрированных систем) не валидируются,не фильтруются или не очищаются на стороне API.

Примеры сценариев атаки
Сценарий #1
Прошивка устройства контроля за детьми предоставляет точку входа /api/CONFIG/restore, которая
ожидает запроса с multipart параметром appId. Используя декомпилятор, злоумышленник обнаруживает,что appId передаётся непосредственно в вызов команды на операционной системе без предварительной
очистки:snprintf(cmd, 128, "%srestore_backup.sh /tmp/postfile.bin %s %d","/mnt/shares/usr/bin/scripts/", appid, 66);
system(cmd);

Следующая команда позволяет злоумышленнику отключить любое устройство с уязвимой прошивкой:$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F'appid=$(/etc/pod/power_down.sh)'Сценарий #2
Рассмотрим приложение с базовым CRUD функционалом для операций с бронированиями.
Злоумышленник обнаружил NoSQL инъекцию через параметр bookingId в запросе на удаление
бронирования. Запрос выглядит следующим образом: DELETE /api/bookings?bookingId=678.
Сервер API обрабатывает запросы на удаление с помощью следующей функции:API8:2019 Инъекции
router.delete('/bookings', async function (req, res, next) {try {const deletedBooking = await Bookings.findOneAndRemove({_id' : req.query.bookingId});
res.status(200);} catch (err) {res.status(400).json({error: 'Unexpected error occured while processing a request'
});
}
});

Злоумышленник перехватывает запрос и изменяет параметр bookingId, как продемонстрировано ниже. Вэтом случае злоумышленник может удалить бронирование, принадлежащее другому пользователю:DELETE /api/bookings?bookingId[$ne]=678

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

СсылкиOWASP•OWASP Injection Flaws•

SQL Injection•

NoSQL Injection Fun with Objects and Arrays•

Command InjectionВнешние
•CWE-77: Command Injection•

CWE-89: SQL Injection

API9:2019 Ненадлежащее Управление Активами
Источники
угрозВекторы
атакНедостатки
безопасности

Зависит отСложность
РаспростраСложность
APIэксплуатации: 3ненность: 3обнаружения: 2Старые версии API обычно не Устаревшая документация усложняет
содержат всех исправлений и поиск и исправление уязвимостей.
могут быть с лёгкостью
Отсутствие инвентаризации активов искомпрометированы безстратегии вывода из эксплуатации
необходимости обходить
приводит к функционированию
новейшие механизмы
необновленных систем, которые могут
безопасности, которые сбыть использованы для кражи
высокой вероятностью
критичных данных. При использования
используются для защиты
современных подходов типапоследних версий API.
микросервисов, которые позволяют
легко разворачивать независимые
приложения (например, облачные
сервисы или kubernetes) хосты API(домены и серверы, на которых
функционирует API) зачастую безнеобходимости доступны извне.

Последствия

Технические Зависит отпоследствия: 2 бизнеса
Злоумышленник может
получить доступ ккритичным данным или дажеполучить контроль надсервером через старую,необновленную версию API,использующую одну и ту жебазу данных.

Как определить, является ли API уязвимым?
API может быть уязвимым, если:• Назначение API хоста неясно, а также нет чётких ответов на следующие вопросы:• В каком окружении запущен API (например, production, staging, test, development)?
• Каким должен быть сетевой доступ к API (например, общедоступным, внутренним, дляпартнёров)?
• Какая версия API запущена?
• Какие данные собираются и обрабатываются API (например, персональные данные)?
• Каков поток движения данных?
• Документация отсутствует или не обновляется.
• Отсутствует план вывода из эксплуатации предыдущих версий API.
• Инвентаризация хостов не проводится, или её результаты устарели.
• Инвентаризация интегрированных внутренних или сторонних сервисов не проводится, или еёрезультаты устарели.
• Старые или предыдущие версии API функционируют без обновлений.

Примеры сценариев атаки
Сценарий #1
После переработки своих приложений локальный поисковый сервис оставил доступ к старой версии
API (api.someservice.com/v1) без надлежащих мер защиты и с доступом к базе данных пользователей.
Тестируя одну из последних выпущенных версий приложения, злоумышленник нашёл адрес API(api.someservice.com/v2). Заменив v2 на v1 в URL, злоумышленник получил доступ к старому
незащищённому API, предоставляющему доступ к персональным данным более 100 миллионов
пользователей.

API9:2019 Ненадлежащее Управление Активами
Сценарий #2
Социальная сеть внедрила механизм ограничения количества запросов, не позволяющий
злоумышленнику подобрать токен для сброса пароля. Этот механизм не был внедрён непосредственно в
код API, а использовался в качестве отдельного компонента между клиентом и официальным API(www.socialnetwork.com). Исследователь нашёл бета версию API (www.mbasic.beta.socialnetwork.com),использующую тот же API, включая механизм сброса пароля, но без механизма ограничения количества
запросов. Исследователь смог сбросить пароль любого пользователя, перебирая все возможные
варианты кода из 6 цифр.

Как предотвратить
• Проводите инвентаризацию хостов API и документируйте важные аспекты каждого из них:окружение (например, production, staging, test, development), каким должен быть сетевой доступ
(например, общедоступным, внутренним, для партнёров) и версию API.
• Проводите инвентаризацию интегрированных сервисов и документируйте важные аспекты
каждого из них: роль в системе, какие данные участвуют в обмене (потоки данных), какая
степень критичности этих данных.
• Документируйте все аспекты API: аутентификацию, ошибки, перенаправления, ограничение
количества запросов, политику разделения ресурсов между источниками (CORS) и точки входа,включая параметры, запросы и ответы.
• Создавайте документацию автоматически, используя общедоступные стандарты. Включайте
создание документации в CI/CD.
• Предоставьте документацию тем, кто имеет право доступа к API.
• Используйте внешние меры защиты, например, API security firewalls на всех доступных версиях
API, а не только на текущей версии в production.
• Избегайте использования данных с production системы в API на базе не production окружения.
Если такого использования невозможно избежать, защищайте этот API аналогично используемым
в production.
• Когда новая версия API включает улучшения, связанные с безопасностью, проводите анализ
рисков для принятия решения о действиях по снижению рисков в старых версиях, например,переносу улучшения в старые версии без нарушения совместимости, или отключению старой
версии и переводу всех клиентов на новую.

Ссылки
Внешние
•CWE-1059: Incomplete Documentation•

OpenAPI InitiativeAPI10:2019 Недостаточное Логирование и Мониторинг
Источники
угрозВекторы
атакНедостатки
безопасности

Последствия

Зависит отСложность
РаспростраСложность
Технические Зависит отAPIэксплуатации: 2ненность: 3обнаружения: 1последствия: 2 бизнеса
Злоумышленник пользуется
Отсутствующие или недостаточныеБез наблюдения заотсутствием логирования илогирование и мониторинг не позволяют происходящей
мониторинга для незаметной отследить подозрительную активность и подозрительной активностью
эксплуатации уязвимостей
своевременно отреагировать на неё.
у злоумышленника естьсистемы.
достаточно времени дляполной компрометации
системы.

Как определить, является ли API уязвимым?
API уязвим, если:•Не пишутся логи, уровень логирования некорректно установлен, или сообщения в логах
недостаточно детальны.

•Не обеспечивается целостность логов (например, Инъекция в логи ).

•Логи не подвергаются постоянному мониторингу.

•API не подвергается постоянному мониторингу.

Примеры сценариев атаки
Сценарий #1
Ключ доступа к административному API утекли через общедоступный репозиторий. Владелец
репозитория был уведомлен о потенциальной утечке по электронной почте, но отреагировал наинцидент более чем через 48 часов, в связи с чем утечка ключей могла привести к получению доступа ккритичным данным. Из-за недостаточного логирования компания не в состоянии оценить, к каким
данным злоумышленники смогли получить доступ.

Сценарий #2
Платформа обмена видео подверглась масштабной атаке по перебору учётных данных. Не смотря налогирование неуспешных попыток входа, уведомление об атаке не последовало в течение всего ходаатаки. Логи были проанализированы и атака обнаружена только во время анализа обращения
пользователя. Компании пришлось публично попросить пользователей сменить пароли и отправить
отчёт об атаке в регулирующие органы.

API10:2019 Недостаточное Логирование и МониторингКак предотвратить
• Логируйте все неудачные попытки входа, отказы в доступе и ошибки валидации входящих
данных.
• Логи должны быть представлены в формате, позволяющем обрабатывать их с помощью систем
управления логами, и должны включать достаточное количество деталей, позволяющих
идентифицировать злоумышленника.
• Логи должны считаться критичными данными, а их целостность должна быть обеспечена припередаче и хранении.
• Настройте систему мониторинга для постоянного контроля инфраструктуры, сети ифункционирующих API.
• Используйте систему управления информацией и событиями безопасности (SIEM), чтобы
агрегировать и управлять логами всех компонентов на всех уровнях и хостах API.
• Настройте персональные уведомления и панели управления для скорейшего обнаружения иреагирования на подозрительную активность.

СсылкиOWASP•OWASP Logging Cheat Sheet•OWASP Proactive Controls: Implement Logging and Intrusion Detection•

OWASP Application Security Verification Standard: V7: Error Handling and Logging Verification
RequirementsВнешние
•CWE-223: Omission of Security-relevant Information•

CWE-778: Insufficient Logging

Дальнейшие шаги для разработчиков
Задача по созданию и поддержке ПО в безопасном состоянии, или исправлению уже существующего ПОможет быть сложной. То же верно и для API.
Мы уверены, что обучение и осведомлённость являются ключевыми факторами написания безопасного
ПО. Все остальное, необходимое для достижения этой цели, зависит от налаженного и повторяемого
процесса безопасности и стандартных мер защиты.
OWASP включает большое количество бесплатных открытых ресурсов по безопасности с самого начала
проекта. Пожалуйста ознакомьтесь со страницей OWASP Projects, чтобы получить полный список
доступных проектов.
Вы можете начать изучать материалы OWASP Education Project, всоответствии со своей профессией и интересами. Для получения
практических знаний мы добавили crAPI – Completely Ridiculous API в нашплан развития. Тем временем вы можете попрактиковаться в безопасностивеб приложений, используя OWASP DevSlop Pixi Module - уязвимое вебОбучение
приложение с API сервисом, направленное на обучение пользователей
тестированию современных веб приложений и API на предмет ошибок
безопасности и написанию более безопасных API в будущем. Вы также
можете принять участие в практических сессиях конференции OWASPAppSec или присоединиться в вашему локальному отделению OWASP.
Безопасность должна быть частью любого проекта с самого начала. Наэтапе сбора требований необходимо определить роль безопасности впроекте. OWASP рекомендует использовать OWASP Application SecurityТребования по
Verification Standard (ASVS) в качестве руководства по постановке
безопасности
требований безопасности. Если вы пользуетесь услугами внешних
разработчиков, рассмотрите проект OWASP Secure Software Contract Annexи адаптируйте его в соответствии с локальными законами и нормативными
требованиями.
Безопасность должна получить должное внимание на всех этапах проекта.
OWASP Prevention Cheat Sheets - хорошая отправная точка поБезопасная архитектура проектированию механизмов безопасности на этапе архитектуры
приложения. Среди прочего вы можете ознакомиться с REST Security Cheat
Sheet и REST Assessment Cheat Sheet.
Внедрение стандартных мер безопасности снижает риск ошибок, связанныхс безопасностью, в ходе написания логики приложения. Несмотря на то, чтомногие современные фреймворки включают в себя стандартные мерыСтандартные мерыбезопасности, OWASP Proactive Controls предоставляет хороший обзор мербезопасности
безопасности, которые стоит включить в ваш проект. OWASP также
предоставляет библиотеки и инструменты, которые могут вам пригодиться,например, механизмы валидации.
Вы можете использовать OWASP Software Assurance Maturity ModelЖизненный цикл(SAMM) для улучшения процессов создания API. Несколько других
разработки безопасного
проектов OWASP могут помочь вам на различных этапах разработки API,ПОнапример, OWASP Code Review Project.

Дальнейшие шаги для DevSecOps
Создание безопасных API критически важно из-за их роли в архитектуре современных приложений.
Безопасностью нельзя пренебрегать, она должна быть частью всего жизненного цикла разработки. Уженедостаточно проводить сканирование и тестирование на проникновение раз в год.
DevSecOps должны присоединиться к работе по разработке и обеспечить непрерывное тестирование
безопасности на всем жизненном цикле разработки ПО. Их цель - усовершенствовать процесс
разработки, автоматизировав проверки безопасности, не влияя на скорость разработки.
Если вы сомневаетесь, ознакомьтесь с DevSecOps Manifesto и следите за его обновлениями.
Приоритеты при тестировании исходят из модели угроз. Если у вас её нет,рассмотрите использование OWASP Application Security VerificationПонимание модели угроз Standard (ASVS) и OWASP Testing Guide для начала её составления.
Включение команды разработки может помочь им быть более
осведомленными в сфере безопасности.
Объединитесь с командой разработки для лучшего понимания жизненного
цикла разработки ПО. Ваше содействие в части непрерывного тестирования
Понимание жизненного
безопасности должно гармонировать с людьми, процессами ицикла разработки ПОинструментами. Все должны быть согласны с процессом дляпредотвращения ненужных разногласий и сопротивления.
Поскольку ваша работа не должна влиять на скорость разработки, вамнеобходимо продуманно выбрать наилучшие (простые, быстрые и наиболее
точные) подходы к проверке требований по безопасности. OWASP SecurityСтратегии тестирования Knowledge Framework и OWASP Application Security Verification Standard отличные источники функциональных и нефункциональных требований побезопасности. Существуют также другие отличные проекты и инструменты,аналогичные предлагаемым сообществом DevSecOps.
Вы соединяете команды разработки и эксплуатации. Чтобы достичь
покрытия нужно сфокусироваться не только на функциональности, но и наДостижение покрытия и оркестрации. Работайте совместно с командами разработки и эксплуатации
точностис самого начала, чтобы оптимизировать свои трудозатраты. Вы должны
стремиться к состоянию, когда основы безопасности непрерывно
проверяются.
Приносите пользу, избегая конфликтов. Передавайте команде разработки
информацию о найденных уязвимостях своевременно, с помощью
Чётко описывайте
инструментов, используемых командой разработки. Помогите команде
найденные уязвимости разработки разобрать найденные уязвимости. Постарайтесь обучить их,чётко объяснив выявленные недостатки и процесс их эксплуатации,включая реальный сценарий атаки.

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

МетодологияНа первом этапе группа экспертов по безопасности собрала, проанализировала и категоризировала
публичные данные об инцидентах безопасности в API. Эти данные были собраны с площадок bug
bounty площадок и баз данных уязвимостей за последний год. Этот временной промежуток выбран дляудобства расчёта статистики.
Затем эксперты по безопасности с опытом тестирования на проникновение составили свой список 10-тинаиболее критичных рисков.
Методология ранжирования рисков OWASP была использована в ходе анализа рисков. Эксперты побезопасности проанализировали результаты. Чтобы узнать о рассуждениях на эту тему обратитесь ксекции Риски безопасности API.
Первый черновик OWASP API Security Top 10 2019 был составлен на базе статистических результатов
первого этапа и списков, созданных экспертами по безопасности. Этот черновик был отправлен дляпроверки и анализа другой группе экспертов по безопасности с достаточным опытом в сфере
безопасности API.
OWASP API Security Top 10 2019 впервые был представлен на конференции OWASP Global AppSec Tel
Aviv в мае 2019 года. С тех пор он доступен на GitHub для публичного обсуждения и содействия.
Список участников, внёсших свой вклад, доступен в секции Благодарность.

Благодарность
Благодарность участникамМы хотели бы поблагодарить всех участников, кто публично участвовал в проекте на GitHub илидругими способами:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

007divyachawla
Abid Khan
Adam Fisher
anotherikbkimminichcaseysoftware
Chris Westphal
dsopasDSotnikov
emilvaErezYalon
flascelles
Guillaume Benats
IgorSasovets
Inonshk
JonnySchnittger
jmanicojmdx
Keith Casey
kozmicLauraRosePorter
Matthieu Estradenathanawmk
PauloASilva
pentagramz
philippederyckpleothaud
r00ter
Raj kumar
Sagar Popat
Stephen Gates
thomaskonrad
xycloops123