Как обезопасить себя от атак по этому вектору, за которым плохо следят

Безопасность API — «отличный вход» в карьеру пентестера, считает Кори Дж. Болл, эксперт в отрасли.

ИНТЕРВЬЮ. Обеспечение безопасности веб-API требует иного подхода, чем классическое обеспечение безопасности веб-приложений, поскольку стандартные тесты обычно упускают наиболее распространённые уязвимости, возникающие при работе с API.

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

Болл начинал осваивать искусство пентестинга веб-приложений ещё в 2015 году по хакерским книгам, а также ресурсам HackTheBox и VulnHub. Далее он оттачивал навыки работы с компьютерами, пользуясь Cold Fusion, WordPress, Apache Tomcat и другими веб-приложениями, ориентированными на использование на большом предприятии.

В дальнейшем он сдал экзамены на сертификаты CEH, CISSP и OSCP и, наконец, был приглашён на руководящую работу в области пентестинга в публичной аудиторской фирме «Мосс Адамс», где до сих пор занимает пост ведущего пентестера веб-приложений.

Недавно он сосредоточился на изучении более узкой области, а именно на безопасности веб-API, которой занимаются в основном по остаточному принципу. Поэтому Болл запустил бесплатный онлайн-курс на эту тему, а также опубликовал книгу Hacking APIs: Breaking Web Application Programming Interfaces (No Starch Press, 2022).

В интервью сайту The Daily Swig Болл рассказывает, как из-за всё более активного использования веб-API требуется пересмотреть традиционные подходы к защите веб-приложений.

Привлекательный вектор атаки

В последние несколько лет активизировалось внедрение веб-API в различных секторах. В 2018 году компания Akamai сообщила, что на вызовы API приходится 83% веб-трафика.

«Бизнес пришёл к пониманию, что теперь можно обойтись и без самообеспечения и не разрабатывать самим абсолютно все аспекты веб-приложения (карты, обработку платежей, коммуникацию, аутентификацию, т.д.)», — говорит Болл. — «Вместо этого можно воспользоваться API и тем вкладом, который уже сделали в него сторонние разработчики, а самим сосредоточиться на специализации».

API означает «интерфейс прикладного программирования». Это набор определений и протоколов для разработки и интеграции прикладного софта.

Веб-API, для доступа к которым используется протокол HTTP, во множестве породили API-сервисы, позволяющие монетизировать их технологии, инфраструктуру, функциональность и данные. Но в то же время API стали пользоваться интересом у киберпреступников.

«Через небезопасные API можно скомпрометировать конфиденциальность, целостность и доступность данных», — говорит Болл, — «потенциальные возможности такого рода вызывают ещё большее беспокойство потому, что многие API обращены в Интернет. Поэтому уязвимые API — это один из наиболее удобных векторов атаки».

Здесь действуют другие правила

API могут причинять меньше головной боли, если привлекать специалистов по безопасности к процессу проектирования этих интерфейсов. Речь о коллегах, которые будут прививать осторожный подход к программированию, регулярно проводить проверки безопасности и отслеживать, не используются ли вызовы программы для атак и других злоупотреблений.  специалистов по безопасности become less of a liability by including security-focused team members

Болл считатет, что защита веб-API требует нового подхода к классической безопасности веб-приложений.

«Если ограничиться стандартным тестированием веб-приложений, то такие проверки, применяемые с веб-API, дадут много ложноотрицательных результатов», — объясняет он, — «инструменты и приёмы, не откалиброванные специально для работы с веб-API, пропустят почти все распространённые уязвимости».

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

В ходе тестирования применялись такие инструменты как Nessus и HP WebInspect, которые делают общий анализ тестируемых целей — именно поэтому серьёзная уязвимость веб-API и прошла незамеченной. Этот невыявленный пробел в безопасности USPS Informed Visibility API открывал любому пользователю, прошедшему аутентификацию, доступ к адресам электронной почты, логинам, обновлениям пакетов, адресам почтовых рассылок и телефонным номерам 60 миллионов клиентов, записанных в базе.

«Оценка степени уязвимости внешнего контура атаки в системе Informed Visibility отлично демонстрирует, чего можно добиться, применяя к API техники взлома веб-приложений», — говорит Болл. —«В данном случае важно усвоить, что при тестировании API нужно правильно подбирать инструменты и приёмы».

