Servicios web seguros: REST sobre HTTPS vs SOAP + WS-Security. ¿Cual es mejor? [cerrado]

No soy un experto en seguridad de ninguna manera, pero estoy a favor de crear servicios web de estilo REST.

Al crear un nuevo servicio que necesita tener los datos que transmite de forma segura. Hemos entrado en un debate sobre qué enfoque es más seguro: REST con HTTPS o SOAP WS con WS-Security.

Tengo la impresión de que podríamos usar HTTPS para todas las llamadas al servicio web y este enfoque sería seguro. Desde mi punto de vista, "si HTTPS es lo suficientemente bueno para sitios web bancarios y financieros, es lo suficientemente bueno para mí". Nuevamente, no soy un experto en este espacio, pero creo que estas personas han pensado mucho sobre este problema y se sienten cómodas con HTTPS.

Un compañero de trabajo no está de acuerdo y dice que SOAP y WS-Security son el único camino a seguir.

La web parece exagerada en esto.

¿Quizás la comunidad aquí podría evaluar los pros y los contras de cada uno? ¡Gracias!

HTTPS asegura la transmisión del mensaje a través de la red y proporciona cierta seguridad al cliente sobre la identidad del servidor. Esto es lo que es importante para su banco o corredor de bolsa en línea. Su interés en autenticar al cliente no está en la identidad de la computadora, sino en su identidad. Por lo tanto, los números de tarjeta, los nombres de usuario, las contraseñas, etc. se utilizan para autenticarlo. Por lo general, se toman algunas precauciones para garantizar que las presentaciones no se hayan alterado, pero en general, lo que ocurra en la sesión se considera iniciado por usted.

WS-Security ofrece protección de confidencialidad e integridad desde la creación del mensaje hasta su consumo. Por lo tanto, en lugar de garantizar que el contenido de las comunicaciones solo pueda ser leído por el servidor correcto, se asegura de que solo pueda ser leído por el proceso correcto en el servidor. En lugar de suponer que todas las comunicaciones en la sesión iniciada de forma segura provienen del usuario autenticado, cada una debe estar firmada.

Aquí hay una explicación divertida que involucra motociclistas desnudos:

https://docs.microsoft.com/archive/blogs/vbertocci/end-to-end-security-or-why-you-shouldnt-drive-your-motorcycle-naked

Por lo tanto, WS-Security ofrece más protección que HTTPS y SOAP ofrece una API más rica que REST. Mi opinión es que, a menos que realmente necesite las características o la protección adicionales, debe omitir los gastos generales de SOAP y WS-Security. Sé que es un poco una evasión, pero las decisiones sobre cuánta protección está realmente justificada (no solo lo que sería genial construir) deben ser tomadas por aquellos que conocen el problema íntimamente.

La seguridad REST depende del transporte, mientras que la seguridad SOAP no.

REST hereda las medidas de seguridad del transporte subyacente, mientras que SOAP define las suyas a través de WS-Security.

Cuando hablamos de REST, a través de HTTP: todas las medidas de seguridad aplicadas HTTP se heredan y esto se conoce como seguridad de nivel de transporte.

Seguridad de nivel de transporte, asegura su mensaje solo mientras está en el cable; tan pronto como sale del cable, el mensaje ya no está seguro.

Pero, con WS-Security, su seguridad de nivel de mensaje, aunque el mensaje abandone el canal de transporte, todavía estará protegido. Además, con la seguridad de nivel de mensaje puede encriptar parcialmente el mensaje [no todo el mensaje, sino solo las partes que desea], pero con la seguridad de nivel de transporte no puede hacerlo.

WS-Security tiene medidas para la autenticación, integridad, confidencialidad y no repudio, mientras que SSL no admite el no repudio [con OAuth de dos patas lo hace].

En cuanto al rendimiento, SSL es mucho más rápido que WS-Security.

Gracias...

Técnicamente, la forma en que está redactada, tampoco es correcta, porque la comunicación del método SOAP no es segura, y el método REST no dijo nada sobre la autenticación de usuarios legítimos.

HTTPS evita que los atacantes escuchen la comunicación entre dos sistemas. También verifica que el sistema host (servidor) es en realidad el sistema host al que el usuario intenta acceder.

WS-Security evita que aplicaciones no autorizadas (usuarios) accedan al sistema.

