Поиск по сайту:

Как защитить себя от API-атак

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

Веб-API

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

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

Любой мог получить личные данные о любом клиенте Peloton. Первое «исправление» просто ограничивало использование API владельцами Peloton. Это было лишь незначительно лучше. С окончательным исправлением данные пользователя Peloton, наконец, становятся конфиденциальными, если только они явно не решат поделиться ими.

Есть много других примеров слабых или плохо спроектированных API. Facebook раскрыл личные данные 533 миллионов своих пользователей, потому что API позволял любому осуществлять поиск в базе данных по телефонным номерам со скоростью до 1000 в минуту.

Более 80 процентов всего интернет-трафика приходится на API-трафик. Это множество API. По состоянию на середину 2021 года 10 главных угроз безопасности Open Web Application Security Project (OWASP) не менялись в течение нескольких лет. К сожалению, одни и те же ошибки, приводящие к одним и тем же уязвимостям, повторяются снова и снова. И это слишком заманчиво, чтобы киберпреступники могли его игнорировать.

Заинтересованные стороны развития

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

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

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

Типы атак

Общие типы атак, с которыми вы столкнетесь, могут быть сгруппированы в соответствии с их техникой атаки.

  • Подстановка учетных данных. Это похоже на атаки методом перебора паролей, но вместо паролей учетных записей пользователей используются учетные данные API.
  • Атаки с внедрением. При атаке с внедрением киберпреступник добавляет компьютерные инструкции к своим запросам API таким образом, что встроенные инструкции действуют на конечную точку API. Внедрение SQL – это атака, использующая базы данных SQL. Часто легко определить, какие текстовые элементы в вызове API будут включены в операторы SQL. Добавление операторов SQL к этим вызовам функций API может привести к тому, что эти фрагменты SQL будут обрабатываться SQL-серверами конечных точек API. Межсайтовый скриптинг – аналогичная атака, при которой встроенные инструкции написаны на языке сценариев, обычно JavaScript.
  • Распределенный отказ в обслуживании (DDoS). Эти атаки очень похожи на DDoS-атаки, которые переполняют веб-сайт трафиком, не позволяя ему обслуживать подлинные запросы. DDoS-атаки, направленные на конечные точки API, становятся все более популярными среди злоумышленников.
  • Человек посередине (MitM) Эти атаки основаны на перехвате трафика между подлинным, невиновным клиентом API и конечной точкой API. Если учетные данные аутентификации API перехвачены, их можно использовать для повторного подключения, маскируясь под подлинного клиента API. Иногда вызовы API, сделанные от подлинного клиента, модифицируются таким образом, чтобы конечная точка API выполняла то, что хотят злоумышленники, а не то, что хочет фактический клиент.

Защита ваших API

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

Определите, с чем вы имеете дело

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

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

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

Сделайте ваши API краткими

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

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

Использовать шифрование

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

Аутентификация и входные значения

Очевидно, вам нужна надежная система аутентификации. Не изобретайте велосипед. По возможности используйте признанное решение, такое как OAuth2.0. Вы можете подумать, что внутренние API не нуждаются в аутентификации. Но можете ли вы гарантировать, что внутренний API не будет опубликован по ошибке, возможно, из-за того, что он повторно используется в другом проекте?

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

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

Союзные технологии

Брандмауэры веб-приложений (WAF) помогают защитить веб-сайты, размещенные приложения и API, фильтруя и отслеживая входящий и исходящий трафик защищенного ресурса. Они могут обнаруживать такие атаки, как межсайтовый скриптинг и SQL-инъекция. WAF — это технология защиты на уровне приложений (уровень 7 в модели ISO), а не решение типа «подгони и забудь» для всего вашего веб-сайта или безопасности API. Лучше всего их развертывать как один из элементов многоуровневой системы защиты.

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

API на передовой

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