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

https://stackoverflow.com/questions/7551

08-06-2019
|

Pregunta

A la hora de diseñar una API REST o servicio hay establecido las mejores prácticas de gestión de la seguridad (Autenticación, Autorización, Gestión de Identidad) ?

Cuando la construcción de una API de SOAP tiene WS-Security como una guía y gran parte de la literatura que existe sobre el tema.He encontrado poca información acerca de la protección de los extremos REST.

Aunque entiendo RESTO intencionalmente no tiene especificaciones análoga a la de WS-* tengo la esperanza de mejores prácticas o pautas recomendadas han surgido.

Cualquier discusión o enlaces a documentos relevantes sería muy apreciado.Si importa, estaríamos utilizando WCF con VARICELA/JSON serializado mensajes para nuestra API REST del/los Servicios construido usando la v3.5 de la .NET Framework.

Solución

Como tweakt dijo, Amazon S3 es un buen modelo para trabajar con.Petición de firmas tienen algunas características (tales como la incorporación de una marca de hora) que ayudan a proteger contra accidental y malicioso solicitar que se repiten.

La cosa agradable sobre HTTP Básica es que prácticamente todos los HTTP bibliotecas de apoyo.Usted, por supuesto, debemos requerir SSL en este caso, ya que el envío de contraseñas de texto plano a través de la red es casi siempre una mala cosa.Basic es preferible a Digerir el uso de SSL, porque incluso si la persona ya sabe que se requieren credenciales, Digerir requiere un extra de ida y vuelta para el cambio de valor nonce.Básicos de los que llaman, simplemente envía las credenciales de la primera vez.

Una vez que la identidad del cliente que está establecido, la autorización es realmente sólo un problema de aplicación.Sin embargo, podría delegar la autorización a algún otro componente con un modelo de autorización.De nuevo la cosa buena acerca de Básica aquí es el servidor termina con un texto simple copia de la contraseña del cliente que usted puede simplemente pasar a otro componente dentro de su infraestructura como sea necesario.

Otros consejos

No existen estándares para el RESTO de HTTP.Hay establecido RESTO de servicios.Te sugiero que eche un vistazo a ellos y tener una idea de cómo funcionan.

Por ejemplo, hemos pedido prestado un montón de ideas de Amazon S3 RESTO de servicios en el desarrollo de nuestro propio.Pero hemos optado por no utilizar el más avanzado modelo de seguridad basado en la petición de firmas.El enfoque más sencillo es HTTP Basic auth a través de SSL.Usted tiene que decidir lo que funciona mejor en su situación.

También, le recomiendo el libro Servicios Web RESTful de O'reilly.Explica los conceptos básicos y proporciona algunas de las mejores prácticas.Generalmente, se puede tomar el modelo que ofrecen y mapa de su propia aplicación.

También puede que desee echar un vistazo a OAuth, emergentes de protocolo abierto para la basada en token de autorización específicamente dirigidas a la api http.

Es muy similar al enfoque adoptado por flickr y recuerde que la leche "resto" api (no necesariamente buenos ejemplos de apis restful, pero buenos ejemplos del enfoque basado en tokens).

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

La autenticación

No reinventar la rueda en la Autenticación, el token de la generación, el almacenamiento de contraseñas.El uso de las normas.
Uso Max Retry y la cárcel características en el inicio de Sesión.
Utilizar el cifrado de todos los datos sensibles.

JWT (JSON Web Token)

El uso de un azar complicado clave (JWT Secreto) para hacer fuerza bruta el token muy duro.
No extraer el algoritmo de la carga.La fuerza del algoritmo en el backend (HS256 o RS256).
Hacer de caducidad de señal (TTL, RTTL) lo más corto posible.
No almacenar datos sensibles en el JWT la carga útil, que puede ser decodificado con facilidad.

OAuth