Si un sistema RESTful tiene una forma de autenticar a los usuarios y una aplicación SOAP con WS-Security está utilizando HTTPS, entonces ambos son realmente seguros. Es solo una forma diferente de presentar y acceder a los datos.

Ver el artículo wiki :

En situaciones punto a punto, la confidencialidad y la integridad de los datos también pueden imponerse en los servicios web mediante el uso de Transport Layer Security (TLS), por ejemplo, mediante el envío de mensajes a través de https.

Sin embargo, WS-Security aborda el problema más amplio de mantener la integridad y la confidencialidad de los mensajes hasta después de que se envió un mensaje desde el nodo de origen, proporcionando la llamada seguridad de extremo a extremo.

Es decir:

• HTTPS es un mecanismo de seguridad de capa de transporte (punto a punto)
• WS-Security es un mecanismo de seguridad de capa de aplicación (de extremo a extremo).

Como usted dice, REST es lo suficientemente bueno para los bancos, por lo que debería ser lo suficientemente bueno para usted.

La seguridad tiene dos aspectos principales: 1) cifrado y 2) identidad.

La transmisión en SSL / HTTPS proporciona cifrado por cable. Pero también deberá asegurarse de que ambos servidores puedan confirmar que saben con quién están hablando. Esto puede ser a través de certificados de cliente SSL, secretos compartidos, etc.

Estoy seguro de que uno podría argumentar que SOAP es "más seguro", pero probablemente no de manera significativa. La analogía del motociclista desnudo es linda, pero si es precisa implicaría que todo Internet es inseguro.

Todavía no tengo el representante necesario para agregar un comentario o simplemente habría agregado esto a la respuesta de Bell. Creo que Bell hizo un muy buen trabajo al resumir los pros y los contras de alto nivel de los dos enfoques. Solo algunos otros factores que puede considerar:

1) ¿Las solicitudes entre sus clientes y su servicio deben pasar por intermediarios que requieren acceso a la carga útil? Si es así, WS-Security podría ser mejor.

2) En realidad, es posible usar SSL para proporcionarle seguridad al servidor en cuanto a la identidad del cliente utilizando una función llamada autenticación mutua. Sin embargo, esto no tiene mucho uso fuera de algunos escenarios muy especializados debido a la complejidad de configurarlo. Entonces Bell tiene razón en que WS-Sec encaja mucho mejor aquí.

3) SSL en general puede ser un poco difícil de configurar y mantener (incluso en la configuración más simple) debido en gran medida a problemas de administración de certificados. Tener a alguien que sepa cómo hacer esto para su plataforma será una gran ventaja.

4) Si necesita hacer algún tipo de mapeo de credenciales o federación de identidad, entonces WS-Sec podría valer la pena. No es que no puedas hacer esto con REST, solo tienes menos estructura para ayudarte.

5) Obtener todo el contenido de WS-Security en los lugares correctos del lado del cliente puede ser más doloroso de lo que crees que debería ser.

Al final, aunque realmente depende de muchas cosas que probablemente no sepamos. Para la mayoría de las situaciones, diría que cualquiera de los enfoques será "lo suficientemente seguro", por lo que ese no debería ser el principal factor decisivo.

Brace yourself, here there's another coming :-)

Hoy tuve que explicarle a mi novia la diferencia entre el poder expresivo de WS-Security en comparación con HTTPS. Ella es una científica de la computación, por lo que incluso si no conoce todo el XML mumbo jumbo, comprende (tal vez mejor que yo) lo que significa el cifrado o la firma. Sin embargo, quería una imagen fuerte, que pudiera hacerla entender realmente para qué sirven las cosas, en lugar de cómo se implementan (eso vino un poco más tarde, no se le escapó :-)).

