Pregunta Mejores prácticas para asegurar una API REST / servicio web [cerrado]


Al diseñar una API o servicio REST, ¿existen algunas mejores prácticas establecidas para tratar con la seguridad (Autenticación, Autorización, Gestión de identidades)?

Al construir una API SOAP, tiene WS-Security como guía y existe mucha literatura sobre el tema. He encontrado menos información sobre la seguridad de los puntos finales REST.

Si bien entiendo que REST intencionalmente no tiene especificaciones análogas a WS- *, espero que surjan las mejores prácticas o los patrones recomendados.

Cualquier discusión o enlaces a documentos relevantes sería muy apreciada. Si es importante, estaríamos usando WCF con los mensajes serializados de POX / JSON para nuestros servicios / API REST construidos utilizando v3.5 de .NET Framework.


747
2017-08-11 05:44


origen


Respuestas:


Como dijo el tweakt, Amazon S3 es un buen modelo para trabajar. Sus firmas de solicitud tienen algunas características (como la incorporación de una marca de tiempo) que ayudan a proteger contra la repetición de solicitudes accidentales y maliciosas.

Lo bueno de HTTP Basic es que prácticamente todas las bibliotecas HTTP lo admiten. Por supuesto, necesitará requerir SSL en este caso porque el envío de contraseñas de texto claro a través de la red es casi universalmente malo. Básico es preferible a Digest cuando se usa SSL, porque incluso si la persona que llama ya sabe que se requieren credenciales, Digest requiere una ida y vuelta adicional para intercambiar el valor nonce. Con Basic, las personas que llaman simplemente envían las credenciales por primera vez.

Una vez que se establece la identidad del cliente, la autorización es realmente solo un problema de implementación. Sin embargo, puede delegar la autorización a algún otro componente con un modelo de autorización existente. Una vez más, lo bueno de Basic aquí es que su servidor termina con una copia en texto plano de la contraseña del cliente que puede pasar simplemente a otro componente dentro de su infraestructura según sea necesario.


280
2017-08-11 08:45



No hay estándares para REST distintos de HTTP. Existen servicios REST establecidos por ahí. Sugiero que echarles un vistazo y obtener una idea de cómo funcionan.

Por ejemplo, tomamos prestadas muchas ideas del servicio REST S3 de Amazon cuando desarrollamos las nuestras. Pero optamos por no usar el modelo de seguridad más avanzado basado en las firmas de solicitud. El enfoque más simple es la autenticación HTTP básica sobre SSL. Debes decidir qué funciona mejor en tu situación.

Además, recomiendo mucho el libro Servicios web RESTful de O'reilly. Explica los conceptos básicos y proporciona algunas mejores prácticas. En general, puede tomar el modelo que proporcionan y asignarlo a su propia aplicación.


108
2017-08-11 06:07



También es posible que desee echar un vistazo a OAuth, un protocolo abierto emergente para la autorización basada en tokens que apunta específicamente a http apis.

Es muy similar al enfoque adoptado por flickr y recuerda la leche Apis "descansar" (no necesariamente buenos ejemplos de apis relajantes, pero buenos ejemplos del enfoque basado en tokens).


68
2017-09-18 02:55



Estoy sorprendido de que SSL con certificados de clientes no haya sido mencionado aún. Por supuesto, este enfoque solo es realmente útil si puede contar con la comunidad de usuarios identificados por certificados. Pero una cantidad de gobiernos / compañías los emiten a sus usuarios. El usuario no tiene que preocuparse por crear otra combinación de nombre de usuario / contraseña, y la identidad se establece en todas y cada una de las conexiones, por lo que la comunicación con el servidor puede ser totalmente apátrida, sin necesidad de sesiones de usuario. (No implica que cualquiera / todas las otras soluciones mencionadas requieran sesiones)


40
2017-09-25 19:39



Todos en estas respuestas han pasado por alto el verdadero control / autorización de acceso.

Si, por ejemplo, sus API REST / servicios web se refieren a registros médicos POSTing / GETing, le conviene definir la política de control de acceso sobre quién puede acceder a los datos y bajo qué circunstancias. Por ejemplo:

  • los médicos pueden OBTENER el historial médico de un paciente con el que tienen una relación de cuidado
  • nadie puede PUBLICAR datos médicos fuera del horario de práctica (por ejemplo, de 9 a 5)
  • los usuarios finales pueden OBTENER los registros médicos que poseen o los registros médicos de los pacientes para quienes son los guardianes
  • las enfermeras pueden ACTUALIZAR la historia clínica de un paciente que pertenece a la misma unidad que la enfermera.

Para definir e implementar esas autorizaciones detalladas, deberá usar un lenguaje de control de acceso basado en atributos llamado XACML, el Lenguaje de marcado de control de acceso extensible.

Los otros estándares aquí son para lo siguiente:

  • OAuth: id. federación y delegación de autorización, p. permitir que un servicio actúe en mi nombre en otro servicio (Facebook puede publicar en mi Twitter)
  • SAML: federación de identidad / SSO web. SAML es mucho sobre quién es el usuario.
  • Estándares WS-Security / WS- *: se enfocan en la comunicación entre servicios SOAP. Son específicos del formato de mensaje de nivel de aplicación (SOAP) y tratan aspectos de mensajería, p. confiabilidad, seguridad, confidencialidad, integridad, atomicidad, eventos ... Ninguno cubre el control de acceso y todos son específicos de SOAP.

XACML es agnóstico de la tecnología. Se puede aplicar a aplicaciones Java, .NET, Python, Ruby ... servicios web, API REST y más.

