В последние годы стало нормой использовать API при разработке веб- и мобильных приложений. В этой статье Екатерина Саяпина, Product Owner личного кабинета платформы МТС Exolve рассказывает, каким рискам могут подвергнуться данные при работе с API и что можно сделать для их защиты.

Немного статистики 

Согласно отчёту State of API Economy 2021 Report, разработчики очень часто используют API при создании веб- и мобильных продуктов. Вот немного цифр.

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

Потенциальные риски API

За каждым API, включая SMS API от МТС, стоит конечная точка — сервер (с поддерживающими его базами данных), который отвечает на его запросы. И эта точка может быть уязвимостью, которую потенциально может использовать злоумышленник. Уязвимости есть в каждой системе, и чем более свободный и открытый доступ пользователей к ресурсу, тем больше потенциальная угроза со стороны различных вирусов и зловредов. Например, в марте 2023 года злоумышленники осуществили кибератаку на почтовый сервис Outlook от Microsoft.

Количество точек входа, через которые злоумышленник может потенциально получить несанкционированный доступ к сети или системе, неизменно растёт. Так, с 2009 года по настоящий момент количество уязвимостей в списках CVE (Common Vulnerabilities and Exposures) выросло в 5 раз.

Использование уязвимого API приведёт к компрометации личной информации или интеллектуальной собственности компании. В худшем случае потенциальному риску могут подвергнуться не только данные, но и вся инфраструктура. Общее количество эксплойтов (атак) на API увеличилось на 286% только за первый квартал 2022 года. 

Это подтверждает прошлогоднее исследование специалистов по безопасности Forbes. А отчёт Salt Labs о состоянии безопасности API за первый квартал 2023 года показал, что число уникальных злоумышленников увеличилось на 400% за последние шесть месяцев и что 94% респондентов сталкивались с проблемами безопасности в рабочих API в прошлом году.

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

  • Проблемы с безопасностью у API Google, затрагивающие аккаунты 52 миллионов человек.

  • Уязвимость в системе безопасности API Uber.

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

Распространённые атаки на веб-API

Специалисты сообщества Owasp, которое занимается кибербезопасностью, выделили распространённые виды атак на веб-API:

  • Broken Object Level Authorization (некорректная авторизация на уровне объектов). Точки входа в API могут быть скомпрометированы злоумышленником, который манипулирует идентификатором объекта, отправляемого в запросе. Поэтому они станут уязвимыми. Это может открыть доступ к критичной информации неавторизованным пользователям.

Один из примеров: онлайн-хранилище документов позволяет пользователям просматривать, редактировать, хранить и удалять свои документы. При удалении документа, в API отправляется мутация GraphQL с ID документа.

POST /graphql
{
  "operationName":"deleteReports",
  "variables":{
	"reportKeys":["<DOCUMENT_ID>"]
  },
  "query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) {
	{
  	deleteReports(reportKeys: $reportKeys)
	}
  }"
}

Поскольку документ с этим ID удаляется без каких-либо проверок, один пользователь может удалить документ другого пользователя.

  • Broken Authentication (некорректная аутентификация). Неправильно реализованный механизм аутентификации даёт злоумышленнику шанс напрямую подобраться к токенам и скомпрометировать пользовательскую информацию.

Пример: чтобы обновить email, связанный с учётной записью, клиентам нужно отправить запрос, подобный такому:

PUT /account
Authorization: Bearer <token>

