¿Configurar Firefox contra redireccionamiento 302 malicioso desde un recurso de imagen incrustado?

1

Hoy mi amigo demostró tal ataque.

Estoy usando RenRen, un sitio web de redes sociales muy parecido a Facebook en China. Y vi un artículo que escribió. En realidad, solo hay una "imagen" incrustada en este artículo, como esta:

<img src="http://somesite.org/x.php" ... >

Cuando un navegador intenta solicitar esta URL, los encabezados de HTTP son una redirección temporal 302 y el destino es la página de cierre de sesión de RenRen, por ejemplo:

www.renren.com/logout.do 

Sé que permitir que exista tal imagen en un artículo publicado es un fallo del programador de RenRen. Pero en lugar de decirles que solucionen eso, quiero configurar mi navegador para que no lo haga. Algunos navegadores como Safari, como yo sabía, son resistentes a este tipo de ataque, posiblemente porque realiza la comprobación de tipo MIME. Pero no he encontrado una solución similar en Firefox, ni siquiera el complemento correcto. Parece que no funcionará NoScript con la configuración adecuada, pero aún no estoy seguro.

Por lo tanto, me gustaría saber cómo clasificar este tipo de ataques y cómo prevenirlos, no solo para Firefox ...

    
pregunta Lucifer Orichalcum 20.08.2013 - 12:33
fuente

4 respuestas

2

Usted no puede defenderse proactivamente contra esta clase de ataques. Considera:

  • el archivo fuente contiene una URL http.

    • No puedes saber si es malicioso o no.
    • No desea evitar que se cargue (bloquearía el ataque, pero pero también haría que varios sitios de repositorios de imágenes legítimos no valgan la pena).
  • entonces tienes que solicitar esa URL.

    • la acción de cierre de sesión se activa al solicitar , por lo que cuando el navegador recibe una página HTTP / 200 OK text/html que dice "Has cerrado la sesión con éxito", incluso si se niega para mostrarlo, el comando ya se ha completado .

Puedes organizar las cosas para que el ataque falle , sin embargo.

Podrías eliminar todos los identificadores de sesión de cualquier solicitud tan pronto como llegues a un Redireccionamiento , para que la página de cierre de sesión ya no te reconozca. Esto podría ser factible con una extensión de Firefox. De esta manera, tendrías:

lucifer -> renren:   get me the message
renren  -> lucifer:  there is an image here
lucifer(*) -> somesite: get me the image
somesite-> lucifer:  go to renren/logout
(the request thread drops the cookie jar and becomes anonymous)
anonymous->renren:   get me the logout
renren->anonymous:   logout who? Error. Cannot logout.
(the request thread expires)

(*) en realidad, su ID de cookie con renren es no enviada a somesite , ya que es probable que esté en otro dominio.

Esto podría provocar un mal funcionamiento en algunas aplicaciones AJAX y posiblemente en implementaciones de OAuth; Tendría que revisar esto.

    
respondido por el LSerni 20.08.2013 - 14:09
fuente
0

Este tipo de ataque se clasifica, según mi conocimiento, como un ataque CSRF (falsificación de solicitudes en sitios) y, en general, no puede defenderse.

No conozco una forma de configurar Firefox para bloquear ese tipo de ataques, pero hay (como usted dijo) NoScript, que viene con una buena característica, ABE (Application Boundaries Enforcer) que le permite especificar cuál Los sitios web pueden acceder a otros sitios.

Puede configurar ABE a través de Configuración - > Avanzado - > ABE. Allí puede seleccionar el conjunto de reglas USUARIO, donde puede definir las reglas que desea aplicar.

Un ejemplo para bloquear todos los accesos que intentan incluir ( <img> , <script> ...) los recursos de renren.com y todos los subsitios, que no se originaron en renren.com o en un subsitio :

Site .renren.com
Accept from .renren.com
Deny INCLUSION

Una desventaja de esa manera es que, si renren.com proporciona medios para incrustar imágenes en otros sitios web, eso también se bloquearía, pero probablemente podría solucionarse utilizando Anonymize , para ese fin. Por otro lado, si desea ser aún más restrictivo, puede omitir INCLUSION , lo que resultará en incluso el bloqueo de enlaces y redirecciones en los enlaces en los que hizo clic.

La diferencia entre las acciones Deny y Anonymize es que la acción Deny bloquea completamente la solicitud, mientras que la acción Anonymize elimina el encabezado de Autorización y el encabezado de la Cookie y convierte todas las solicitudes que no sean GET (es decir, POST, HEAD, PUT ...) en solicitudes GET sin datos. El resultado de esto es que el sitio web (generalmente) no puede asociar la solicitud con una sesión, y /logout.do no puede terminar la sesión, porque no sabe qué sesión tendría que finalizar, sino imágenes incrustadas en otros. Aparecerán los sitios web que no requieren una sesión para trabajar. Una desventaja de la acción Anonymize es que nunca muestra una barra de información en la que NoScript anonimizó la solicitud, pero la anonimiza silenciosamente, por lo que si está utilizando Anonymize y algo no funciona como debería , intente usar Deny , que mostrará una barra de información en la parte superior de la pantalla si bloquea algo.

Si está utilizando un servicio diferente para iniciar sesión en renren.com como MSN, 360.cn, 189.cn o Baidu (enumerados en el orden de aparición en renren.com), entonces, con solo bloquear INCLUSION puede (es bastante improbable) que tenga que poner una cláusula Accept (ejemplo: Accept from openapi.baidu.com ) para el sitio correspondiente también, si bloquea todo, entonces tendrá que poner uno en el conjunto de reglas.

Más información sobre ABE está disponible aquí .

    
respondido por el Michael Ehrenreich 20.08.2013 - 15:38
fuente
0

Esta es una falsificación de solicitudes entre sitios (CSRF) en la vulnerabilidad www.renren.com sitio web. Deberían haber implementado la página logout.do para cerrar la sesión solo al usuario cuando se realiza un POST requst que contiene un token en la carga útil que validan para garantizar que la solicitud de cierre de sesión proviene de un usuario en su propio sitio.

Esto debería poder controlarlo deshabilitando Cookies de terceros . Cuando deshabilite las cookies de terceros en Chrome , lo hará impide que el dominio de terceros lea la cookie, por lo que la página www.renren.com/logout.do no podrá cerrar sesión a menos que se solicite en una nueva ventana o pestaña. No he podido encontrar una respuesta clara si Firefox permite leer las cookies de terceros cuando acepta las cookies de terceros están configuradas como deshabilitadas , pero puede probar esto y ver si el <img src="http://example.org/x.php" /> exploit falla.

    
respondido por el SilverlightFox 21.08.2013 - 16:14
fuente
-2

Añadir

127.0.0.1 somesite.org

A su archivo de hosts, o bloquéelo en el firewall o en el proxy.

    
respondido por el symcbean 20.08.2013 - 13:03
fuente

Lea otras preguntas en las etiquetas