Оглавление
Я думаю, каждый участник спецпроекта “WAF для API-номики” напишет, что количество API стало огромным и даст расшифровку этому термину. Мы, в свою очередь, это уже сделали [1] и даже попытались придумать читаемую аббревиатуру. Но ничего толком не получилось: как был “Программируемый Интерфейс Приложения”, так и получился ПИП. Неблагозвучно и довольно странно, поэтому вернемся к англицизмам.
Автор: Лев Палей, директор по информационной безопасности, “Вебмониторэкс”
Основной вызов, который привлекает внимание многих – это распространение API не только для обмена между системами, но и для функционирования самих подкомпонентов приложений. Сейчас даже фронтовая часть в основном состоит из API-вызовов, и это считается хорошей практикой. А если вспомнить, что согласно отчету GMI [2], больше 70% систем сейчас разрабатываются и функционируют на базе микросервисов, то ситуация смотрится еще интереснее: API на API едет и API погоняет. Такое развитие вполне закономерно, потому что в России идет бум разработки с учетом требований импортонезависимости. Надо много и быстро разрабатывать под совершенно разные нужды. А когда нужно быстро, понятия оптимизации, безопасности и корректности уходят на задний план. И возвращаются только когда наступает стадия масштабирования и подстройки системы под более жесткие требования.
Основные проблемы при работе с API
Стоит начать с азов. Как и в программировании, качество программного кода зависит в том числе от количества времени, потраченного на его оптимизацию. Для этого есть понятие «рефакторинг», которое подразумевает под собой аудит, описание и оптимизацию кода таким образом, чтобы разработка разными командами и его функционирование были прозрачны и прогнозируемы. Вкладываем на старте, получаем результат по итогам. То же касается и API. Но насколько в каждой ситуации мы можем соблюдать все правила, зависит от требований к скорости разработки и доступных трудовых ресурсов, поэтому и нужны решения по автоматизации ряда этапов и контролей.
Идеальный вариант, если в компании принята парадигма API First.
Рис. 1. API First
Тогда процесс создания API будет выглядеть следующим образом:
Дизайн API. На этом этапе создается проект API. Рекомендуется использование открытых стандартов, таких как REST, JSON и OAuth для обеспечения совместимости API с другими системами. Выходными данными этапа проектирования становится Open API Specification (OAS) – документация описывающая API.
Тест. Здесь команда QA проверяет, реализуемо ли описанное в спецификации API: достаточно ли имеющихся и предоставляемых данных. И после валидации спецификации и корректировки основных несоответствий можно переходить к этапу внедрения API.
Внедрение. Здесь API по подготовленной и проверенной спецификации становится рабочим элементом – либо частью коммуникаций между бэкэндом и фронтэндом, либо публичным интерфейсом. С одной лишь разницей.
Если есть этап предпродуктового тестирования, то на этом этапе также подключаются тесты по безопасности. Обычно используется инструментарий DAST, позволяющий понять, есть ли уязвимости за эндпоинтами в спецификации. Эндпоинт представляет собой адрес конечной точки сервиса, на который отправляются запросы.
Если нет предпродуктового тестирования. Здесь должны подключаться системы для мониторинга API, чтобы увидеть корректность реализации после всех этапов.
Рис. 2. Работа системы для мониторинга API
Что можно увидеть внутри API?
Для наблюдаемости описанного выше процесса хорошо иметь понимание, насколько реализация совпадает с реальностью, при этом с помощью инструментов производства нашей компании мы выделяем следующие контроли.
Shadow API – это недокументированный API, который существует в инфраструктуре организации. Это значит трафик на эндпоинт проходит, но в спецификации он не указан. Наличие таких эндпоинтов говорит, о том что опубликована API не соответствующая спецификации, а значит процесс не работает.
Orphan API – это документированный API, который не получает трафик. Здесь обратная ситуация – в спецификации эндпоинт есть, но не используется продолжительное время. Тут возникает вопрос избыточности – зачем нам возможность вызова, которая не востребована?
Zombie API относится к устаревшим API, которые, как все предполагают, были отключены, но на самом деле все еще используются. Этот тип недостатка можно увидеть при сравнении подготовленной спецификации (на этапе проектирования) и спецификации полученной после публикации API из трафика (см. рис. 3).
Следующую категорию недостатков нельзя описать однозначно в бинарной логике (плохо или хорошо) – каждый из них зависит от того, насколько параметры API критичны для процессов конкретного приложения и компании.
Рис. 4. Уровни риска
Эти факторы повышают вероятность атаки на тот или иной эндпоинт в API. Такая оценка может производиться на этапе дизайна и проектирования API, а также может служить Security Gate, то есть представляет собой фильтр (реализованный техническими или административными средствами), который пропускает или не пропускает API в производственную среду на основании уровня риска, рассчитанного исходя из критериев, указанных ниже.
Количество параметров запроса и тела. Чем большее количество параметров используется в эндпоинте, тем больше количество точек, которые может использовать злоумышленник для применения атаки, и тем больше точек необходимо контролировать при разработке. То есть мы говорим об увеличении поверхности атаки и вероятности, что среди всех передаваемых параметров окажется тот, контроль и санитизация которого окажутся недостаточными. В том числе это же говорит и о недостатках разработки – хорошая практика использовать достаточное количество параметров в одном эндпоинте.
Параметры с конфиденциальными данными. Этот контроль важен для отслеживания количества параметров с конфиденциальными данными и методов защиты, которые к ним применяются. Согласитесь, будет странно, если персональные данные будут доступны без авторизации, или можно будет получить из разных полей полные данные о человеке.
Работа с объектами XML/JSON. Пусть эти форматы и работы с ними известна уже достаточно давно и плотно вошла в обиход разработки веб приложений и API – они все же являются элементом усложнения конечной системы. Работа с XML и JSON определенно дает больше возможностей. Но это относится и к возможностям злоумышленников по осуществлению атак на наши приложения. Небезопасная десериализация, атаки и внедрения в XML достаточно уверено вошли в OWASP Top 10 и присутствуют как подкатегории актуального рейтинга.
Возможность загружать файлы на сервер. По сути, c точки зрения безопасности это еще один, достаточно вариативный способ получения данных, нуждающийся в контроле. Передача измененных либо же созданных специально для целей осуществления атак файлов – по-прежнему актуальные и часто эффективные методики применяемые злоумышленниками. И опять таки, это усложнение самой API.
Корректность – понятие растяжимое
Часть из упомянутых выше контролей относятся и к безопасности, и к структурированию API, которое хорошо проводить на этапе проектирования, наблюдать в процессе тестирования API и отслеживать после публикации. При этом никуда не уходит (но видоизменяется) практика моделирования угроз – то есть формирования отношения и формулирования риск-аппетита по отношению к таким контролям. Понятно, что для приватных и публичных API внимание к таким контролям может быть совершенно разное, а значит и выдачу информации по таким API можно разделить и отдельно настроить.
Рис. 5. Влияние факторов на оценку рисков
Таким образом корректность формирования API можно наблюдать как минимум в двух разрезах:
насколько то, что запроектировано, действительно соответствует функционирующему API;
насколько корректно и безопасно то API, которое мы внедрили, с учетом существующих практик.
Принципы построения идеального API
С точки зрения построения идеального API опять-таки есть базовые принципы, часть из них мы упомянули выше, в составе контролей безопасности и при описании процесса. Давайте их суммируем.
Рекомендуется использование открытых стандартов, таких как REST, JSON и OAuth для обеспечения совместимости API с другими системами. Этот пункт больше относится к повторному использованию и масштабированию созданного API.
Не придумывайте слишком много кодов состояний и всегда применяйте одни и те же коды для одинаковых результатов в API. Таким образом тестирование и использование API будет более прогнозируемым.
Используйте разбиение на страницы, фильтрацию и сортировку при выборе коллекций записей. Представьте, что ваше API вырастет и будет отдавать больше записей, чем вы предполагали изначально. С этим, кстати, столкнулся известный сервис NVD, предоставляющий доступ к информации об уязвимостях, и разработчикам пришлось в итоге реализовать подобное ограничение.
Распределяйте параметры по эндпоинтам с учетом контекста данных и количества записей. Эта рекомендация затрагивает и вопросы безопасности (сокращение площади атаки), и вопросы управляемости (возможность предоставления большей части функций без большой переделки API).
Реализация базовых контролей безопасности: шифрование ответов, аутентификация, включение в ответы только необходимой информации.
Как проконтролировать процесс создания и функционирования API?
Здесь мы конечно не сможем обойтись без инструментария, но так или иначе весь он будет нацелен на обеспечение доверия тем этапам, которые мы ведем.
Документирование API, управление версиями API. Как база и основа, не только как элемент разработки, но также и хороший инструмент, с помощью которого можно встроить автоматическую проверку по контролям. Если есть OAS, можно увидеть, что хотели сделать, и что получилось в итоге в трафике к этому API.
Тестирование API. Если на вход подается OAS, то компонент ПроAPI Тест может провести все необходимые проверки. Таким образом мы понимаем, что API безопасен.
Фиксация OAS. Если API задокументирован и согласован, то его публикацию хорошо осуществлять через API Gateway, на котором ограничиваются вызовы всех функций, не указанных в документации. В линейке продуктов ПроAPI этим заведует компонент «ПроAPI Защита».
Мониторинг API. Желательно на всех стадиях смотреть, как изменяется API, чем спродюсированы эти изменения, насколько они корректны.
В заключение
Все, что мы разобрали выше, позволяет минимизировать уровень неизвестности относительно того, что происходит в ваших API. А чем меньше неизвестного, чем больше наблюдаемости, тем выше вероятность, что при атаке, неправильной работе или ошибках интеграции у вас будет больше информации для быстрого и корректного выхода из сложившейся ситуации.
ITSec_articles