Implementación de firma de interfaz

Al proporcionar una interfaz para un sistema de terceros, debe considerar la seguridad de los datos de la interfaz, como si los datos han sido manipulados, si están desactualizados, si la solicitud es única, si los datos se pueden enviar repetidamente, etc. Es relativamente importante si los datos han sido alterados.

La solicitud lleva los parámetros appid y sign. Sólo se puede liberar el appid de identidad legal y el signo de firma correcto. Esto resuelve el problema de la autenticación de identidad y la manipulación de parámetros. Incluso si los parámetros de la solicitud son secuestrados, dado que no se puede obtener el secreto (solo se usa para el cifrado local y no participa en la transmisión de la red), es imposible falsificar una solicitud legítima. .

Usar solo appid y sign resuelve el riesgo de que se alteren los parámetros de la solicitud, pero también existe el riesgo de reutilizar los parámetros de la solicitud para falsificar solicitudes secundarias.

El nonce hace referencia a una cadena aleatoria única que se utiliza para identificar cada solicitud firmada. Al proporcionar un identificador único para cada solicitud, el servidor puede evitar que la solicitud se use varias veces (registrando todos los nonces usados ​​para evitar que se usen dos veces).

Sin embargo, el coste para el servidor de almacenar permanentemente todos los nonces recibidos es muy alto. La marca de tiempo se puede utilizar para optimizar el almacenamiento nonce.

Suponga que se permite que la diferencia horaria entre el cliente y el servidor sea de hasta 10 minutos y que se realiza un seguimiento del conjunto de nonce registrado en el servidor. Cuando llega una nueva solicitud, primero verifique si la marca de tiempo transportada está dentro de los 10 minutos. Si excede el rango de tiempo, rechácela. Luego verifique el nonce transportado si existe (lo que indica que la solicitud es la segunda solicitud). él. De lo contrario, registre el nonce y elimine el nonce con una marca de tiempo superior a 10 minutos en el conjunto de nonce (puede usar la caducidad de Redis y establecer su tiempo de vencimiento en 10 minutos al agregar un nuevo nonce).

Para el servidor, puede usar aspectos AOP o interceptores para interceptar solicitudes. Si desea interceptar todas las solicitudes, puede manejarlas directamente con el interceptor (el interceptor está antes del aspecto, después del filtro, específicamente después de la distribución dispather de springmvc).

El orden de filtro → interceptor → aspecto:

Entre ellos, los campos que deben colocarse en el encabezado de la solicitud: appid, marca de tiempo, nonce, firma.

Para varios tipos de parámetros de solicitud, primero realice el siguiente proceso de empalme:

Si hay varios formularios de datos, entonces empalméelos en el orden de ruta, consulta, formulario y cuerpo. Obtenga el valor empalmado de todos los datos.

El valor del empalme anterior se denota como Y.

X="appid=xxxnonce=xxxtimestamp=xxx"

Valor de empalme final=XY. Finalmente, el valor final empalmado se firma según un algoritmo de cifrado.

Aunque se recomiendan los algoritmos hash SHA-256, SHA-384 y SHA-512, está prohibido el uso de MD5. Pero, de hecho, no existe un gran problema al utilizar el cifrado MD5 para firmas. No se recomienda MD5 principalmente porque hay una gran cantidad de bibliotecas de descifrado MD5 en Internet.

La implementación se puede dividir en los siguientes pasos:

HttpServletRequest de caché personalizado con parámetros de cuerpo:

Reemplazar el RequestServlet personalizado en el filtro:

Agregue la configuración del filtro y preste atención al orden:

Dado que Zuul viene con filtros predeterminados, algunos de los cuales ya han procesado el cuerpo (FormBodyWrapperFilter), para procesar firmas en Zuul, solo necesita agregar Un filtro puede ser el siguiente.

Plan de implementación de firma de interfaz Java (Firma)

Verificación de firma de interfaz API abierta, para que su interfaz ya no se ejecute desnuda