Los siguientes son recursos interesantes:


34
2017-09-24 22:22



He usado OAuth algunas veces y también he usado otros métodos (BASIC / DIGEST). De todo corazón sugiero OAuth. El siguiente enlace es el mejor tutorial que he visto sobre el uso de OAuth:

http://hueniverse.com/oauth/guide/


25
2018-01-09 21:25



Hay una gran lista de verificación que se encuentra en Github:

Autenticación

  • No reinvente la rueda en Autenticación, generación de tokens, almacenamiento de contraseñas. Usa los estándares.

  • Utilizar Max Retry y características de la cárcel en Iniciar sesión.

  • Use cifrado en todos los datos confidenciales.

JWT (JSON Token web)

  • Usa una clave complicada al azar (JWT Secret) para hacer que el token bruto sea muy difícil.

  • No extraiga el algoritmo de la carga útil. Forzar el algoritmo en el backend (HS256 o RS256).

  • Hacer vencimiento del token (TTL, RTTL) tan corto como sea posible.

  • No almacene datos confidenciales en JWT carga útil, puede decodificarse fácilmente.

OAuth

  • Siempre validar redirect_uri del lado del servidor para permitir solo las URL incluidas en la lista blanca.

  • Siempre intente cambiar por código y no por tokens (no permita response_type=token)

  • Use el parámetro de estado con un hash aleatorio para evitar CSRF sobre el OAuth proceso de autenticación.

  • Defina el alcance predeterminado y valide los parámetros de alcance para cada aplicación.

Acceso

  • Solicitudes de límite (estrangulación) para evitar ataques de DDoS / fuerza bruta.

  • Use HTTPS en el servidor para evitar MITM (Man In The Middle Attack)

  • Utilizar HSTS encabezado con SSL para evitar el ataque de la franja SSL.

Entrada 

  • Use el método HTTP adecuado según la operación: GET (leer), POST (crear), PUT/PATCH (reemplazar / actualizar), y DELETE (para eliminar un registro) y responder con 405 Method Not Allowed si el método solicitado no es apropiado para el recurso solicitado.

  • Validar el tipo de contenido a petición Accept encabezado (Negociación de contenido) para permitir solo su formato compatible (p. application/xml, application/json, etc.) y responder con 406 Not Acceptable respuesta si no coincide

  • Validar content-type de los datos publicados a medida que aceptas (p. application/x-www-form-urlencoded, multipart/form-data, application/json, etc.)

  • Valide la entrada del usuario para evitar vulnerabilidades comunes (por ejemplo, XSS, inyección SQL, ejecución remota de código, etc.).

  • No use datos confidenciales (credenciales, contraseñas, fichas de seguridad o claves API) en la URL, pero utilice la norma Authorization encabezamiento.

  • Use un servicio API Gateway para habilitar el almacenamiento en caché Rate Limit políticas (por ejemplo, Cuota, Arresto de picos, Límite de velocidad concurrente) y despliegue de recursos de API dinámicamente.

Tratamiento

  • Compruebe si todos los puntos finales están protegidos detrás de la autenticación para evitar el proceso de autenticación interrumpido.

  • Se debe evitar la identificación del recurso propio del usuario. Utilice / me / orders en lugar de / user / 654321 / orders.

  • No aumente automáticamente los ID. Use UUID en su lugar.

  • Si está analizando archivos XML, asegúrese de que el análisis de entidades no esté habilitado para evitar XXE (ataque de entidad externa XML).

  • Si está analizando archivos XML, asegúrese de que la expansión de la entidad no esté habilitada para evitar la bomba Billion Laughs / XML a través del ataque de expansión de entidad exponencial.

  • Use un CDN para cargar archivos.

  • Si está tratando con una gran cantidad de datos, use Trabajadores y Colas para procesar tanto como sea posible en segundo plano y devuelva la respuesta rápidamente para evitar el Bloqueo HTTP.

  • No te olvides de encender el DEPURAR modo apagado.

Salida

  • Enviar X-Content-Type-Options: nosniff encabezamiento.

  • Enviar X-Frame-Options: deny encabezamiento.

  • Enviar Content-Security-Policy: default-src 'none' encabezamiento.

  • Eliminar encabezados de huellas digitales - X-Powered-By, Server, X-AspNet-Version etc.

  • Fuerza content-type por su respuesta, si regresa application/json entonces su tipo de contenido de respuesta es application/json.

  • No devuelva datos confidenciales como credenciales, contraseñas, tokens de seguridad.

  • Devuelve el código de estado correcto según la operación completada. (p.ej. 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, etc.)


22
2017-11-08 20:29



Una de las mejores publicaciones que he encontrado sobre Seguridad en relación con REST ha terminado en 1 RainDrop. Las API de MySpace también usan OAuth para la seguridad y usted tiene acceso completo a sus canales personalizados en el código de RestChess, con lo que hice mucha exploración. Esto se demostró en Mix y puedes encontrar la publicación aquí.


17
2017-09-18 20:53



Gracias por el excelente consejo. Terminamos usando un encabezado HTTP personalizado para pasar un token de identidad del cliente al servicio, en preparación para integrar nuestra API RESTful con el próximo marco de Identidad Zermatt de Microsoft. He descrito el problema aquíy nuestra solución aquí. Yo también tomé tweakt's consejos y compró Servicios web RESTful - un libro muy bueno si estás construyendo una API RESTful de cualquier tipo.


15
2017-09-17 20:30