¿Riesgos de asegurar la API REST mediante SSL?

3

Estamos pensando en construir una API REST donde todas las llamadas se realicen a través de SSL. Después de iniciar sesión correctamente, las llamadas subsiguientes incluirán un token que fue devuelto por el servicio de inicio de sesión. El servidor validará que el token es legítimo y válido. ¿Se considera esto un método válido para asegurar una API? ¿Cuáles son los riesgos aquí?

    
pregunta Marcus Leon 11.02.2016 - 03:52
fuente

3 respuestas

1

Esto supone que muchos otros componentes del sistema son seguros. Del mismo modo, no protege la API del ataque directo de un mal actor que puede registrarse para una cuenta (puede o no ser un problema para usted). También es siempre conveniente contar con protección en banda para las conexiones a cualquier servicio. Tal vez vea algo como un Firewall de aplicación web (WAF) o algo como mod_security para agregar controles adicionales. Parte de esto depende de lo seguro que quiera las cosas, pero hay muchos controles de seguridad adicionales dependiendo de su aplicación.

Consulte la Hoja de referencia de seguridad de OWASP REST para obtener más información acerca de REST específicamente y no olvide reforzar sus servidores y proteger su red también.

enlace

    
respondido por el Trey Blalock 11.02.2016 - 09:33
fuente
0

He trabajado con servicios web REST que tienen este mismo esquema de seguridad. Esta es una buena manera de asegurar sus servicios web en mi opinión. El único riesgo que me gustaría señalar es tener cuidado con la cantidad de información que está registrando cuando se invocan sus servicios web. Específicamente, tenga cuidado de que las credenciales del usuario no se almacenen en algún registro cuando los usuarios invocan el servicio web de autenticación para recibir los tokens. Además, asegúrese de que los tokens no se estén registrando en solicitudes posteriores. Si esta información se está registrando, asegúrese de enmascarar los datos.

    
respondido por el user99955 11.02.2016 - 04:35
fuente
0

Esto es seguro si:

  • el atacante no puede iniciar sesión (lo que implica que todo el proceso de autenticación debe ser seguro)
  • el atacante no puede obtener un token válido (lo que requiere que los tokens se mantengan donde el atacante no pueda obtenerlos y no se filtren al transmitirlos)
  • la verificación del token no se puede omitir y solo acepta tokens válidos

Aunque (implementado correctamente) SSL guardará el token en tránsito, el token permanece vulnerable en los puntos finales de la comunicación y en cualquier intermediario que realice la intercepción de SSL (como "proxies HTTPS"). Incluso si estos sistemas son de confianza, pueden filtrar el token sin tener la intención de hacerlo, por ejemplo, porque registran la solicitud (por ejemplo, es mejor que no pase el token en la URL, porque eso suele aparecer en los archivos de registro).

    
respondido por el meriton 15.02.2016 - 23:43
fuente

Lea otras preguntas en las etiquetas