Validar siempre redirect_uri en el lado del servidor para permitir que sólo incluido en la lista blanca de direcciones Url.
Siempre trate de cambio de código y no de tokens (no permitir response_type=token).
El uso de parámetro de estado con una muestra aleatoria de hash para evitar CSRF en el OAuth proceso de autenticación.
Definir el ámbito predeterminado, y validar el alcance de los parámetros para cada aplicación.

Acceso

Límite de solicitudes (Limitación) para evitar ataques DDoS / ataques de fuerza bruta.
El uso de HTTPS en el lado del servidor para evitar MITM (Hombre En El Ataque Medio)
Uso HSTS encabezado con SSL para evitar SSL Strip ataque.

De entrada

Utilizar el método HTTP de acuerdo a la operación: GET (leer), POST (crear), PUT/PATCH (reemplazar/actualización), y DELETE (para eliminar un registro), y responder con 405 Method Not Allowed si el método no es apropiado para el recurso solicitado.
Validar el tipo de contenido en la solicitud Accept encabezado (de Contenidos de la Negociación) para permitir que sólo su formato compatible (por ejemplo, application/xml, application/json, etc) y responder con 406 Not Acceptable respuesta si no coincide.
Validar content-type de los datos enviados como la acepte (por ejemplo, application/x-www-form-urlencoded, multipart/form-data, application/json, etc).
Validar la entrada del Usuario para evitar vulnerabilidades comunes (por ejemplo,XSS, Inyección de SQL, la Ejecución Remota de Código, etc).
No usar ningún tipo de datos sensibles (credenciales de usuario, Contraseñas, tokens de seguridad, o claves de API) en la URL, pero el uso estándar Authorization encabezado.
Utilizar una Puerta de enlace API de servicio para habilitar el almacenamiento en caché Rate Limit las políticas (por ejemplo,Cuota, Spike Detención, Simultáneas Límite de Velocidad) e implementar la Api de recursos de forma dinámica.

Procesamiento de

Compruebe si todos los parámetros están protegidos detrás de autenticación para evitar fracturas de proceso de autenticación.
Usuario ID de recurso debe ser evitado.Uso /me/órdenes en lugar de /usuario/654321/pedidos.
No auto-incremento de los Identificadores.Usar UUID en su lugar.
Si usted analiza los archivos XML, asegúrese de que la entidad de análisis no está habilitado para evitar XXE (XML externo de la entidad de ataque).
Si usted analiza los archivos XML, asegúrese de que la entidad de expansión no está habilitado para evitar que Millones de Risas/XML bomba a través de la exponencial de la entidad de expansión de ataque.
El uso de un CDN para la carga de archivos.
Si usted está tratando con gran cantidad de datos, el uso de los Trabajadores y de las Colas de proceso tanto como sea posible en segundo plano y volver de respuesta rápida para evitar HTTP Bloqueo.
No te olvides de activar el DEPURACIÓN el modo de APAGADO.

Salida

Enviar X-Content-Type-Options: nosniff encabezado.
Enviar X-Frame-Options: deny encabezado.
Enviar Content-Security-Policy: default-src 'none' encabezado.
Eliminar huellas digitales de las cabeceras - X-Powered-By, Server, X-AspNet-Version etc.
La fuerza content-type por su respuesta, si el retorno de application/json entonces su respuesta content-type es application/json.
No devuelven datos sensibles como las credenciales de usuario, Contraseñas, tokens de seguridad.
Devolver el correcto código de estado según la operación se completó.(por ejemplo, 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, etc).

Estoy un poco sorprendido de SSL con certificados de cliente no se ha mencionado todavía.Concedido, este enfoque sólo es realmente útil si usted puede contar en la comunidad de usuarios, siendo identificadas por los certificados.Pero un número de gobiernos y/o empresas de emitir a sus usuarios.El usuario no tiene que preocuparse de crear otro nombre de usuario y una contraseña, y la identidad se establece en todas y cada una conexión de modo que la comunicación con el servidor puede ser completamente independiente, ninguna de las sesiones de usuario necesarios.(No implica que cualquier/todas las otras soluciones mencionadas requieren sesiones)

