Опасные связи: чем тестировать API и почему это важно

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

Мнение экспертов подтверждают громкие инциденты. Среди последних – кибератака на системы обмена информацией между странами Евросоюза и кража персональных данных 37 млн клиентов у телеком-гиганта T-Mobile. В обоих случаях хакеры использовали уязвимость в API. 

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

Что такое API

API, или Application Programming Interface, – это интерфейс программирования приложений. Он включает в себя инструменты и правила, благодаря которым одна программа может взаимодействовать с другой. 

API помогает разработчикам расширять возможности своих продуктов и интегрировать их с другими. Благодаря ему, например, мобильное приложение для доставки цветов использует гугл-карты, а пользователь интернет-магазина покупает товары без перехода в приложение банка.

Программы для тестирования API

Выбор инструментов тестирования API зависит от множества параметров. Один из них – язык, на котором разрабатывается основной продукт. Например, если используется Java, то стоит присмотреться к REST-Assured. Утилита легко интегрируется с любым приложением для автотестирования на этом языке. Также, если нужно автоматизировать процесс, можно обратить внимание на Citrus Framework, Katalon Studio или Assertible.

Если практики или желания заниматься автотестами нет, то может быть достаточно приложения Postman. Эта программа для тестирования API раньше была плагином Chrome. Сегодня она легко работает в приложениях для Mac, Windows, Linux. У Postman есть альтернатива – Postwoman, с которой можно проводить API-тестирование онлайн.

Такой же простой в использовании, как и предыдущие два, инструмент – Insomnia. Функциональность, по большому счету, та же, что и в Postman.

Еще одна популярная утилита – SoupUI. Вариант подходит, если приходится анализировать и отрабатывать сложные сценарии пользовательского поведения. В этом инструменте тестирования API можно не только гибко настроить тесты, но и добавить свой функционал. 

Помимо SoupUI, QA-специалисты часто используют JMeter. И хотя это приложение изначально создавали для нагрузочного тестирования, сейчас его активно применяют для функциональных проверок. 

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

Алексей Яковлев

Ведущий продуктовый маркетолог аутсорсинговой компании MIMINO

Чтобы более эффективно проверять риски информационной безопасности при тестировании API, QA-специалисты могут использовать различные инструменты, такие как Burp Suite, Postman, SoapUI, OWASP ZAP и другие. 

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

Что именно и для чего тестировать

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

Наиболее важные риски ежегодно вносят в список Топ-10 проблем API от OWASP. Обычно первые места в нем занимают уязвимости, связанные с аутентификацией пользователей. 

Сергей Полунин

Руководитель группы защиты инфраструктурных ИТ компании «Газинформсервис»

Именно проблемы с аутентификацией позволяют использовать ваш API бесконтрольно. При этом никуда не деваются и трудности с отсутствием логирования, или, например, инъекции кода. 

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

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

Михаил Черкашин

Руководитель направления AppSec компании Innostage

К примеру, в 2018 году нашли уязвимость в API крупного автопроизводителя. Через нее можно было удаленно открывать двери в машинах и запускать двигатель. А в 2020 году обнаружили уязвимость в системе быстрых платежей, через которую можно было подменять счета отправителей платежей. 

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

Филипп Щиров

Директор сервиса для работы в 1С через интернет «Альтап»

В частности, важен защищенный протокол передачи данных — в подавляющем большинстве случаев HTTPS. Он позволяет шифровать все данные, которые передаются между клиентом и сервером.

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

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

Кто выбирает приложения для тестирования API

Как правило, инструменты тестирования API использует в работе QA-инженер. Должен ли специалист ИБ заниматься такими задачами? Эксперты считают, что да. Но ответ чаще зависит от кейса, конкретной компании и того, какие требования предъявляются к основному программному продукту. 

Екатерина Федина

Руководитель проектов тестирования iiii Tech

Безусловно, команде тестирования во время работы с API (и не только) стоит уделять внимание как минимум базовым проверкам безопасности, например, возможным SQL-инъекциям и XSS-атакам. 

Но если у вас довольно высокие требования к безопасности, а сам продукт обширный, то лучше нанять отдельного специалиста по ИБ или воспользоваться услугами сторонней организации.

С Екатериной Фединой также согласны другие эксперты. Они считают, что участие специалистов ИБ в тестировании даже может быть лишним. 

Петр Арапов

Специалист по тестированию компании «Датаномика»

Если тестируется небольшой API с вручную выдаваемым токеном, рассчитанный на несколько тысяч запросов в неделю, то QA-специалисту в связке с разработчиком не составит труда найти бутылочное горлышко и протестировать его.

Другое дело – большие компании с десятками, а то и сотнями продаваемых сервисов (внешних, публичных API). Для таких продуктов одного желания QA-специалиста узнать, что такое пентестинг, будет явно недостаточно, потому что он не сможет обойтись общими метриками, сценариями и знаниями.

В любом случае, помощь специалиста ИБ коллегам важна всегда. Даже если она касается только вопросов терминологии или предметной области.

Денис Исангулов

Руководитель отдела тестирования NGR Softlab

QA-специалист должен проверять риски кибербезопасности при тестировании API, так как это поможет выявить уязвимости и предотвратить возможные атаки на систему. При этом специалисту по информационной безопасности тоже важно быть вовлеченным в процесс тестирования, чтобы предоставить дополнительную экспертизу в предметной области.

ИБ-специалист способен помочь QA-специалисту более детально разобраться с подходом к тестированию. А позже – помочь устранить обнаруженные уязвимости. 

Иногда от специалиста ИБ требуется больше, чем консультации. И тогда часть проверок он может проводить сам.

Дмитрий Тишкин

Руководитель команды Application Security R-Vision

На мой взгляд, QA, может и должен проверять риски кибербезопасности при тестировании API, но делать это нужно в тесной связке с ИБ-экспертами, которыми чаще всего являются AppSec-специалисты (Application Security). Таким образом, часть тестирования возьмут они, а часть – QA.

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

Михаил Черкашин

Руководитель направления AppSec компании Innostage

ИБ-специалисты должны верифицировать дизайн API, закладывать принцип security by design для команд разработки. А тестировщики должны все это проверять по заранее разработанному плану проверки на безопасность. 

Михаил Черкашин добавляет: принципы безопасности всегда лучше закладывать еще на этапе разработки. Это позволяет сэкономить на средствах защиты. Хотя коллеги рекомендуют смотреть на процесс еще шире. 

Сергей Полунин

Руководитель группы защиты инфраструктурных ИТ компании «Газинформсервис»

Грамотное построенное тестирование на этапе разработки – это половина дела. Потребуется еще грамотно организовать доступ клиентов к этому API, например используя межсетевой экран уровня приложений, который имеет функционал защиты API. 

Полезно также, по мнению Сергея Полунина, проводить регулярные тестирования на проникновения, потому что взлом API или даже обнаружения в нем каких-то логических изъянов – это почти наверняка компрометация всей инфраструктуры приложения и даже угроза для пользователей.

Итоги 

Как именно и чем тестировать API, в компании решают двое – QA-инженер и ИБ-специалист. Особенно такое сотрудничество важно сейчас, когда атаки на программный интерфейс приложений становятся более частыми и масштабными. 

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