Каждая pull request Добавление или изменение конечной точки меняет поверхность атаки вашего API. Большинство инструментов обеспечения безопасности API не замечают этого до тех пор, пока эта конечная точка не будет запущена и не начнет принимать трафик. К тому времени исправление уже не сводится к изменению одной строки кода в ходе проверки, а превращается в обсуждение реагирования на инцидент.
Безопасность API — это практика выявления и устранения рисков, связанных с тем, как приложение предоставляет свои конечные точки: кто может их вызывать, какие данные они возвращают и выполняют ли они то, что указано в документации.
Большинство инструментов, разработанных для решения этой проблемы, тестируют API во время выполнения, извне, так же, как это делал бы злоумышленник. Такой подход работает, но только после развертывания API. Ксигени Он выбирает предыдущий путь: он считывает ваш исходный код и спецификацию API до того, как хотя бы один запрос достигнет конечной точки.
Четыре способа тестирования API и ответы на каждый из них.
В большинстве зрелых программ используется более одного из этих методов:
- Статическое тестирование Анализирует исходный код и спецификации API перед развертыванием. Он отвечает на вопрос: «Что мы только что раскрыли?» Именно на таком подходе сосредоточена данная статья.
- Динамическое тестирование (DAST) Он отправляет реальный трафик на работающий API и наблюдает за его реакцией. Он отвечает на вопрос: «Что на самом деле доступно и может быть использовано в своих целях прямо сейчас?»
- Fuzzing Он выдает некорректные или неожиданные входные данные на конечные точки, что приводит к сбоям и ошибкам в крайних случаях. Он отвечает на вопрос: «Что может сломаться при поступлении непредвиденных входных данных?»
- Ручное тестирование на проникновение Добавляет человеческий фактор для выявления логических ошибок, которые пропускают автоматизированные инструменты. Это дает ответ на вопрос: «Какие цепочки действий мог бы объединить умный злоумышленник?»
Ни один из них не заменяет другие. Они отвечают на разные вопросы на разных этапах жизненного цикла, и пробел, который существует в большинстве программ, — это первый из них.
Почему большинство инструментов обеспечения безопасности API видят риски слишком поздно
Тестирование безопасности API во время выполнения отправляет трафик в работающее приложение и наблюдает за его реакцией. Это законный и необходимый уровень. Кроме того, по своей сути это запаздывающий индикатор: конечная точка должна существовать, быть развернута и доступна, прежде чем сканер во время выполнения сможет что-либо о ней сказать. Все, что он обнаружит, уже было доступно в течение времени, необходимого для выполнения сканирования.
За этой проблемой синхронизации скрывается ещё один пробел. Инструменты выполнения могут проверять только то, что им известно о существовании. Если конечная точка никогда не была задокументирована, или спецификация OpenAPI устарела в тот момент, когда кто-то выпустил новый маршрут, сканер во время выполнения никак не сможет узнать о её существовании. Он проверяет карту, а не территорию.
Статическое тестирование безопасности API устраняет обе уязвимости, перенося проверку туда, где определена конечная точка: в ваш код и спецификацию API, до развертывания. Тот же самый pull request Вводящая конечную точку — это pull request это выявляет его риски.
Что на самом деле означает статическая безопасность API?
Xygeni формирует ваш API-каталог из двух источников: исходного кода вашего приложения и спецификаций API, включая OpenAPI и Swagger.
Инвентаризация, содержащая только спецификацию, показывает конечные точки, которые кто-то вспомнил задокументировать. Инвентаризация, содержащая только код, показывает то, что существует, но не обязательно то, как это предполагалось использовать. Чтение обеих инвентаризаций дает полную картину: конечные точки, которые ваши команды задокументировали, и те, которые никто не задокументировал.
Этот перечень — основа, на которой строится все остальное:
- Общее количество обнаруженных API и активы, подверженные риску, измеренные относительно базового уровня.
- Конечные точки разбиты по методам HTTP.
- Вопросы, сгруппированные по видам услуг.
- Каждая конечная точка с указанием метода, пути, сервиса, модуля, состояния аутентификации и оценки риска.
Ваши ведущие инженеры видят структуру вашего API без создания каких-либо заявок в службу поддержки.
Каждая обнаруженная Xygeni конечная точка, включая метод, состояние аутентификации и оценку риска, была сформирована на основе кода и спецификации.
Production note Вырежьте панель AI Triage из любого скриншота безопасности API.
Соответствует списку 10 самых важных пунктов по безопасности API OWASP.
Полученные результаты подтверждают эффективность используемой вашими командами безопасности и аудиторами методологии. Xygeni выявляет риски в рамках стандарта OWASP API Security. Топ 10 (2023 г.):
Одна категория намеренно отсутствует. API6, «Неограниченный доступ к конфиденциальным бизнес-процессам», требует понимания того, что должен разрешать бизнес-процесс, и ни один статический анализатор не может это достоверно обнаружить. Любой поставщик, утверждающий обратное, просто продает вам галочку. Этот пункт останется в компетенции ваших специалистов по моделированию угроз и тестировщиков на проникновение.
Не все результаты одинаково полезны: чувствительность данных и токсичные сочетания.
При использовании простого списка обнаруженных проблем, неаутентифицированная конечная точка проверки работоспособности рассматривается так же, как и неаутентифицированная конечная точка, возвращающая записи о клиентах. Это разные проблемы, и модель приоритезации, которая оценивает их одинаково, обучает ваши команды игнорировать этот список.
Xygeni классифицирует данные, обрабатываемые каждой конечной точкой, помечая персональные данные (PII), данные PCI и PHI в параметрах запроса и в ответах, и сопоставляет это с состоянием аутентификации конечной точки.
Он также сопоставляет результаты, полученные на одной и той же конечной точке, и повышает степень серьезности, когда они суммируются. Утечка персональных данных в ответе сама по себе является серьезным нарушением. Та же самая утечка на конечной точке, не требующей аутентификации, является критической, и платформа оценивает ее именно так, вместо того чтобы оставлять возможность обнаружения связи кому-либо вручную.
«Зомби- и сиротские» конечные точки: разрыв между кодом и спецификацией
Поскольку Xygeni читает ваш код и спецификацию API одновременно, он видит, где они расходятся. Это расхождение проявляется в виде трех узнаваемых закономерностей:
- Недокументированные конечные точки. Они существуют в коде и никогда не были включены в спецификацию.
- Конечные точки зомби. Они помечены как устаревшие или выведенные из эксплуатации, но при этом остаются доступными.
- «Сиротские» конечные точки. Никто из нынешней команды ими не владеет.
Ни один из этих предметов не отображается в инвентаре, содержащем только характеристики, потому что именно в характеристиках они и отсутствуют.
Доказательства, на основании которых можно принять меры, а не протокол о начале расследования.
Каждая обнаруженная уязвимость указывает на конкретный обработчик, ответственный за её возникновение: файл, класс, метод и конкретную строку кода, внесшую ошибку, с соответствующим отображением кода. Каждая из них также имеет свою степень серьезности, категорию OWASP API Security Top 10, CWE (Certified WealthError), состояние аутентификации конечной точки и классификацию конфиденциальности задействованных данных.
Обнаружение, указывающее лишь на конечную точку, заставляет разработчика просматривать весь код еще до того, как он сможет что-либо исправить. Обнаружение, указывающее на строку кода, сразу же указывает на место, где нужно исправить ошибку.
Результаты экспортируются в форматы JSON, CSV, Markdown и SARIF 2.1.0, поэтому они попадают в нужный раздел.инструменты, в которых ваши команды уже работают.
Обработчик, строка кода и сам код, приведшие к уязвимости. Это не заявка на расследование.
Почему это доступно только на одной платформе, а не на другой консоли?
Xygeni обеспечивает безопасность API параллельно с другими функциями. SAST, SCA, Секреты безопасности, IaC и ДАСТ внутри единой платформы, взаимосвязанные посредством ASPM, вместо того, чтобы поставлять его как отдельный инструмент со своим собственным login и собственный список невыполненных задач.
Это важно, потому что статические и динамические результаты отвечают на разные вопросы об одной и той же конечной точке, и они более полезны вместе, чем по отдельности. Статические данные показывают, что конечная точка опасна до её запуска. DAST подтверждает, что на самом деле доступно и может быть использовано в злоумышленных целях после запуска.
Разделите это на две консоли, и коррелированный риск превратится в два несвязанных списка задач. Никто их не согласует, и конечная точка, которая одновременно не документирована и не аутентифицирована, не окажется ни в одной из очередей.
Узнайте о реальной уязвимости вашего API. API Security доступен в качестве Enterprise Это дополнение к платформе Xygeni, которое запускает сканирование ваших собственных репозиториев внутри вашей собственной инфраструктуры.
FAQ
Может ли система определить, какие конечные точки обрабатывают конфиденциальные данные?
Да. Xygeni помечает персональные данные, данные о пациенте и информацию о здоровье пациентов в параметрах и ответах конечных точек и использует эту классификацию для ранжирования результатов в зависимости от реального воздействия.
Может ли это работать на каждом устройстве? pull request?
Да. Инкрементальное сканирование анализирует только те конечные точки, которые изменились, и созданный им манифест может сфокусировать последующее сканирование DAST на тех же конечных точках, поэтому статическое и исполняемое тестирование остаются согласованными с тем, что фактически изменилось.
Выходит ли мой код за пределы моей среды выполнения?
Нет. Сканирование выполняется в вашей собственной инфраструктуре. Загружаются только результаты, которые защищены как при передаче, так и в состоянии покоя.
Как мне получить доступ к API Security?
API Security доступен в качестве Enterprise Дополнение. Запросите подтверждение концепции (PoC), и мы согласуем с вами объем работ.
