Un ataque Man-in-the-Browser se produce cuando un malware infecta un navegador web, lo que le permite modificar las páginas web, el contenido de las transacciones o insertar transacciones adicionales de forma encubierta. Estos ataques son particularmente peligrosos, ya que pueden eludir muchos controles de seguridad tradicionales, como HTTPS y la autenticación de dos factores.
Un ataque man-in-the-browser (MitB) se apoya en malware, a menudo un troyano o una extensión de navegador maliciosa, que se instala dentro del navegador de la víctima. Una vez residente, se engancha a las funciones del navegador para poder leer y reescribir las páginas a medida que se muestran y a medida que se envían los datos. Durante una sesión de banca en línea, por ejemplo, el malware puede mostrar al usuario los importes y destinatarios que espera mientras altera en silencio la transacción que realmente se envía al servidor, o inyectar campos de formulario adicionales para recolectar credenciales. Como la manipulación ocurre después del descifrado, dentro del navegador de confianza, es invisible tanto para el usuario como para el servidor que recibe la solicitud.
MitB derrota los controles que dan por sentado que el propio navegador es de fiar. La conexión sigue siendo HTTPS válido, así que el cifrado no ayuda; la sesión pertenece al usuario legítimo, así que la autenticación del lado del servidor pasa; y como el malware manipula la sesión en vivo en tiempo real, puede vencer muchos esquemas de contraseña de un solo uso y de doble factor aprovechando una sesión ya autenticada. El usuario ve una página normal y de aspecto correcto mientras al backend llegan datos distintos. Esto convierte a MitB en un favorito para el fraude financiero y el robo de cuentas, y puede persistir de una sesión a otra hasta que se encuentra y elimina la infección subyacente del dispositivo.
Como el malware vive en el propio dispositivo de la víctima, la higiene del endpoint es clave: antimalware actualizado, instalación prudente de extensiones y parcheo inmediato. Del lado del servidor, la verificación de transacciones fuera de banda —mostrar los detalles reales en un canal aparte, como una aplicación móvil o un SMS— permite que los usuarios detecten importes que se alteraron en el navegador. Ten en cuenta el límite de capacidad: una infección en el propio navegador del visitante queda fuera de los scripts que carga un sitio, así que un monitor de scripts de terceros no puede limpiarla. cside es relevante en el caso adyacente en el que la manipulación llega a través de un script de terceros comprometido o de código inyectado en tus páginas; analiza esas cargas útiles en un método Script y puede bloquear el comportamiento malicioso en tiempo real.
No. HTTPS protege los datos en tránsito entre el navegador y el servidor, pero un ataque man-in-the-browser opera dentro del navegador, después de que la página se descifra y antes de que un envío se cifre. El canal permanece válido mientras se manipula el contenido, así que el candado no ofrece ninguna protección aquí.
Un atacante man-in-the-middle intercepta el tráfico en la ruta de red entre el navegador y el servidor, algo que HTTPS derrota en gran medida. Man-in-the-browser se sitúa dentro del propio endpoint mediante malware, así que ve y edita datos que ya están descifrados. Esa ubicación le permite esquivar por completo el cifrado y muchas comprobaciones de doble factor.
We answer client-side security questions every day. Bring yours.