Рекомендации
по безопасности API
для защиты ваших данных. Часть 2

API (Application Programming Interface) — это интерфейс программирования приложений. Внедрение API помогает  разработчикам расширять функциональность своего продукта и интегрировать его с другими.

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

В этой части нашей статьи мы продолжим делиться советами по безопасности, а также подробно расскажем о возможных видах тестирования безопасности API.

Рекомендации по безопасности API

1. Регистрируйте активность API

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

2. Проводите тесты безопасности

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

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

Тестирование безопасности API

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

Вам необходимо разработать сценарии, которые будут отвечать на следующие вопросы:

  1. Могут ли пользователи, которые прошли проверку подлинности, получить доступ к вашим конечным точкам?
  2. Предоставляется ли пользователям доступ только к необходимым конечным точкам в зависимости от их роли?
  3. Возвращается ли правильная информация в ответах на каждый потенциальный запрос?
  4. Отклоняются ли достоверные, но недействительные запросы?

После того, как вы установите, что ваш API работает нормально, вам необходимо смоделировать атаки внедрения кода, MITM, DoS и кражи паролей против ваших систем в тестовой среде. В своих тестах обратите внимание на следующее:

  1. Может ли текущая аутентификация противостоять попыткам входа методом подбора?
  2. Как API обрабатывает большое количество входящих запросов?
  3. Что происходит, когда аутентифицированный пользователь отправит вредоносный скрипт или файл через запрос?
  4. Все ли передачи данных зашифрованы? Запрещены ли запросы без TLS/SSL (т.е. с HTTP, а не HTTPS)?
  5. Что происходит, если запрос или ответ перехвачены? Как API и пользователь узнают об этом?

Ниже рассмотрим некоторые конкретные тесты, которые вы можете запустить.

1. Тест аутентификации пользователя

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

Чтобы проверить свои механизмы аутентификации, попробуйте отправлять запросы API без надлежащей аутентификации (либо без токенов или учетных данных). 

2. Тест на изменение параметров

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

3. Тест на внедрение

Чтобы проверить, уязвим ли ваш API для внедрений попробуйте внедрить SQL, NoSQL, LDAP, ОС или другие команды во входные данные API и посмотрите, выполняет ли их ваш API. Эти команды должны быть безвредными, как команды перезагрузки или команды cat. 

4. Тест необработанных HTTP-методов

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

Чтобы протестировать эту уязвимость, вам необходимо попробовать все распространенные методы HTTP (POST, GET, PUT, PATCH и DELETE). 

Вы можете, например, отправить запрос API с глаголом HEAD вместо GET — если ваш API работает нормально, то вы получите код ошибки. 

5. Тест на размытие

Тест на размытие имитирует Overflow и DDoS-атаки. Для этого тестирования вам необходимо отправить большое количество различных запросов, включая SQL-запросы, системные команды, произвольные числа и другие символы. 

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


Источник: hubspot.com 

Условия передачи информации

Я даю согласие OOO «ЭсБилдер» (далее «BINN») на обработку моих персональных данных в соответствии со статьями 6, 9, 10, 18 Федерального закона от 27 июля 2006 года № 152-ФЗ «О персональных данных», указанных в онлайн-форме и/или предоставленных мною с целью:

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

Настоящее согласие применяется в отношении обработки следующих данных: имя, номер телефона, адрес электронной почты (E-mail).

Настоящее согласие предоставляется сроком на пять лет. По истечении указанного срока действие согласия считается продленным на каждые следующие пять лет при отсутствии сведений о его отзыве.

Согласие может быть отозвано мною в любой момент путем направления в BINN подписанного мною письменного заявления.