[API] Перевод OWASP API Security Top 10 (перевод)

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
16-Мар-2021 16:32

Цитировать

Эта статья - перевод OWASP API Security Top 10, опубликованного в 2019 году. Проект состоит из десяти наиболее актуальных рисков безопасности API. Полная версия документа на русском языке опубликована здесь: https://github.com/OWASP/API-Security/blob/master/2019/ru/dist/owasp-api-security-top-10.pdfAPI1:2019 Некорректная Авторизация на Уровне ОбъектовИсточники угроз/Векторы атакНедостатки безопасностиПоследствияЗависит от API : Сложность эксплуатации 3Распространенность 3 : Сложность обнаружения 2Технические последствия 3 : Зависит от бизнесаЗлоумышленник может проэксплуатрировать уязвимые к некорректной авторизации на уровне объектов точки входа API, манипулируя идентификатором объекта, отправляемого в запросе. Это может привести к неавторизованному доступу к критичной информации. Это очень распространненая ситуация среди приложений базирующихся на API, потому что серверная часть не полностью отслеживает состояние клиента, а вместо это полагается на отправляемые клиентом параметры, например, идентификатор объекта, чтобы принять решение, к какому объекту осуществляется доступ.Данная атака на API наиболее распространена и несет наибольшие последствия. Авторизация и механизмы контроля доступа в современных приложениях повсеместны и зачастую запутаны. Даже если проверки авторизации реализованы в приложении корректно, разработчики могут забыть добавить эти проверки перед доступом к критичным объектам. Автоматизированное статическое и динамическое тестирование, как правило, не обнаруживает проблемы в управлении доступом.Неавторизованный доступ может привести к потере или манипуляции данными, а также разглашению данных лицам, не имеющим права доступа к ним. Кроме того неавторизованный доступ может привести к получению полного контроля над учетными записями.Как определить, является ли API уязвимым?Авторизация на уровне объектов - это механизм управления доступом, реализуемый на уровне кода и проверяющий, что пользователь может получить доступ только к тем объектам, к которым у него должен быть доступ.Каждая точка входа API, получающая идентификатор объекта и выполняющая любое действие с объектом, должна провести проверку авторизации на уровне объекта. Проверка должна удостовериться в том, что текущий пользователь действительно имеет право осуществить запрошенное действие над запрошенным объектом.Некорректная работа этого механизма обычно приводит к неавторизованному разглашению или изменению данных, а также к их уничтожению.Пример сценария атакиСценарий #1Торговая онлайн платформа для онлайн магазинов предоставляет страницу с графиками доходов для каждого размещенного на платформе магазина. Злоумышленник, проанализировав отправляемые браузером запросы, может найти точки входа API, предоставляющие данные для графиков и определить формат запросов к ним /shops/{shopName}/revenue_data.json. Используя другую точку входа API, злоумышленник может получить список названий всех магазинов, размещенных на платформе. Используя простой скрипт, заменяющий {shopName} в URL запроса на названия магазинов, злоумышленник может получить доступ к данным о продажах тысяч онлайн магазинов.Сценарий #2Злоумышленник анализирует сетевой трафик носимого устройства, и HTTP PATCH запрос, содержащий нестандартный HTTP заголовок X-User-Id: 54796, привлекает его внимание. Изменив значение заголовка X-User-Id на 54795, злоумышленник получает ответ сервера, означающий успешную обработку запроса. Это означает, что злоумышленник может изменять данные учетных записей других пользователей.Как предотвратить

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

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

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

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

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 содержит полный список камер на объекте.Как предотвратить

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

API4:2019 Отсутствие Ограничений на Количество Запросов и Потребляемые РесурсыИсточники угроз/Векторы атакНедостатки безопасностиПоследствияЗависит от API : Сложность эксплуатации 2Распространенность 3 : Сложность обнаружения 3Технические последствия 2 : Зависит от бизнесаДля эксплуатации необходимы простые запросы к API. Аутентификация не требуется. Злоумышленник может единовременно отправить большое количество запросов, используя локальный компьютер или облачную систему вычислений.Часто API не ограничивают количество запросов, или эти ограничения настроены некорректно.Эксплуатация может привести к отказу в обслуживании, выражающемся в долгом времени ответа или полной недоступности API.Как определить, является ли API уязвимым?Запросы к API потребляют ресурсы, например, пропускную способность канала, процессорное время, оперативную память и место в хранилище данных. Количество ресурсов, потребляемых для ответа на запрос к API, во многом зависит от пользовательского ввода и бизнес логики точки входа. Кроме того, нужно принимать во внимание то, что запросы от различных клиентов API используют ресурсы совместно. API уязвимо, если хотя бы одно из следующих ограничений отсутствует или имеет некорректное значение (например, слишком высокое или низкое):

Максимальное время ожидания выполнения
Максимальный объем выделяемой памяти
Количество файловых дескрипторов
Количество процессов
Размер полезной нагрузки запроса (например, размер загружаемого файла)
Количество запросов на одного клиента или ресурс
Количество записей из базы данных, возвращаемых в ответе на один запрос

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

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

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.Примеры сценариев атакиСценарий #1В ходе процесса регистрации в приложении, которое позволяет регистрироваться только приглашенным пользователям, мобильное приложение отправляет следующий запрос к API GET /api/invites/{invite_guid}. Ответ содержит JSON с деталями приглашения, включая роль пользователя и его электронную почту.Злоумышленник может дублировать запрос, изменив HTTP метод и точку входа на POST /api/invites/new. Только администраторы должны иметь доступ к этой точке входа через интерфейс администрирования, однако он не проводит проверки авторизации на уровне функций.Проэксплуатировав уязвимость, злоумышленник может отправить себе приглашение с ролью администратора:

