Чем безопасность API отличается от общей безопасности приложений?

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

Что такое безопасность приложений?

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

ISACA определяет пять важнейших компонентов программ AppSec:

1. Безопасность по задумке
2. Безопасное тестирование кода
3. Спецификация программного обеспечения
4. Обучение и осведомленность в области безопасности
5. Шлюзы безопасности WAF и API и разработка правил

Что такое безопасность API?

API, или интерфейс прикладного программирования, безопасность защищает API от кибератак. В последние годы использование API резко возросло, предоставив организациям возможности для инноваций, обеспечивая передачу данных между приложениями. К сожалению, по мере увеличения использования API на них также стали осуществляться атаки. Исследование Salt Security показало, что атаки на API увеличились на 400% в период с июня по декабрь 2022 года.

Угрозы безопасности приложений и API

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

Интересно, что хотя OWASP опубликовал список «Десять главных рисков безопасности веб-приложений» в 2003 году, список «Десять главных рисков безопасности API» был опубликован только в конце 2019 года. широко исследованная дисциплина, претерпевшая множество этапов эволюции, тогда как безопасность API — нет.

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

Десять крупнейших рисков безопасности приложений OWASP (2021 г.)

1. Нарушение контроля доступа . Когда неавторизованный пользователь может получить доступ к ограниченной информации или системам.
2. Криптографические сбои – когда третья сторона раскрывает конфиденциальные данные без конкретного намерения из-за отсутствия или недостатков криптографии.
3. Внедрение – когда злоумышленник пытается отправить данные в приложение таким образом, чтобы изменить смысл команд, отправляемых интерпретатору.
4. Безопасный дизайн – риски, связанные с архитектурными и проектными недостатками.
5. Неправильная конфигурация безопасности . Когда специалисты по безопасности неправильно настраивают или оставляют элементы управления безопасностью небезопасными.
6. Уязвимые и устаревшие компоненты . Когда организации оставляют компоненты без исправлений.
7. Сбои идентификации и аутентификации (ранее «Нарушенная аутентификация») — когда приложения уязвимы для атак аутентификации.
8. Нарушения целостности программного обеспечения и данных . Когда код и инфраструктура не могут защитить от нарушений целостности.
9. Сбои ведения журнала безопасности и мониторинга (далее «Недостаточное ведение журнала и мониторинг») — когда организациям не удается обнаружить утечки данных из-за неадекватных процедур ведения журнала и мониторинга.
10. Подделка запросов на стороне сервера . Когда злоумышленники обманом заставляют приложения отправлять созданный запрос в неожиданный пункт назначения, даже если они защищены брандмауэром, VPN или другим типом списка управления доступом к сети (ACL).

Десять крупнейших рисков безопасности API OWASP (2023 г.)

1. Авторизация на уровне сломанного объекта — когда объект API — например, базы данных или файлы — не имеет надлежащего контроля авторизации, предоставляя доступ неавторизованным пользователям.
2. Нарушенная аутентификация . Когда инженеры по программному обеспечению и безопасности неправильно понимают границы аутентификации API и способы ее реализации.
3. Авторизация на уровне свойств сломанного объекта — сочетание чрезмерного раскрытия данных и массового присвоения: когда злоумышленники используют блокировку или неправильную авторизацию на уровне свойств объекта.
4. Неограниченное потребление ресурсов. Для удовлетворения запросов API требуется пропускная способность сети, ЦП, память и хранилище. Поставщики услуг делают другие ресурсы, такие как электронная почта/SMS/телефонные звонки или проверка биометрических данных, доступными через интеграцию API и оплачиваются за каждый запрос. Успешные атаки могут привести к отказу в обслуживании или увеличению эксплуатационных расходов.
5. Авторизация на сломанном функциональном уровне предполагает, что злоумышленники отправляют законные вызовы API на открытые конечные точки API.
6. Неограниченный доступ к конфиденциальным бизнес-потокам. API-интерфейсы, уязвимые для этого риска, раскрывают бизнес-поток, например, покупку билета или публикацию комментария, без компенсации за то, как эта функциональность может нанести вред бизнесу при чрезмерном использовании в автоматическом режиме; это не обязательно связано с ошибками реализации.
7. Подделка запроса на стороне сервера. Когда API извлекает удаленный ресурс без проверки URI, предоставленного пользователем; позволяя злоумышленнику заставить приложение отправить созданный запрос в неожиданный пункт назначения, даже если оно защищено брандмауэром или VPN.
8. Неправильная конфигурация безопасности . API и поддерживающие их системы обычно содержат сложные конфигурации, делающие их более настраиваемыми. Инженеры по программному обеспечению и DevOps могут пропустить эти конфигурации или не следовать рекомендациям по безопасности в отношении конфигурации, открывая двери для различных типов атак.
9. Неправильное управление запасами . API предоставляют больше конечных точек, чем традиционные веб-приложения, поэтому важна правильная и обновленная документация. Адекватная инвентаризация хостов и развернутых версий API также важна для устранения таких проблем, как устаревшие версии API и открытые конечные точки отладки.
10. Небезопасное использование API. Разработчики склонны доверять данным, полученным от сторонних API, больше, чем пользовательскому вводу, и принимают более слабые стандарты безопасности. Чтобы скомпрометировать API, злоумышленники используют интегрированные сторонние сервисы вместо того, чтобы напрямую скомпрометировать целевой API.

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

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