Разговор о методе подписи API

Безопасность
Разговор о методе подписи API

предисловие

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

  • Незаконное использование API-сервисов. (Недопустимый вызов интерфейса зарядки)
  • Злонамеренные атаки и саботаж. (Подделка данных, DOS)

Следовательно, необходимо разработать некоторые методы защиты интерфейса для повышения безопасности интерфейса.Сертификаты SSL могут быть добавлены на транспортном уровне и могут быть добавлены HTTPS.На прикладном уровне это в основном достигается за счет некоторой логики шифрования. Текущие основные два добавляют информацию для аутентификации и подписи API в заголовок HTTP.

Простая HTTP-аутентификация

Добавьте поле аутентификации в заголовок HTTP-запроса, например:

Authorization: 3F2504E04F8911D39A0C0305E82C3301

Удалите это поле перед обработкой сервером и проверьте его.

Проект Spring Boot напрямую реализует перехватчик для оценки:

String token = request.getHeader("Authorization");
if (!Strings.isNullOrEmpty(token)) {
    hasAuth = redisTemplate.hasKey("userToken:" + token);
}

Этот тип метода относительно прост в реализации и может выполнять базовую аутентификацию личности, предотвращая джентльменов, но не злодеев, и получая авторизацию с помощью атак «человек посередине». Использование HTTPS повысит безопасность, но не защитит от повторных атак, таких как DDOS.

Аутентификация подписи API

Метод подписи API намного сложнее предыдущего, но и решает больше проблем с безопасностью:

  • Законность запрашивающего может быть проверена.
  • Целостность параметров может быть проверена и не были ли они подделаны.
  • Вы можете предотвратить атаки воспроизведения.

Часть1: Шифрование на стороне запроса

Пользователи API получат два секретных ключа, ak и sk, выдаваемые сервером: ak — открытый ключ, а sk — закрытый ключ.

Подпись имеет следующие правила:

  1. Согласовано, что запрос будет содержать ak в качестве параметра и помещать его в заголовок HTTP.
  2. Обработка параметров запроса:
    • ПОЛУЧИТЬ: Извлеките все параметры, отсортируйте их лексикографически по ключу и соберите в следующем формате.
    • ПОСТ: Если этоapplication/x-www-form-urlencoded, напрямую извлечь и ПОЛУЧИТЬ параметры для сортировки и объединения, если даapplication/json, затем напрямую зашифруйте всю строку json md5, а затем base64.
GET:
strToSign = uri + "\n" + ak=ak&k1=v1&k2=v2&k3=v3
POST:
strToSign = uri + "\n" + ak=ak&k1=v1&k2=v2&k3=v3 + "\n" + base64(md5(json_body))
  1. Используйте алгоритм HMACSHA256 для перехода к SK для расчета подписи,sign = base64(HmacSHA256(K,strToSign)),вK=sk.
  2. Соберите HTTP-запрос,X-Ca-Key=ak,X-Ca-Signature=signДобавить в заголовок HTTP для запроса.

Простой пример показан на следующем рисунке:

часть 2: расшифровка сервера

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

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

Сделайте еще один шаг вперед

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

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

Однократное использование временной метки может в определенной степени снизить частоту повторных атак, но полностью сдержать их невозможно.

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

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

часть 1: запрашивающая сторона генерирует временную метку и одноразовый номер

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

Запишите метку времени и одноразовый номер в заголовок HTTP.

часть 3: Проверка сервера

  1. Существует ли NONECE в запросе к базе данных (Redis рекомендуется с собственной функцией TTL).
  2. Если нет существования, и время запроса действительна, это юридический запрос, и NONCE написан, и время записано; если нет существования, и время запроса превышает указанный срок, он определяется как вредоносный запрос.
  3. Если он уже существует, он оценивается как злонамеренный запрос.

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

Подписание API и HTTPS

Я также хотел бы упомянуть здесь HTTPS. Я видел вопрос на Quora раньше:Нужно ли после использования https подписывать данные, чтобы гарантировать, что данные не были подделаны?

Подвести итог:

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

  • HTTPS гарантирует зашифрованную передачу на транспортном уровне, но не может защитить от повторных атак.

Другими словами, HTTPS гарантирует, что пакеты, захваченные атаками «человек посередине», являются зашифрованными текстами, которые невозможно или трудно взломать. Тем не менее, сообщение все еще может быть отправлено повторно для формирования DDOS. При этом, если нет подписи, используется только простая HTTP-аутентификация, а Авторизацию можно получить напрямую, перехватив пакеты, а затем можно инициировать запросы по желанию. Поэтому самый безопасный способ — совместить подпись HTTPS и API.

Суммировать

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

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

исходный код

использованная литература

Категории