El servicio web HTTPS cambió a HTTP. ¿Qué puede ir mal?

Tienes razón, la regresión a HTTP no tiene sentido.

Tenga en cuenta que todos sus puntos se aplican a un tipo particular de ataque, donde el adversario puede acceder al transporte de datos entre el cliente y el servidor. Ese podría ser el propietario de un punto de acceso WiFi o su ISP actuando como man-in-the- medio , que se encuentra entre usted y el servidor. Esto puede ser difícil de lograr para un atacante remoto, pero es particularmente fácil en un WiFi público.

Lo que HTTPS agrega a HTTP es transporte de datos seguro . La aplicación web en sí puede estar completamente bien: si se está comunicando a través de un canal no cifrado, el atacante podrá leer, modificar e inyectar datos arbitrarios en sus solicitudes y las respuestas del servidor. Con una cookie de sesión capturada, también será posible suplantarte mientras la cookie sea válida.

Lo que el atacante no puede hacer es controlar su cuenta de Google o volver a autenticarse con Google más adelante. Esto se debe a que la autenticación con Google siempre se realiza a través de SSL y el token otorgado caduca después de un tiempo determinado.

Entonces, la situación es algo mejor que capturar sus credenciales de inmediato. Sin embargo, como usted dijo, un atacante aún podría hacerse cargo de la sesión y realizar cualquier acción en su nombre.

Me gustaría plantear la siguiente pregunta:

¿Qué sentido tiene tener autenticación en la aplicación?

Si toda la página contiene contenido público y verificable de forma externa (por ejemplo, un espejo debian, donde los paquetes están con PGP) y , a los usuarios no les importa que un tercero examine detenidamente lo que visita, la página podría no necesitar https. Pero tampoco un inicio de sesión.

Las razones comunes para requerir autenticación incluyen:

• Hay algunos datos que el usuario solo puede leer mientras está conectado

• Un usuario registrado puede enviar mensajes a otras personas

• Le permite al usuario ganar reputación al mantener una identidad que solo él usa

• La cuenta puede recibir algunos beneficios obtenidos fuera (como el acceso a contenido pagado)

Todos ellos son derrotados usando http en lugar de https en la comunicación, así como casi cualquier otra razón para insertar un inicio de sesión. Independientemente del hecho de que la contraseña no esté expuesta (lo que, ciertamente, sería aún peor).

Hace algún tiempo, se discutió el precio de comprar los certificados, pero hoy en día hay varias CA que proporcionan certificados de forma gratuita.

† El rincón de Nitpicker, hay algunos casos extremadamente raros donde la seguridad no se ve comprometida por esto. Un ejemplo es Mega, que cargó algunos javascripts comunes a través de http, pero un script https cargado verificó sus hashes antes de ejecutarlos. Frágil y más complejo que configurar https en todas partes. No intentes esto en casa, niños.

Sus credenciales son seguras, pero el secuestro de sesión puede suceder

Una posibilidad podría haber sido que un atacante podría haber realizado un ataque de Tira SSL mientras actuaba como Man In Middle. Si eso sucede, el sitio web de HTTPS se servirá como HTTP para la víctima. Pero como confirmó con el sitio web que lo han hecho intencionalmente, esta posibilidad se desactiva.

Ahora, Google usa oAuth2, por lo que el apretón de manos con Google será más de HTTPS & después de eso, será redirigido a su sitio web a través de HTTP (sucede de la misma manera con enlace mientras usa su cuenta de Google). Su sitio web habría generado un token de sesión después de oAuth. El riesgo que HTTP tiene en este caso es que un atacante puede secuestrar fácilmente su sesión y navegar por el sitio web haciéndose pasar por usted

Tienes toda la razón. Excluyendo las credenciales de inicio de sesión de Google, un atacante puede realizar un ataque MITM e interceptar todas las solicitudes de la víctima. Le sugiero que les comunique los riesgos y vuelva a implementar el protocolo SSL.

"¿Qué puede salir mal?": si lo haces con una API, todas las aplicaciones de iOS diseñadas para iOS 9 y que se ejecuten en iOS 9 con esa API dejarán de funcionar.

Se llama "Seguridad de transporte de la aplicación" y, a menos que el desarrollador cree una excepción para su dominio, no se acepta http y no se acepta https con conexiones no lo suficientemente seguras. Dado que su API solía usar https, las aplicaciones existentes no tendrán una excepción para su dominio, por lo que dejarán de funcionar.