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

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

1. Используйте токен для аутентификации личности пользователя.

Блок-схема аутентификации личности пользователя выглядит следующим образом:

20210124164442864.png

Конкретные инструкции заключаются в следующем:

① Когда пользователь входит в систему, клиент запрашивает интерфейс и передает имя пользователя и пароль.

② Сервер проверяет личность пользователя. Если проверка не пройдена, будет возвращен результат ошибки; если проверка пройдена, будет сгенерирован случайный неповторяющийся токен, который будет сохранен в redis (если мы возьмем пример redis, он также может храниться в БД, где находится он хранится конкретно на ваше усмотрение) и установите срок годности. Среди них ключом redis является токен, а значением — информация пользователя, полученная после прохождения проверки.

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

2. Используйте знак, чтобы предотвратить подделку входящих параметров.

Чтобы предотвратить атаки «человек посередине» (запросы клиента перехватываются и подделываются третьей стороной),или интерфейс вызывается ненадежной третьей стороной),Представляем параметрыМеханизм подписи。

Конкретные шаги заключаются в следующем:

① Клиент и сервер согласовывают алгоритм шифрования (например, шифрование md5 или шифрование sha1 или сначала шифрование md5, а затем шифрование sha1... обе стороны могут самостоятельно согласовать метод шифрования. Когда клиент инициирует запрос, Все ненулевые параметры соединяются вместе в порядке возрастания или убывания, формируются в знак с помощью алгоритма шифрования, объединяются в запросе и передаются на сервер.

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

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

2021012417375499.png

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

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

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

источник значения знака = Отсортируйте все непустые параметры в порядке возрастания (или Сортировать по убыванию)+токен+метка времени

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

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

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

Обобщенная блок-схема выглядит следующим образом:

123.png