Esta respuesta es principalmente sobre la declaración de Chris Dixon más que por la respuesta "Cuántos ataques vienen de MiTM".
Si afirmamos la forma diferente en que uno podría convertirse en MiTM y las consecuencias dadas, creo que podemos llegar a algunas conclusiones sobre si nos importa o no la importancia de los ataques MiTM.
Si observamos algunos riesgos para las diferentes situaciones, podríamos tener algo como:
- ¿Alguien está robando la base de datos a través de la explotación de la aplicación web?
- Alguien que ataca a un usuario / administrador a través de un ataque de MiTM
Yo diría que el primero tiene un impacto mucho mayor (en general) y en muchos aspectos debería ser mitigado y tratado como el primero.
¡Entonces, para que el punto 2 prevalezca sobre el punto 1, creo que MiTM realmente tendría que estar loco para que lo valoremos tan alto como un obstáculo de seguridad como el punto 1 (como indica Chris en la cita)!
Ahora si vemos en los diferentes vectores de ataque. Primero para MiTM. Para convertirse en MiTM uno podría, por ejemplo:
- Poseer un punto de acceso inalámbrico no autorizado. Esto es trivial, pero para un ataque dirigido deberías estar en la misma ubicación física de la víctima con tu aplicación web.
- Detectar datos inalámbricos sin cifrar o datos que vienen a través de un HUB (¿ya existen?)
- Usa ARP Poisoning para atacar a los usuarios. No es trivial a menos que esté en la misma red que los usuarios objetivo que utilizan su aplicación web.
- Envenenamiento de caché de DNS. Para que esto funcione, necesita envenenar el DNS que utilizan los usuarios seleccionados. Si el DNS no está configurado correctamente, este ataque se vuelve algo trivial de realizar, sin embargo, hay mucho en que confiar para que esto funcione.
- Ataques de phishing. Estos todavía engañan a los usuarios ingenuos e ingenuos, sin embargo, gran parte de la responsabilidad es del usuario.
Todo esto solo para atacar a uno o un pequeño subconjunto de usuarios. Incluso entonces, atacar a estos usuarios les dará una advertencia en sus navegadores (también hay formas de atacar esto, pero no lo estoy tomando aquí). Solo al comprometer una CA raíz o al encontrar una falla en el algoritmo utilizado para generar los certificados, se le permitirá hacerse pasar por un emisor de certificados confiable.
Si, por otro lado, observamos todas las cosas potencialmente desagradables que podemos ver si no invertimos en la seguridad de la propia aplicación web, vemos vectores de ataque como:
- Inyección de SQL: trivial y fácil de explotar y descubrir. Daño muy alto impacto.
- XSS (Cross Site Scripting): fácil de descubrir, más difícil de explotar. Creo que veremos un impacto cada vez mayor en los usuarios de esto en el futuro. Preveo que esto se está convirtiendo en la tendencia de "nueva inyección de SQL" que hemos estado viendo en los últimos días.
- CSRF (falsificación de solicitud de sitios cruzados): moderada para descubrir, moderada para explotar. Esto requeriría que los usuarios naveguen a un sitio que ya es de su propiedad, lo que provocará una solicitud a su aplicación web que haría una transacción en nombre del usuario.
Entonces, solo mencionando estos pocos, pero los métodos populares para atacar la aplicación web y convertirse en MiTM lo dejarían para un análisis específico de riesgo / consecuencia de la organización específica que está tratando de asegurar, ya sea que defienda o no. usuarios directamente implementando SSL o defendiendo la aplicación web en su totalidad (que también incluye propiedad intelectual, datos de usuarios, datos confidenciales, datos potenciales que podrían violar otras aplicaciones, etc.).
En mi humilde opinión, estoy muy de acuerdo con la declaración de Chris Dixon. Priorice la protección de la aplicación web tanto como pueda antes de comenzar a pensar en proteger la capa de transporte.
Editar :
En una nota al margen: páginas como Facebook, Gmail y otros sufrieron fuertes ataques de MiTM durante la estela de Firesheep. Esto solo podría ser mitigado a través de SSL y conocimiento.
Sin embargo, si lo piensa bien, detectar el tráfico inalámbrico con Firesheep y secuestrar las sesiones requeriría que la LAN inalámbrica a la que está conectado no tenga ningún cifrado.
Cuando voy a conducir en la guerra hoy, ha disminuido drásticamente el número de puntos de acceso inalámbricos abiertos y también en el número de puntos de acceso habilitados para WEP. Seguimos viendo más y más AP encriptados WPA2 que en la mayoría de los casos nos brindan suficiente seguridad.
Ahora, ¿cuál es el riesgo de que alguien cree una herramienta fácil y conveniente para detectar y secuestrar las sesiones de sus usuarios? ¿Cuál es el impacto para esos usuarios? También podría mitigarse de diferentes maneras (volviendo a autenticar al usuario cuando venía de diferentes huellas al mismo tiempo, notificando al usuario cuando algo se ve mal (gmail es un buen ejemplo de esto)).