Todo el mundo en estas respuestas ha pasado por alto el verdadero control de acceso y autorización.

Si, por ejemplo, su Api de REST / servicios web son acerca de la Publicación / GETing registros médicos, es posible que desee definir el control de acceso en las políticas sobre quién puede tener acceso a los datos y en qué circunstancias.Por ejemplo:

los médicos pueden OBTENER el historial médico de un paciente que tiene una relación de cuidado con
nadie puede PUBLICAR los datos médicos fuera de horas de práctica (por ejemplo,De 9 a 5)
los usuarios finales pueden OBTENER los registros médicos son de su propiedad o de los registros médicos de los pacientes para quienes son el tutor
las enfermeras pueden ACTUALIZAR los registros médicos de un paciente que pertenece a la misma unidad como la enfermera.

Con el fin de definir e implementar los de grano fino, autorizaciones, usted tendrá que usar un atributo basado en lenguaje de control de acceso denominada XACML, eXtensible Access Control Markup Language.

Las demás normas aquí son para los siguientes:

OAuth:id.de la federación y de la delegación de la autorización por ej.dejando a un servicio de actuar en mi nombre en otro servicio (Facebook pueden enviar a mi Twitter)
SAML:la federación de identidades / SSO web.SAML es mucho acerca de quién es el usuario.
WS-Security / WS-* normas:estos se centran en la comunicación entre los servicios SOAP.Son específicos para el nivel de aplicación del formato de mensajes (SOAP), y se tratan los aspectos de mensajería por ejemplo,la fiabilidad, la seguridad, la confidencialidad, la integridad, la atomicidad, gestión de eventos...Ninguno de la cubierta de control de acceso y todos son específicos para el JABÓN.

XACML es la tecnología agnóstica.Se puede aplicar a las aplicaciones java, .NET, Python, Ruby...web services, REST Api, y más.

Los siguientes son recursos interesantes:

el OASIS XACML sitio web
el NIST estándar de ABAC

He usado OAuth un par de veces, y también se utilizan otros métodos (BÁSICO/IMPLÍCITA).De todo corazón me sugieren OAuth.El siguiente enlace es el mejor tutorial que he visto sobre el uso de OAuth:

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

Uno de los mejores posts que he encontrado con respecto a la Seguridad, como se relaciona a DESCANSAR en la 1 Gota de lluvia.El MySpace de la API de usar OAuth también para la seguridad y usted tiene acceso completo a su costumbre de canales en la RestChess código, en el que hice un montón de exploración.Este fue demostraciones en la Mezcla y usted puede encontrar la publicación aquí.

Gracias por el excelente asesoramiento.Terminamos el uso de un encabezado HTTP personalizado para pasar un testigo de identidad del cliente al servicio, en preparación para la integración de nuestra API Rest con el la próxima Zermatt marco de Identidad de Microsoft.He descrito el problema aquí y nuestra solución aquí.También tomé tweakt's el asesoramiento y la compró Servicios Web RESTful - un libro muy bueno si usted está construyendo una API RESTful de cualquier tipo.

OWASP(Open Web Application Security Project) tiene unas hojas de trucos que cubre todos los aspectos del desarrollo de Aplicaciones Web.Este Proyecto es una muy valiosa y confiable fuente de información.Con respecto a RESTO de los servicios que usted puede comprobar esto: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

Yo recomendaría OAuth 2/3.Usted puede encontrar más información en http://oauth.net/2/

He buscado mucho acerca de descanso ws de seguridad y también terminé con el uso de token a través de cookies desde el cliente al servidor para autenticar las solicitudes .He utilizado la primavera de seguridad para la autorización de las solicitudes de servicio, porque yo tenía para autenticar y autorizado de cada solicitud en función de lo especificado políticas de seguridad que ya ha sido en DB.

El hecho de que el JABÓN mundo está bastante bien cubierto con los estándares de seguridad no significa que es seguro por defecto.En primer lugar, las normas son muy complejo.La complejidad no es una muy buena amiga de seguridad y vulnerabilidades de implementación, tales como XML firma de envolver los ataques son endémicas aquí.

