¿Por qué necesitamos seguridad de servicio REST si tenemos HTTPS?

Navega tus respuestas
13

Me refiero a este excelente artículo enlace que habla de Amazon como la seguridad para el servicio web. Sin embargo, se me hizo una pregunta en el equipo de por qué la necesitamos si ya usamos HTTPS. No pude responder, ya que realmente me parece que pueden estar en lo cierto, aunque el instinto me dice lo contrario.

¿También hay lugares en los que se proporcionan servicios REST donde HTTPS no funcione? ¿Te gustan los sitios web de terceros?

Si alguien tiene experiencia en la protección de servicios web a través de las interwebs públicas, arroje algo de luz con su experiencia.

Gracias de antemano.

EDITAR: Para aclarar, no estoy hablando de autenticación de usuario, sino de autenticación de cliente. Se puede asumir que la autenticación del usuario es texto sin formato sobre HTTPS + REST.

Mi preocupación es que esto todavía permite que cualquiera pueda usar el servicio web sin que mi cliente acceda a él, ya que todo es texto plano, aunque a través de HTTPS el punto final del cliente todavía puede usar mi servicio web sin la aplicación cliente.

    
pregunta Abhishek Dujari 13.06.2011 - 03:56

4 respuestas

13

¿Por qué debemos proporcionar a Gmail, o cualquier otro sitio con cuentas de usuario, nuestro nombre de usuario y contraseña si ya está utilizando HTTPS? La respuesta es la misma que la respuesta a su pregunta.

HTTPS proporciona, ante todo, una conexión cifrada entre el servidor y el cliente.

  

La confianza inherente en HTTPS se basa en las principales autoridades de certificación que vienen preinstaladas en el software del navegador (esto es equivalente a decir "Confío en la autoridad de certificación (por ejemplo, VeriSign / Microsoft / etc.) para decirme en quién debo confiar" ).

A menos que el servidor le dé a cada usuario un certificado , el servidor no puede confiar en el cliente sin algún otro método de autentificación.

    
respondido por el Matt Ball 13.06.2011 - 04:48
3

HTTPS es muy bueno para prevenir las escuchas ilegales y los ataques de "hombre en el medio". Como encripta todo el tráfico para una sesión.

Pero como la mayoría de las personas utilizan los certificados predeterminados que vienen con su navegador y no tienen idea de cómo crear su propio certificado personal o configurar el navegador para usarlo.

Esto hace que el HTTPS sea bastante inútil para la autenticación del usuario, aparte de proteger un diálogo de autenticación de escuchas ilegales, etc.

    
respondido por el James Anderson 13.06.2011 - 04:55
2

HTTPS trata de asegurar el canal, no de probar quién es la persona que llama, o las muchas otras cosas que debe considerar. La autenticación, la autorización y el cifrado de la capa de transporte son solo una pequeña parte de lo que debe tener en cuenta. Muchas de las vulnerabilidades conocidas relacionadas con las aplicaciones web se aplican mucho a las API REST. Debe considerar la validación de entrada, el agrietamiento de sesiones, los mensajes de error inapropiados, las vulnerabilidades internas de los empleados, etc. Es un gran tema.

Robert

    
respondido por el Robert Morschel 12.10.2012 - 10:27
0

Puede adoptar el enfoque de los certificados SSL del cliente y separar la seguridad de la API. El gran inconveniente de este enfoque es la sobrecarga de la operación, que se volverá costosa a medida que más y más clientes consuman su API.

En cualquier caso, la autenticación básica HTTP está bien para la gran mayoría de los servicios consumidos públicamente.

    
respondido por el CodeToGlory 13.06.2011 - 05:27

Lea otras preguntas en las etiquetas

¿Cuáles son algunas aplicaciones bien conocidas escritas en F #? [cerrado] ¿Cuál es la diferencia entre ref y out en tiempo de ejecución?