AccessKey&SecretKey (Открытая платформа)

запросить личность

Назначьте AccessKey (идентификатор разработчика, для обеспечения уникальности) и SecretKey (для шифрования интерфейса, чтобы гарантировать, что его не просто исчерпать, а алгоритм генерации непросто угадать).

Защита от несанкционированного доступа

подпись параметра

Расположите непустые параметры запроса (включая AccessKey) в возрастающем алфавитном порядке имен параметров запроса и используйте формат пары ключ-значение URL (т. е. ключ1=значение1&ключ2=значение2...) для вставки в строку stringA;
Объединение Secretkey в конце stringA для получения строки stringSignTemp;
Выполните операцию MD5 над stringSignTemp и преобразуйте все символы результирующей строки в верхний регистр, чтобы получить значение знака.

Запрос содержит параметры AccessKey и Sign, и только при наличии юридического идентификатора AccessKey и правильной подписи Sign он может быть выпущен. Это решает проблемы аутентификации и подделки параметров.Даже если параметры запроса украдены, так как невозможно получить SecretKey (используется только для локального шифрования и не участвует в передаче по сети), невозможно подделать легитимные запросы.

повторить атаку

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

схема timestamp+nonce

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

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

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

выполнить

Интерфейс запроса:API.test.com/test?Тогда = также…

клиент

Генерировать текущую метку времени timestamp=now и уникальную случайную строку nonce=random
Упорядочить непустые параметры запроса в возрастающем алфавитном порядке имен параметров запроса (включая AccessKey) stringA="AccessKey=access&home=world&name=hello&work=java×tamp=now&nonce=random";
Ключ соединения SecretKeystringSignTemp="AccessKey=access&home=world&name=hello&work=java×tamp=now&nonce=random&SecretKey=secret";
MD5 и преобразовать в верхний регистр sign=MD5(stringSignTemp).toUpperCase();
окончательный запросAPI.test.com/test?Тогда = также…;

Сервер

拒绝接口裸奔！开放API接口签名验证

Токен и ключ приложения (приложение)

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

Токен аутентификации

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

Проверка подписи Token+AppKey

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

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

выполнить

Запросы на вход и выход

拒绝接口裸奔！开放API接口签名验证

Процесс входа и выхода

дополнительный запрос

клиент

Подобно поведению клиента вышеописанной открытой платформы, просто измените AccessKey на токен.

Сервер

拒绝接口裸奔！开放API接口签名验证

серверный процесс