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

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

OWASP API Security Top 10

API используется повсеместно, а вместе с этим растет количество инцидентов, связанных с атаками на его функционал. Авторитетный проект OWASP, сосредоточенный на безопасности веб-приложений, выпустил OWASP API Security Top 10 2019 (PDF-версия) — перечень наиболее опасных и распространенных ошибок при разработке и использовании API:

  • API1:2019 — Недостатки контроля доступа к объектам;
  • API2:2019 — Недостатки аутентификации;
  • API3:2019 — Разглашение конфиденциальных данных;
  • API4:2019 — Отсутствие ограничений на ресурсы и запросы;
  • API5:2019 — Недостатки контроля доступа на функциональном уровне;
  • API6:2019 — Переназначение параметров;
  • API7:2019 — Ошибки настроек безопасности;
  • API8:2019 — Инъекции;
  • API9:2019 — Некорректное управление ресурсами;
  • API10:2019 — Недостаточное журналирование и мониторинг.

API1:2019 Недостатки контроля доступа к объектам

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

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

API2:2019 Недостатки аутентификации

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

  • API Key — это строка символов, которую передает клиент в запросах к серверу. Для успешной аутентификации строка должна совпадать и у клиента и у сервера;
  • Basic Authentication — использование аутентификации по двум строкам, например логину/паролю. Для передачи информации используется HTTP заголовок 'Authorization' с ключевым словом Basic, далее пробел и в base64 закодированная строка username:password;
  • Cookie-Based Authentication — использование механизма передачи Cookies в HTTP запросах. В ответ на запрос клиента сервер посылает заголовок Set-Cookie, который содержит имя и значение cookie, а также дополнительные атрибуты: expires, domain, path, secure, httponly;
  • Token-Based Authentication — использование подписанного сервером токена (bearer token), который клиент передает на сервер в заголовке Authorization HTTP с ключевым словом Bearer или в теле запроса.

Компрометация способности системы идентифицировать пользователя ставит под угрозу безопасность API в целом.

API3:2019 Разглашение конфиденциальных данных

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

Пример:
Из-за некорректной обработки пользовательских данных работа API нарушается, вызывая непреднамеренное раскрытие данных.

API4:2019 Отсутствие ограничений на ресурсы и запросы

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

  • задержка выполнения;
  • максимально доступная память;
  • количество процессов;
  • размер полезной нагрузки запроса;
  • количество запросов на клиента;
  • количество записей на страницу, возвращаемых в одном ответе на запрос.

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

API5:2019 Недостатки контроля доступа на функциональном уровне

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

Пример:
Система разграничения доступа между ролями пользователей API позволяет назначать права доступа для различных ролей, таких как обычный пользователь или администратор. Команды, которые может выполнять только администратор, должны быть доступны только администратору. Проверка прав доступа должна выполняться при каждом выполнении команды пользователем API.

API6:2019 Переназначение параметров

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

Пример:
Записи пользователей могут иметь поля, доступные для редактирования: Имя, Фамилия, дата рождения и т.д. Без ограничения списка атрибутов, которые может менять пользователь, злоумышленник способен изменить любой параметр, явно не предусмотренный для этого системой.

API7:2019 Ошибки настроек безопасности

Уязвимость может возникнуть в следующих случаях:

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

API8:2019 Инъекции

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

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

API9:2019 Некорректное управление ресурсами

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

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

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

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

Nemesida WAF

Для выявления атак на веб-приложения и API рекомендуем использовать Nemesida WAF или Nemesida WAF Free. Функционал Nemesida WAF позволяет анализировать обращения в том числе к API, производя нормализацию и парсинг запросов, таким образом повышая точность выявления атак до 99.98% при минимальном количестве ложных срабатываний. Установка и базовая настройка основных компонентов займет не более 15 минут.

После активации Nemesida WAF / Nemesida WAF Free атаки будут отображаться в личном кабинете (также устанавливается локально). Демо-версия личного кабинета доступна по ссылке: demo.lk.nemesida-security.com (логин: demo@pentestit.ru / пароль: pentestit).