Entonces va así. Suponga que está desnudo y tiene que conducir su motocicleta a un determinado destino. En el caso (A) atraviesas un túnel transparente: tu única esperanza de no ser arrestado por comportamiento obsceno es que nadie esté mirando. Esa no es exactamente la estrategia más segura con la que puedes salir ... (nota la gota de sudor de la frente del chico :-)). Eso es equivalente a un POST en claro, y cuando digo "equivalente" lo digo en serio. En el caso (B), estás en una mejor situación. El túnel es opaco, por lo que, siempre que viaje, su registro público estará seguro. Sin embargo, esta todavía no es la mejor situación. Todavía tiene que salir de casa y llegar a la entrada del túnel, y una vez fuera del túnel, probablemente tendrá que bajarse y caminar a algún lado ... y eso es para HTTPS. Cierto, su mensaje está seguro mientras cruza el abismo más grande: pero una vez que lo entregó al otro lado, realmente no sabe cuántas etapas tendrá que pasar antes de llegar al punto real donde se procesarán los datos. Y, por supuesto, todas esas etapas podrían usar algo diferente a HTTP: un MSMQ clásico que almacena solicitudes que no se pueden atender de inmediato, por ejemplo. ¿Qué sucede si alguien acecha sus datos mientras están en ese limbo de preprocesamiento? Hm. (lea este "hm" como el que Morpheus pronunció al final de la oración "¿cree que respira aire?"). La solución completa (c) en esta metáfora es dolorosamente trivial: ¡ponte algo de ropa, y especialmente el casco mientras estás en la motocicleta! Por lo tanto, puede moverse con seguridad sin tener que depender de la opacidad de los entornos. Es de esperar que la metáfora sea clara: la ropa viene con usted independientemente de la infraestructura o la infraestructura circundante, como lo hace la seguridad a nivel de mensaje. Además, puede decidir cubrir una parte pero revelar otra (y puede hacerlo de manera personal: la seguridad del aeropuerto puede quitarle la chaqueta y los zapatos, mientras que su médico puede tener un mayor nivel de acceso), pero recuerde que las camisas de manga corta son mala práctica incluso si estás orgulloso de tus bíceps :-) (mejor un polo o una camiseta).

¡Estoy feliz de decir que ella entendió el punto! Tengo que decir que la metáfora de la ropa es muy poderosa: tuve la tentación de usarla para introducir el concepto de política (las discotecas no te permiten usar calzado deportivo; no puedes ir a retirar dinero en un banco en ropa interior) , aunque este es un aspecto perfectamente aceptable mientras te balanceas en un surf; y así sucesivamente), pero pensé que por una tarde fue suficiente ;-)

Arquitectura - WS, Ideas salvajes

Cortesía: http://blogs.msdn.com/b/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked. aspx

Trabajo en este espacio todos los días, así que quiero resumir los buenos comentarios sobre esto en un esfuerzo por cerrar esto:

SSL (HTTP / s) es solo una capa que garantiza:

1. El servidor al que está conectado presenta un certificado que prueba su identidad (aunque esto puede ser falsificado a través del envenenamiento de DNS).
2. La capa de comunicaciones está encriptada (sin escuchas).

WS-Security y las implementaciones / estándares relacionados usan PKI que:

1. Probar la identidad del cliente.
2. Probar que el mensaje no se modificó en tránsito (MITM).
3. Permite al servidor autenticar / autorizar al cliente.

El último punto es importante para las solicitudes de servicio cuando la identidad del cliente (persona que llama) es primordial para saber si deben estar autorizados para recibir dichos datos del servicio. SSL estándar es autenticación unidireccional (servidor) y no hace nada para identificar al cliente.

La respuesta realmente depende de sus requisitos específicos.

Por ejemplo, ¿necesita proteger sus mensajes web o no se requiere confidencialidad y todo lo que necesita es autenticar a las partes finales y garantizar la integridad del mensaje? Si este es el caso, y a menudo ocurre con los servicios web, HTTPS es probablemente el martillo incorrecto.

Sin embargo, desde mi experiencia, no pase por alto la complejidad del sistema que está creando. No solo HTTPS es más fácil de implementar correctamente, sino que una aplicación que se basa en la seguridad de la capa de transporte es más fácil de depurar (a través de HTTP simple).

Buena suerte.

REST Over HTTPS Debería ser un método seguro siempre que el proveedor de API implemente la autorización del servidor. En el caso de una aplicación web también, lo que hacemos es acceder a una aplicación web a través de HTTPS y alguna autenticación / autorización, tradicionalmente las aplicaciones web no tenían problemas de seguridad, ¡Restful API también contrarrestaría problemas de seguridad sin problemas!

Si su llamada RESTFul envía mensajes XML de un lado a otro incrustados en el cuerpo Html de la solicitud HTTP, debería poder tener todos los beneficios de WS-Security, como encriptación XML, certificados, etc. en sus mensajes XML mientras usa cualquier función de seguridad están disponibles desde http, como el cifrado SSL / TLS.