{ "email": "<new_email_address>" }

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

  • Broken Function Level Authorization (некорректная авторизация на уровне функций). Злоумышленники, использующие уязвимости в авторизации на этом уровне, могут зайти в учётную запись пользователя: повысить привилегии для получения административного доступа либо удалить её.

  • Broken Object Property Level Authorization (некорректная авторизация на уровне объектов). Такой вид атаки также нередко приводит к раскрытию конфиденциальных сведений.

  • Unrestricted Resource Consumption (неограниченное потребление ресурсов). API считается уязвимым при некорректно установленных ограничениях, например, максимально доступном объёме памяти, количестве файловых дескрипторов, количестве операций, выполняемых в одном клиентском запросе API (например, пакетная обработка GraphQL).

  • Injection (инъекции) — атаки на базу данных, при которых вредоносный код вставляется в программу, в месте, где ожидается обычный ввод данных пользователем (например, логин, пароль, параметр или интегрированный сервис). Сюда входит также межсайтовый скриптинг (XSS) — внедрение вредоносного скрипта (часто JavaScript) в код веб-приложения или страницы. Около 34% всего трафика в сети Auth0 состоит из преступных попыток заполнения учётных данных — это показал прошлогодний отчёт State of Secure Identity 2022.

Принципы защиты API

Более 80% юзеров прекращают использовать продукцию определенной компании, если есть подтверждённый факт допущенной этим брендом утечки конфиденциальной пользовательской информации. На это указывает опрос потребителей, проведённый несколько лет назад pingidentity.com. Соответственно, безопасность API должна быть одним из первых пунктов в ИБ-стратегии любой компании. Именно так считаем и мы в МТС, создавая SMS API и другие компоненты в составе МТС Exolve.

Некоторые полезные принципы защиты данных перечислим ниже.

Используйте надёжные решения для реализации аутентификации и авторизации

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

  • Использовать проверенные механизмы аутентификации (например, OAuth2.0 и OpenID Connect).

  • Применять простые надёжные пароли и многофакторную аутентификацию (MFA).

  • При необходимости использовать единый вход (SSO).

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

  • Проверять входные данные, чтобы убедиться в их соответствии требованиям.

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

  • Защитить токены аутентификации (хранить токены в безопасных местах и контролировать к ним доступ).

  • Ограничить доступ к ключам API (за этим мы тоже следим).

Практикуйте принцип наименьших привилегий

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

Применяйте шифрование трафика

Компаниям, регулярно обменивающимся конфиденциальной информацией, для защиты API от атак типа Security Misconfiguration будет полезным использование шифрования, например, при помощи протоколов SSL/TLS.

Следите за потреблением ресурсов

Для защиты от атак типа Unrestricted Resource Consumption используйте решения, упрощающие ограничение памяти, ЦП, количества перезапусков, файловых дескрипторов и процессов (контейнеры, бессерверный код). Ограничьте количество выполнения одной операции одним пользователем API (например, проверяйте OTP или запрашивайте восстановление пароля без посещения одноразового URL-адреса).

Инвентаризация API

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

Инструменты для безопасности API

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

  2. RESTler для сканирования и фаззинга REST API. Это первый инструмент фаззинга REST API с отслеживанием состояния для автоматического тестирования облачных сервисов через их REST API и поиска ошибок безопасности и надёжности в этих сервисах.

  3. API-брандмауэр для конечных точек REST API и безопасности в реальном времени.

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

И несмотря на то что, согласно опросу разработчиков State of the API Report 2023, инциденты угрозы безопасности API происходят реже одного раза в год, позаботиться о его защите всё же надо заранее.

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

Комментарии (2)


  1. systemoops
    25.08.2023 04:36

    Интересные вещи, а то вечно только про тестирование api все говорят, а что апишки у всех дырявые, несмотря на вроде бы отсутствие багов, никому нет дела


  1. sicvense
    25.08.2023 04:36
    +1

    Еще стоит упомянуть о конкретных ляпах в реализации, таких как валидация данных на фронте, к примеру на сайте МТС Банк если посмотреть, то получив токен в браузере, можно закинуть любые невалидные данные в БД, что не очень хорошо, валидация должна быть и на backend.
    Еще прям из ляпов из беглого просмотра того, что есть на сайтах экосистемы МТС это маскирование данных на фронте))) заходим в режим Dev в браузере и видим не маскированные персональные данные, т.е создается только иллюзия для пользователя который их хранит, что данные защищены, на самом деле они хранятся и путешествуют в открытом виде.