Imagina el siguiente escenario: el usuario está en attacker.com y juega un juego allí. Justo antes de que haga clic en algún punto, se le redirige a victim.com utilizando el historial del navegador. El usuario pensó que hizo clic en attacker.com pero realmente hizo clic en victim.com , lo que implicó una operación no deseada. Consulte la demostración en enlace .
¿Cómo puede el propietario de victim.com protegerse de tales ataques? ¿Y él debería?
Los ataques de navegación de Zalewski y navegación de distancia se basan en la navegación sin desenfocar la ventana; especialmente en el caso más suave donde la operación de "retroceso" activa el bfcache, es poco probable que incluso obtenga un evento onblur o onfocus !
Estos pueden contrarrestarse detectando que su ventana ha sido abierta por un script. Esto se puede hacer comprobando window.opener ; También vale la pena buscar window.name , ya que una ventana con nombre puede ser "encontrada" por window.open .
Esto normalmente se agregaría a una secuencia de comandos de interrupción de marco, por ejemplo:
if (top!==self || opener!==null || name!=='') {
// countermeasure
}
donde la contramedida sería algo así como ocultar / desactivar todo el contenido de la página (no navegar por la parte superior, ya que es muy fácil de detener).
Al igual que con los rompedores de marcos en general, esto requiere JavaScript, por lo que no funcionará si está desactivado y podría ser atacado a través del filtro anti-XSS falso de IE (si no lo ha desactivado con X-XSS-Protection ). Si usted es una aplicación que se basa en JS y no necesita accesibilidad solo de HTML, puede denegarla por defecto aquí para obtener más confiabilidad.
Naturalmente, si haces esto, tú o tus socios tampoco podrán abrir tu página en una ventana emergente.
Hay otros ataques similares que involucran el cierre de pestañas o ventanas emergentes para hacer que el contenido de su página aparezca debajo del puntero, pero son menos suaves que los ataques de variedad de navegación. En estos casos, do obtiene onfocus / onblur y es razonable reaccionar haciendo que la interfaz esté inactiva durante un período después de onfocus si hay una página que le preocupa especialmente protegiendo.
Una mitigación general para toda la clase de vulnerabilidades sería no hacer que cualquier operación peligrosa se realice desde un solo clic en una página a la que se puede acceder directamente. Esto suena débil, pero probablemente encontrará que ya lo está haciendo naturalmente en muchos casos por razones que no son de seguridad, por ejemplo, Eliminar cuenta - > "¿Está seguro de que desea eliminar permanentemente su cuenta?".
En teoría, el operador del sitio web puede evitar tales ataques mediante el uso de los eventos window onfocus y onblur . Por ejemplo, en la ventana del evento onfocus , se podría crear una superposición <div> en toda la página durante medio segundo, evitando así la interacción con los elementos de la página. Sin embargo, no vi que se usara en ninguna parte, y no sospecho que vaya a ganar popularidad, ya que de todos modos es probable que se pueda pasar por alto.
El ataque que usted describe, creado por Michael Zalewski es solo uno de los muchos ataques novedosos de prueba de concepto que demuestran por qué la web es roto 'a un nivel fundamental. Algunos de sus ataques anteriores basados en la sincronización ( secuestro del consentimiento de geolocalización HTML5 ) explotaron vectores similares y se han corregido a nivel de navegador. Uno podría sospechar que esta clase de vulnerabilidades se solucionará en los navegadores en el futuro (posiblemente lejano), pero son muy difíciles de solucionar ya que explotan las imperfecciones humanas que pueden manifestarse de varias maneras.
En pocas palabras: puede intentar experimentar con los eventos onfocus y onblur , pero prepárese para peculiaridades del navegador y no pierdas demasiado tiempo en ello. Es poco probable que sea abusado masivamente por los sombreros negros.
Lea otras preguntas en las etiquetas appsec attack-prevention