Como para el .NET entorno no me ayuda mucho, pero "La construcción de servicios web con Java" (un ladrillo con ~10 autores) ¿me ayudan mucho en la comprensión de la WS-* arquitectura de seguridad y, muy especialmente, de sus peculiaridades.

RESTO en sí no ofrece estándares de seguridad, pero las cosas como OAuth y SAML se están convirtiendo rápidamente en las normas de este espacio.Sin embargo, la autenticación y la autorización son sólo una pequeña parte de lo que usted necesita considerar.Muchas de las vulnerabilidades conocidas relacionados con las aplicaciones web se aplican mucho a las api de REST.Usted tiene que considerar la validación de entrada, sesión de grietas, inapropiado de los mensajes de error interno de los empleados de las vulnerabilidades y así sucesivamente.Es un gran tema.

Quiero añadir(en línea con stinkeymatt), la solución más sencilla sería la de añadir los certificados SSL para su sitio.En otras palabras, asegúrate de que la url es: HTTPS://.Que cubra su seguridad en el transporte (explosión para el buck).Con el Descanso de la dirección url, la idea es mantenerlo simple (a diferencia de WS* seguridad/SAML), puede utilizar oAuth2/openID connect o incluso Basic Auth (en casos sencillos).Pero usted todavía necesita SSL/HTTPS.Por favor, compruebe ASP.NET Web API 2 de seguridad aquí: http://www.asp.net/web-api/overview/security (Artículos y Vídeos)

Como @Nathan terminó con la que es un simple Encabezado HTTP, y algunos dijeron OAuth2 y cliente de lado los certificados SSL.El quid de la cuestión es esta...su API REST, no han de tener para manejar la seguridad como que realmente debería estar fuera del alcance de la API.

En lugar de una capa de seguridad se debe colocar en la parte superior de la misma, si se trata de un Encabezado HTTP detrás de un proxy web (un enfoque común como SiteMinder, Zermatt o incluso de Apache HTTPd), o tan complicado como OAuth 2.

La clave es la solicitudes deben trabajar sin ningún tipo de interacción con el usuario final.Todo lo que se necesita es asegurarse de que la conexión a la API de REST es autenticado.En Java EE, tenemos la noción de un userPrincipal que se pueden obtener en un HttpServletRequest.También es administrado en el descriptor de despliegue de que un patrón de URL puede ser seguro, por lo que el RESTO de la API de código no es necesario para comprobar más.

En el WCF mundo, me gustaría utilizar ServiceSecurityContext.Current para obtener el contexto de seguridad actual.Usted necesita configurar la aplicación para requerir autenticación.

Hay una excepción a la declaración de que había anteriormente y que es el uso de un nonce para evitar repeticiones (que pueden ser ataques o alguien que acaba de presentar los mismos datos dos veces).Esa parte puede ser manejado solamente en la capa de aplicación.

Para la Seguridad de Aplicaciones Web, usted debe echar un vistazo a OWASP (https://www.owasp.org/index.php/Main_Page) que proporciona cheatsheets de varios ataques de seguridad.Usted puede incorporar cuantas medidas posibles para garantizar su Aplicación.Con respecto a la seguridad de la API (autorización, autenticación, gestión de identidad), hay múltiples maneras como ya se ha mencionado (Basic,Digest y OAuth).Hay agujeros de bucle en OAuth1.0, así que usted puede utilizar OAuth1.0a (OAuth2.0 no es ampliamente adoptada debido a las preocupaciones con la especificación)

Ha sido un tiempo pero la pregunta sigue siendo relevante, aunque la respuesta podría haber cambiado un poco.

Una Puerta de enlace API sería un flexible y altamente configurable solución.He probado y usado KONG un poco y realmente me gustó lo que vi.KONG proporciona una administración de la API de REST de su propio que puede utilizar para administrar usuarios.

Express-puerta de enlace.io es más reciente y es también una Puerta de enlace API.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow