Cómo diseñar una buena seguridad de API RESTful

b) Cifrar datos confidenciales y evitar la manipulación

c) Autorización después de la verificación

Existen varias prácticas comunes para verificar al cliente:

Colocar parámetros de firma en la solicitud

1.

Asigne una clave a cada visitante y especifique el método para calcular la firma. Requiere que se agreguen parámetros de firma a la solicitud de la parte que accede. Este es el método más simple, pero requiere garantizar que las claves de la parte que accede se almacenen de forma segura y, al mismo tiempo, evitar ataques de repetición. La ventaja de este método es que es fácil de entender e implementar. La desventaja es que debe soportar la carga de almacenar la clave de forma segura y actualizarla periódicamente. No es lo suficientemente flexible y es muy difícil actualizar la clave. clave y actualice el algoritmo de firma.

Utilice el mecanismo de autenticación HTTP estándar

La autenticación HTTP básica es menos segura y debe usarse junto con HTTPS. La autenticación implícita HTTP se puede utilizar sola y proporciona un nivel moderado de seguridad.

La autenticación HTTP Digest también admite la inserción de algoritmos de cifrado definidos por el usuario, lo que puede mejorar aún más la seguridad de la API. Sin embargo, no hay muchos casos de inserción de algoritmos de cifrado personalizados en API conectadas a Internet.

Este método requiere garantizar el almacenamiento seguro de la información triple "dominio de seguridad-nombre de usuario-contraseña" de la parte que accede y evitar ataques de repetición.

Ventajas

Puntos clave: Basado en estándares, amplio soporte (una gran cantidad de bibliotecas de clientes y servidores HTTP). La responsabilidad de la autenticación HTTP en el lado del servidor puede recaer en servidores web (como Nginx), servidores de aplicaciones (como Tomcat) y marcos de seguridad (como Spring). ), que es muy importante para las aplicaciones y es transparente para los desarrolladores de programas. El mecanismo de autenticación HTTP (mecanismo de autenticación HTTP RFC (RFC2617)) encarna bien el principio de diseño de "separación de preocupaciones" y mantiene la visibilidad de la semántica operativa.

2. Desventajas: están basadas en el usuario. Es poco probable que el mecanismo de nombre y contraseña sea más seguro que un mecanismo basado en claves asimétricas, como un certificado digital.

Autenticación mediante el protocolo OAuth

OAuth

OAuth

El protocolo se utiliza para autorizar que aplicaciones externas accedan a los recursos de este sitio web. El mecanismo de cifrado involucrado es más seguro que HTTP

Autenticación implícita. Tenga en cuenta que OAuth y HTTP <. /p>

La autenticación implícita no es intercambiable, se utilizan en diferentes escenarios de aplicaciones; el protocolo OAuth es más adecuado para proporcionar autorización a las API que enfrentan los usuarios finales, como el acceso a los tweets y

de los usuarios. otra información Si la API no está dirigida a los usuarios finales, es más adecuado proporcionar autorización para aplicaciones externas. Si la API no está dirigida a los usuarios finales, como servicios de almacenamiento como Qiniu Cloud Storage, entonces este no es un escenario de aplicación típico. de OAuth

3. Cifrar datos confidenciales y evitar la manipulación. Las prácticas comunes incluyen:

Implementar infraestructura SSL (es decir, HTTPS) y toda la transmisión de datos confidenciales se basa en SSL. /p>

Cifre solo la parte confidencial (por ejemplo, número de tarjeta y contraseña para una tarjeta prepaga) y agregue algún tipo de número aleatorio como sal criptográfica para evitar que los datos sean manipulados. > La autorización después de la autenticación generalmente debe ser controlada por la aplicación. Existen muchos marcos para implementar algún tipo de mecanismo de autorización basado en roles y grupos de usuarios, pero la mayoría de los equipos de desarrollo prefieren implementar funciones relacionadas ellos mismos. /p>