OWASP API Security Top 10 RC

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

    Проект безопасности OWASP API Security Top 10 предназначен подчеркнуть потенциальные риски в небезопасных API и предложить меры снижения таких рисков.

    OWASP


    На проект OWASP ссылается множество стандартов, инструментов и организаций, включая MITRE, PCI DSS, DISA, FTC, и множество других. Методологии OWASP являет признанной методологией оценки уязвимостей веб-приложений во всем мире. Проекты OWASP отражают наиболее значимые угрозы веб- и мобильным приложениям, API, описывают методики и методологии тестирования.

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

    MODERN API


    Данный документ находится в статусе Release Candidat, официальное представление планируется на второй квартал 2020 года. API Security фокусируется на стратегиях и решениях для понимания и снижения уникальных уязвимостей и рисков безопасности интерфейсов прикладного программирования (API).

    Что стало предпосылкой к созданию этого листа:

    • Клиентские устройства становятся разнообразнее и сложнее.
    • Логика перемещается из бэкенда в фронтенд (вместе с некоторыми уязвимостями).
    • Меньше слоев абстракции.
    • Клиент и сервер (и БД) «говорят» на одном и том же JSON языке.
    • Сервер больше используется в качестве прокси для данных.
    • Компонент рендеринга — клиент, а не сервер.
    • Клиенты потребляют необработанные данные.
    • API раскрывают базовую реализацию приложения.
    • Состояние пользователя обычно поддерживается и контролируется клиентом.
    • В каждом HTTP-запросе отправляются дополнительные параметры (идентификаторы объектов,
    • фильтры).

    Современное веб-приложение практически невозможно представить без использования API.



    OWASP API Security Top 10


    А1 Некорректная авторизация на уровне объектов


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

    А2 Некорректная аутентификация


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

    А3 Выдача избыточной информации


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

    А4 Отсутствие лимитов на ресурсы и запросы


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

    А5 Некорректная авторизация функций


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

    А6 Переназначение параметров


    Привязывание данных, полученных от клиента (например в JSON) к моделям данных без фильтрации обычно приводит к переназначению параметров. Атакующие, исследуя API, читая документацию, или просто угадывая могут добавлять к запросам «лишние» параметры, меняя объекты к которым у них нет доступа.

    А7 Ошибки настроек безопасности


    Ошибки в настройках безопасности чаще всего — результат настроек по-умолчанию, «костылей», хранения в облаках, неправильной настройки HTTP заголовков, ненужных HTTP методов, чересчур широких настроек CORS, и включенного вывода ошибок.

    A8 Инъекции


    Уязвимости вида «инъекция» — такие как SQL, NoSQL, внедрение кода/команд, и т.д. случаются когда недоверенные данные пересылаются в обработчик как часть запроса или команды. Данные, внедренные атакующим могут «обмануть» обработчик и он выполнит произвольную команду, или получит данные без надлежащей авторизации.

    A9 Некорректное управление ресурсами


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

    A10 Недостаточное журналирование и мониторинг


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

    OWASP API Security Top 10 2019


    OWASP Russia chapter: OWASP Russia
    OWASP Russia chat: https://t.me/OWASP_Russia
    OWASP Russia channel: https://t.me/OWASP_RU
    • +36
    • 4.6k
    • 1
    Support the author
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 1

      +1
      SPA поэтому зло, их лепят на право и на лего потому что можно разделить девелоперов на ФЕ и БЕ, а то пускай сами договоряться как-то, отсюда избыточность и переопределение параметров можно легко упустить из виду, странно что авторизация имеет проблемы, вроде как ничего не стоит это настроить и это первое с чего апи начинается, но видимо о авторизации начинают думать когда уже всё остальное написано

      Only users with full accounts can post comments. Log in, please.