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

13

Me refiero a este excelente artículo http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ que habla de amazon como seguridad para el servicio web. Sin embargo, me hicieron una pregunta en el equipo sobre 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 al proporcionar servicios REST donde HTTPS puede no funcionar? ¿Te gustan los sitios web de terceros?

Si alguien tiene experiencia en la seguridad de los servicios web a través de las redes públicas, arroje algo de luz con su experiencia.

Gracias por adelantado.

EDITAR: Para aclarar, no estoy hablando de autenticación de usuario, sino más de autenticación de cliente. Se puede suponer que la autenticación del usuario es texto sin formato a través de 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 simple, aunque a través de HTTPS el punto final del cliente aún puede usar mi servicio web sin la aplicación del cliente.

rest

— Abhishek Dujari
fuente

3

¿El más adecuado para security.stackexchange.com ?

— jweyrich

1

tal vez tengas razón, pero mi pregunta está más relacionada.

13

¿Por qué necesitamos darle a Gmail, o cualquier otro sitio con cuentas de usuario, nuestro nombre de usuario y contraseña si ya está usando 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 equivale 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 otorgue a cada usuario un certificado , el servidor no puede confiar en el cliente sin algún otro método de autenticación.

— Matt Ball
fuente

lo siento, no entendiste bien o no estaba claro. Los documentos de Amazon APi establecen que debemos usar HTTPS, pero si no lo hacemos, ENTONCES firmamos la solicitud. La contraseña del nombre de usuario es irrelevante en este momento.

3

En un nivel superior, debe demostrar su identidad al servidor para que acepte comandos de usted. La autenticación del cliente se puede hacer a través de HTTPS, y también se puede hacer mediante la firma de mensajes.

— Matt Ball

1

Si desea utilizar HTTPS para la autenticación del cliente, debe emitir a cada usuario un certificado de clave pública, como se describe en el último enlace de mi respuesta. Piense en estos certificados como la versión electrónica de un pasaporte.

— Matt Ball

1

Enlace para "dar a cada usuario un certificado" kidn de respuestas mi pregunta. Supongo que toda la clave pública privada y la firma aún se requieren para asegurar adecuadamente ambos extremos en un servicio web, por lo que un SSL en el servidor no es suficiente. Tu respuesta es la más cercana hasta ahora. muchas gracias.

— Abhishek Dujari

1

+1 Es genial que mencione los certificados de cliente, pero no es necesario que el servidor emita los certificados. Solo necesitan ser firmados por una CA confiable; básicamente lo mismo que cómo funcionan los certificados de servidor.

— JimmyJames

3

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

Pero como la mayoría de las personas están usando 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 HTTPS sea bastante inútil para la autenticación de usuarios que no sea proteger un diálogo de autenticación de escuchas, etc.

— James Anderson
fuente

Creo que estás muy cerca de lo que te pido. Entonces, ¿sugiere que sigamos firmando la solicitud en el lado del cliente incluso si usamos HTTPS?

2

HTTPS se trata de asegurar el canal, no probar quién es la persona que llama o las muchas otras cosas que debe tener en cuenta. 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 tener en cuenta la validación de entrada, el craqueo de sesión, los mensajes de error inapropiados, las vulnerabilidades internas de los empleados, etc. Es un gran tema.

Robert

— Robert Morschel
fuente

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 de consumo público.

— CodeToGlory
fuente