Безопасность веб-API — это приложение любой безопасности, которое применяется к веб-API и включает в себя конфиденциальность API и контроль доступа, а также обнаружение атак на него путем обратного проектирования. Независимо от того, на что нацелено приложение, будь то потребители, сотрудники, партнеры или иное, мобильное приложение или веб-приложение, которые являются клиентскими сторонами приложения, взаимодействуют с серверной стороной через интерфейс прикладного программирования (API). . Проще говоря, мы можем сказать, что программирование приложений упрощает создание разработчиком сервисов разработки мобильных приложений на стороне клиента.
Что такое безопасность веб-API и как работает API?
Разработчики API часто сталкиваются с уязвимостями безопасности, поскольку они основаны на веб-технологиях. API-интерфейсы очень восприимчивы к атакам, поскольку веб-API раскрывают базовую реализацию вычислительной системы, что еще больше расширяет зону атаки. Веб-API, в отличие от веб-приложений, предоставляют потребителям гораздо большую гибкость. Стандарты безопасности API в меньшей степени ориентированы на API, которые используются одним пользователем, и предоставляются другими сторонами. Благодаря анализу исходящего трафика API также можно получить ценную информацию.
Некоторые серьезные атаки при реализации API:
Интерфейс прикладного программирования (API) позволяет приложениям взаимодействовать друг с другом и предоставляет разработчикам возможность создавать программные приложения, а также позволяет извлекать данные и обмениваться ими в доступной форме.
API-интерфейсы могут использоваться для облегчения кибератак из-за уязвимостей, таких как слабая аутентификация, отсутствие шифрования, логические ошибки и небезопасные конечные точки.
Некоторые из основных атак, которые обычно случаются:
Человек посередине (MITM)
Злоумышленник перехватывает трафик между взаимодействующими сторонами, ретранслируя и блокируя обмен данными, включая обмен API, для получения конфиденциальной информации.
Внедрение API (XSS и SQLi)
При этом вредоносный код вставляется в уязвимое программное обеспечение для проведения атаки, такой как межсайтовый скриптинг (XSS) и внедрение SQL (SQLi).
Захват DNS
Этот вид захвата, также известный как перенаправление DNS, представляет собой тип атаки, при которой DNS-запросы неожиданно перенаправляются на вредоносные сайты. Этот вид угона также используется для фишинга, при котором жертвы становятся мишенью, и злоумышленники пытаются обманом заставить их раскрыть конфиденциальную информацию, такую как их платежные данные.
Безопасность API для SOAP, REST и GraphQL:
API-интерфейсы могут иметь несколько типов, и иногда их стиль влияет на то, как к ним применяются стандарты безопасности API. Например, до веб-API стандартным стилем использования были веб-службы SOAP (WS), которые применяются на уровне сообщения с использованием цифровых подписей и зашифрованных частей в самом сообщении XML. Преимущество SOAP, отделенного от транспортного уровня, заключается в том, что его можно переносить между сетевыми протоколами, хотя этот тип безопасности на уровне сообщений потерял популярность.
REST, также известный как передача репрезентативного состояния, стал более распространенным стилем безопасности API за последнее десятилетие, и его часто принимают по умолчанию, когда используется термин «веб-API». Важным аспектом стиля REST API является то, что HTTP URI однозначно идентифицируют его ресурсы. Этот аспект предсказуемых REST API вдохновил поколение методологий управления доступом, в которых правила связаны с URI (ресурсом), к которому осуществляется доступ, или, по крайней мере, с шаблоном URI, к которому осуществляется доступ.
Правила управления доступом часто основаны на сочетании глагола HTTP и шаблонов HTTP URI. Это практикуется, в частности, для решений по обеспечению безопасности промежуточного программного обеспечения, потому что они применяют правила управления доступом, которые отделены от самих реализаций веб-API, сидя перед ними или выступая в качестве агентов.
В GraphQL, который является заменой REST, API, доступ ко всем ресурсам осуществляется через один URI (например, /graphql). Существующие системы безопасного управления доступом к веб-API и инфраструктура часто не предназначены для этого типа трафика API. Таким образом, достаточно сказать, что поставщики API должны учитывать, что будет лучше всего соответствовать каждому новому набору требований при выборе своего подхода.
Как защитить API и почему:
Кибер-злоумышленники переключают свое внимание с традиционных целей на API из-за их нынешнего роста. Новая цель была предоставлена из-за широкого внедрения API во всем мире, и она еще не была полностью использована.
API-интерфейсы быстро становятся мишенями для злонамеренной эксплуатации. В недавнем отчете европейской фирмы по безопасности Edgescan было обнаружено, что, хотя 81% всех уязвимостей в 2018 году были сетевыми уязвимостями, 19% всех уязвимостей были связаны с веб-приложениями, API и т. д. API следует обрабатывать с помощью тот же уровень серьезности, который предлагается другим критически важным бизнес-приложениям группами безопасности. Меры безопасности конечных точек API следует рассматривать как существенный аспект процесса разработки, а не как второстепенный.
Рекомендации по безопасности API:
Некоторые рекомендации по обеспечению безопасности API:
● Применяйте строгую аутентификацию и авторизацию.
● Повышение прозрачности API.
● Проверка параметров
● Используйте квоты и ограничение скорости
● включена безопасность на протяжении всего жизненного цикла разработки API
● Практика обучения пользователей
Интеграция безопасности API во весь жизненный цикл разработки API должна иметь место, так как без всеобъемлющего подхода поддержание безопасности ваших API может быть затруднено.
API — это отличная технология, которая позволяет предприятиям создавать динамические приложения, ориентированные на будущее. Однако, несмотря на то, что они могут быть обоюдоострым мечом, с помощью правильных методологий и политик эти риски можно уменьшить.
Кредит статьи:
Манан Г. [email protected]