POST /api/invites/new
{“email”:”hugo@malicious.com”,”role”:”admin”}

Сценарий #2API содержит точку входа, которая должна быть доступна только администраторам GET /api/admin/v1/users/all. Эта точка входа возвращает данные всех пользователей и не проводит проверки авторизации на уровне функции. Злоумышленник, изучив структуру API, подбирает URL и получает доступ к точке входа, которая возвращает критичные данные пользователей приложения.Как предотвратитьВ вашем приложении должен быть согласованный и легко анализируемый модуль авторизации, вызываемый всеми бизнес функциями. Зачастую такая защита предоставляется одной или несколькими компонентами вне кода приложения.

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

API6:2019 - Массовое Переназначение Параметров (Mass assignment)Источники угроз/Векторы атакНедостатки безопасностиПоследствияЗависит от 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}.

Злоумышленник дублирует первый запрос со следующим телом запроса:

{"user_name":"attacker","age":60,"credit_balance":99999}

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

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

API7:2019 Ошибки Настроек БезопасностиИсточники угроз/Векторы атакНедостатки безопасностиПоследствияЗависит от API : Сложность эксплуатации 3Распространенность 3 : Сложность обнаружения 3Технические последствия 2 : Зависит от бизнесаЗлоумышленники часто пытаются найти незакрытые уязвимости, распространенные точки входа или незащищенные файлы и папки, чтобы получить информацию о системе или неавторизованный доступ к ней.Ошибка настроек безопасности может произойти на любом уровне API: от сетевого уровня до уровня приложения. Существуют автоматизированные инструменты для обнаружения и эксплуатации таких ошибок конфигурации, как ненужные (забытые) сервисы или использование устаревших параметров.Ошибки настроек безопасности могут не только раскрыть конфиденциальные данные пользователей, но и данные о системе, что потенциально может привести к её полной компрометации.Как определить, является ли 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). В частности, не защищено скачивание изображений профиля. Поскольку взаимодействие пользователя с приложением бинарно (да или нет, свайп влево или вправо, и так далее), несмотря на шифрование трафика, злоумышленник может найти закономерности в параметрах ответов API (например, размер ответа на свайп влево больше, чем на свайп вправо), которые он в свою очередь может использовать для отслеживания действий и предпочтений пользователя.Как предотвратитьЖизненный цикл API должен включать в себя:

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

Кроме того:

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

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 обрабатывает запросы на удаление с помощью следующей функции:

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, предоставляющему параметризированный интерфейс.
Всегда ограничивайте количество возвращаемых записей, чтобы предотвратить массовую утечку данных в случае инъекции.
Валидируйте входящие данные с помощью надлежащих фильтров, допуская только подходящие значения каждого из входящих параметров.
Определите тип данных и строгую модель данных для всех строковых параметров.

API9:2019 Ненадлежащее Управление АктивамиИсточники угроз/Векторы атакНедостатки безопасностиПоследствияЗависит от API : Сложность эксплуатации 3Распространенность 3 : Сложность обнаружения 2Технические последствия 2 : Зависит от бизнесаСтарые версии API обычно не содержат всех исправлений и могут быть с легкостью скомпрометированы без необходимости обходить новейшие механизмы безопасности, которые с высокой вероятностью используются для защиты последних версий API.Устаревшая документация усложняет поиск и исправление уязвимостей. Отсутствие инвентаризации активов и стратегии вывода из эксплуатации приводит к функционированию необновленных систем, которые могут быть использованы для кражи критичных данных. При использования современных подходов типа микросервисов, которые позволяют легко разворачивать независимые приложения (например, облачные сервисы или kubernetes) хосты API (домены и серверы, на которых функционирует API) зачастую без необходимости доступны извне.Злоумышленник может получить доступ к критичным данным или даже получить контроль над сервером через старую, необновленную версию 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 миллионов пользователей.Сценарий #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 включает улучшения, связанные с безопасностью, проводите анализ рисков для принятия решения о действиях по снижению рисков в старых версиях, например, переносу улучшения в старые версии без нарушения совместимости, или отключению старой версии и переводу всех клиентов на новую.

API10:2019 Недостаточное Логирование и МониторингИсточники угроз/Векторы атакНедостатки безопасностиПоследствияЗависит от API : Сложность эксплуатации 2Распространенность 3 : Сложность обнаружения 1Технические последствия 2 : Зависит от бизнесаЗлоумышленник пользуется отсутствием логирования и мониторинга для незаметной эксплуатации уязвимостей системы.Отсутствующие или недостаточные логирование и мониторинг не позволяют отследить подозрительную активность и своевременно отреагировать на нее.Без наблюдения за происходящей подозрительной активностью у злоумышленника есть достаточно времени для полной компрометации системы.Как определить, является ли API уязвимым?API уязвим, если:

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

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

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

===========
Источник:
habr.com
===========
===========
Автор оригинала: OWASP Project
===========Похожие новости:

Теги для поиска: #_api, #_owasp, #_api_security, #_top_10, #_blog_kompanii_owasp (
Блог компании OWASP
), #_api

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 21:46
Часовой пояс: UTC + 5