Атаки по сторонним каналам при взломе API

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

Как правило, API должен отклонять все неавторизованные запросы и возвращать в ответ стандартный  HTTP-код 401 «не авторизован». Поскольку на исследуемом API не было предусмотрено ограничение скорости обработки, Болл смог отправить множество запросов и протестировать различные ID и имена пользователей, собранные в процессе пассивной разведки. Исследователь безопасности выяснил, что в некоторых ответах немного больше байт, чем в других.

«При более тщательном рассмотрении (с использованием Comparer) стало понятно, что по заголовку промежуточного ПО можно выяснить, насколько больше времени сервер тратил на обработку определённых запросов. Я обнаружил такие запросы к уже существующим записям, на обработку которых сервер тратил в пять раз больше времени, чем на обработку несуществующих записей».  

Собирая вместе разрозненные частицы информации, Болл также смог собрать конфиденциальные данные и сопоставить пользователей с их ID, почтовыми кодами, телефонными номерами, медицинскими полисами и номерами социального страхования.

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

Цена возможности

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

 «Не существовало книг, где фокус делался бы на тестировании безопасности API, этот навык не сертифицировался, почти не было статей в блогах [или] видео», — говорит он, — «я отправлялся на конференции и прямо спрашивал у спикеров, выступавших с докладами о новейших приёмах взлома веб-приложений, а каким образом они тестируют безопасность API? Они либо понятия не имели, что делать с API, либо в их команде находился в лучшем случае один специалист по тестированию API».

Один из управляющих партнёров в компании «Moss Adams» вдохновил Болла стать экспертом в теме API. За несколько месяцев Болл исправно собрал примерно 150 страниц заметок на эту тему, прежде, чем осознал, что уже наполовину написал книгу по безопасности API.

«Я увидел в этом возможность поделиться моими исследованиями, вооружить тестировщиков и помочь предотвратить следующую утечку данных, которая произойдёт через API», — говорит он, — «я связался с издательством  No Starch Press. Так началась эта история».

Ball также выпустил бесплатный онлайновый курс на сайте APIsec University. В рамках этого курса рассказывается о различных фазах пентестинга API, о настройке лабораторного стенда, о том, как производится разведка, анализируются конечные точки и поэтапно выстраиваются различные атаки.

Дни UnAPI

Постепенно оформляются ресурсы и стандарты, описывающие безопасность API. В частности, в рамках Open Source Web Application Project (OWASP) в 2019 году были опубликованы топ-10 уязвимостей API.

Но Болл по-прежнему наблюдает, как в Интернете продолжают распространяться типичные ошибки в проектировании API. «Именно с авторизацией по-прежнему связаны основные ошибки в несоблюдении безопасности API, встречающиеся в природе», — говорит он.

Ему часто попадаются примеры нарушения авторизации на уровне объектов и уровне функций. Оба этих примера — в вышеупомянутом топ-листе от OWASP. В большинстве случаев эти уязвимости проявляются так: пользователь, прошедший аутентификацию, получает через API не положенный ему доступ к данным других пользователей.

«При таком преобладании связанных с авторизацией уязвимостей API складывается впечатление, что мы одновременно слишком доверяем полноправным пользователям, и недостаточно тщательно проверяем, могут ли отдельные пользователи или группы обращаться к данным друг друга и изменять их», — говорит Болл.

Баг в шлюзе

По мере того, как API распространяются всё шире, всё сильнее растёт потребность в экспертах по безопасности API.

«Я считаю, что API — на самом деле, отличный вход в профессию для всех, кому интересно стать пентестером. Пожалуй, современные хакеры в первую очередь пытаются взломать именно API», - говорит Болл.

Где научиться безопасности API? Болл предлагает следующие ресурсы:

• Курс API Penetration Testing на сайте APIsec University

• Web Security Academy компании Portswigger

• OWASP API Security Project

«Как следует познакомьтесь с Postman и инструментарием Burp», — советует Болл. — «Естественно, если вам удобнее взять всю эту информацию в одном источнике, то посмотрите мою книгу «Hacking APIs».

Приобрести книгу «Хакинг API: взлом программных интерфейсов веб-приложений» можно на Wildberries.