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

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

Цель состоит в том, чтобы предотвратить атаку на сам API, и вам следует подумать о каждой «точке соприкосновения» на длине пути API.

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

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

Этот раздел будет посвящен безопасности данных и оценке различных механизмов защиты данных.

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

Первое, что вам нужно сделать, это всегда использовать шифрование TLS / HTTPS и не создавать самозаверяющие сертификаты.

Безопасность API - это все, что касается аутентификации, авторизации и векторов атак.

Аутентификация

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

Базовая проверка подлинности и авторизация имеют прямую направленность, все это обрабатывается в заголовке HTTP, куда вы можете добавить закодированные учетные данные и комбинацию user:password для проверки. Если все в порядке, он вернет код состояния HTTP 200, в противном случае произойдет сбой. Находится так:

Заголовок HTTP: Authorization: [Encoded-Base64 creds = user:password]

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

Базовая аутентификация - старый механизм, и в нем есть недостатки.

  1. В идеале вам нужно использовать HTTPS для зашифрованной связи
  2. Вам необходимо отправлять учетные данные для каждого запроса, потому что HTTP для API не имеет состояния, это означает, что сеансы не реализуются.
  3. Если вы реализуете базовую аутентификацию в мобильном приложении, ваши учетные данные должны храниться на устройстве, это представляет большой риск.

JWT

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

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

Распространенным программным подходом к управлению токенами является использование JWT или веб-токенов JSON, этот механизм является самодостаточным на основе нотации JSON (очевидно), которая определяет общую структуру для токенов.

Он состоит из трех частей:

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

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

Подробное техническое объяснение можно найти на сайте jwt.io.

Если вы знакомы с NodeJS и JavaScript, вы можете этот пакет NPM для лучшего понимания.

Ключи и секреты API

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

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

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

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

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

Атаки, атаки, атаки…

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

Проблемы безопасности можно решить в мире API.

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

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

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

Пришло время использовать все эти аспекты и приступить к созданию следующего API на миллион долларов.

Удачного кодирования :)