elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.


 


Tema destacado: Comparativa y análisis mejores sistemas de videollamadas


+  Foro de elhacker.net
|-+  Seguridad Informática
| |-+  Bugs y Exploits
| | |-+  Nivel Web (Moderadores: sirdarckcat, WHK)
| | | |-+  Firefox es inseguro contra ataques XSS reflejados?
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: [1] Ir Abajo Respuesta Imprimir
Autor Tema: Firefox es inseguro contra ataques XSS reflejados?  (Leído 2,901 veces)
Ethicalsk

Desconectado Desconectado

Mensajes: 113



Ver Perfil
Firefox es inseguro contra ataques XSS reflejados?
« en: 2 Septiembre 2017, 07:57 »

Buenas! Estuve probando atacarme via XSS, y Chrome viene con el filtro anti XSS (el XSS Auditor)  que impide ejecutar javascript si el mismo es enviado en el enlace... Estuve revisando las configuraciones de Chrome y note que no se puede desactivar dicho filtro desde el navegador, la única forma en la que pude lograr un ataque XSS a través de Chrome fue utilizando

Header set X-XSS-Protection 0

en mi Apache... Forzando con ésta cabecera a desactivar el filtro anti XSS de Chrome... Según lei hubo formas para bypassear dichos filtros en distintas versiones, pero dudo que se pueda bypassear la version mas actual de Chrome...

En cuanto a Internet Explorer, también cuenta con el filtro anti XSS y se puede forzar/desactivar también a través del X-XSS-Protection. La diferencia que note respecto a Chrome es que Internet Explorer tambien permite desactivar dicho filtro a través de la configuracion en el mismo navegador...

Bueno, todo ésto es lo que probé hasta ahora, tal vez este equivocado con lo que digo, y tal vez haya formas de bypassear filtros de Chrome en versiones actuales, o también se pueda desactivar el filtro de Chrome desde el navegador y yo no lo sepa... En ese caso me gustaría que me corrigieran.

Respecto a Firefox, noté que no cuenta con ningún filtro... Puedo ejecutar javascript desde el enlace aunque el servidor de la pagina tenga el header

X-XSS-Protection 1; mode=block

lo cual me parece bastante mal, ya que si bien hay muchas formas de evitar ataques de XSS (a través de código seguro, y adicionalmente WAFs), me parece que Firefox está quitando una capa adicional de seguridad, y ésto lo convierte en un navegador poco seguro... Ustedes que piensan?

Saludos y gracias!
« Última modificación: 2 Octubre 2017, 07:01 por Ethicalsk » En línea

WHK
Moderador
***
Desconectado Desconectado

Mensajes: 6.308


The Hacktivism is not a crime


Ver Perfil WWW
Re: Firefox es inseguro contra ataques XSS reflejados?
« Respuesta #1 en: 29 Septiembre 2017, 15:33 »

Los filtros anti xss son solo una mitigación y no una solución, eso quiere decir que te ayudan pero no te solucionan un problema, de hecho si buscas en la pagina oficial de microsoft ni si quiera ellos recomiendan que la gente confíe en sus filtros anti xss del lado del servidor y del navegador.

Te puedo decir que hoy todos los filtros antixss son bypaseables, todos los dias me toca bypasearlos para crear pruebas de conceptos de vulnerabilidades que encuentro en sitios webs, tanto en google chrome como en internet explorer, mod security de apache y el filtro nativo antixss de internet information service (iis).

Ahora, ¿firefox debiera tener un filtro anti xss?, por otro lado, que un navegador no tenga este tipo de filtros no los hace menos seguros, por lo contrario, para mi firefox es mucho mas seguro que chrome tanto en la confidencialidad en al manipulación de los datos como en la tecnología misma.

¿Sabias que el filtro anti xss permitió que los sitios webs que no eran vulnerables fueran vulnerables?, a esto se le llamó XSS universal debido a que a traves de una dirección url podias manipular el comportamiento del filtro que se supone debia protegerte para que ejecutara un xss a pesar de que el sitio web no tuviera xss.

Asi que, volviendo a tu pregunta, hace menos seguro Firefox por no tener un filtro anti xss? mi respuesta es no, la seguridad de un ambiente o aplicativo no radica en la cantidad de capas de seguridad que tenga sino en la calidad de ellas, puedes tener todo un datacenter con la mejor tecnología de seguridad y la mas costosa del mercado pero puede que te sirva menos que tomar todo ese dinero e invertirlo en capacitar a los desarrolladores del aplicativo web, en este caso firefox tiene mucha ingeniería en temas de seguridad que están muy de punta, aunque esto no quiere decir que es inhackeable, pero eso es un tema totalmente diferente.

Saludos.
En línea

Telegram: @WHK102
Ethicalsk

Desconectado Desconectado

Mensajes: 113



Ver Perfil
Re: Firefox es inseguro contra ataques XSS reflejados?
« Respuesta #2 en: 30 Septiembre 2017, 06:53 »

Impecable respuesta WHK!!! Te agradezco mucho por tu tiempo, y ya que te tengo te quería preguntar si las técnicas que mencionas en éste post:

http://foro.elhacker.net/nivel_web/tutotial_bypaseando_un_firewall_waf_mod_security_de_apache_y_filtros_de_iis-t449489.0.html

son todavía aplicables hoy en dia. En tal caso quedaría cubierto el salteo del firewall, del waf, y los filtros iis. Pero me gustaría también tener información sobre como saltear los filtros de Chrome por ejemplo, ya que lo último que había leído es un artículo de Elevenpaths del 2014:

http://blog.elevenpaths.com/2014/01/how-to-bypass-antixss-filter-in-chrome.html

Si tenés algún articulo que me pueda instruir sobre técnicas más actuales, estaría muy agradecido. ya me queda poco de la guía de prueba de OWASP, una vez que la termine me encataría leer en detalle tu post y también otra información sobre bypass a filtros de navegadores.

Muchas gracias nuevamente.

Saludos!
En línea

WHK
Moderador
***
Desconectado Desconectado

Mensajes: 6.308


The Hacktivism is not a crime


Ver Perfil WWW
Re: Firefox es inseguro contra ataques XSS reflejados?
« Respuesta #3 en: 30 Septiembre 2017, 20:28 »

Pues ese tema de los filtros es muy muy extenso, pero si te puedo dar algunos tips.

¿Cómo google chrome, Internet explorer e IIS saben que deben detener un XSS y no un falso positivo?, utilizan dos técnicas:

* El filtrado
* Comparación I/O

Esto quiere decir que existen dos capas antes de llegar al bloqueo, el filtrado es cuando detectan que tu solicitud http ya sea en el request o en el body de la petición viene una mezcla de carácteres inseguros (payload), como por ejemplo etiquetas html, para esto la mayoría usan expresiones regulares, chrome es un poco mas complejo ya que usa otro tipo de filtrado donde evalua caso a caso los caracteres. Ahora, que detecte un contenido HTML no quiere decir que necesariamente sea un ataque por lo cual viene una segunda capa que es la comprobación I/O, o sea input de entrada v/s output de salida, si el contenido que retorna el sitio WEB contiene parte del contenido malicioso detectado por el primer filtro (o sea, si pongo un <script> en la url y aparece en el código devuelto por el sitio web) entonces ahi recién detiene la carga del sitio y alerta de un posible ataque de tipo XSS.

Ahora, con respecto a esto, donde la mayoría de las personas erran es intentar bypasear la primera capa la cual está lleno de reglas fuertes, bypaseables pero fuertes en ves de buscar bypasear la segunda capa y ahi es donde viene lo entretenido.

Por ejemplo, supongamos un escenario de un sistema que me tocó ver el mes pasado: Existe una compañía donde por norma de Active Directory todos los usuarios de la organización que usan windows solo pueden utilizar Google Chrome para mitigar los ataques de tipo XSS utilizando el filtro nativo pero tienen un portal WEB con un XSS y nos tocó comprobar que esa capa de protección de Google Chrome no era suficiente. El problema consistía en que el sitio WEB vulnerable tenía un XSS en una sección donde se podian guardar comentarios de páginas, el proceso era el siguiente:

Estabas en el sitio web y querias postear un comentario -> Este comentario era enviado por Ajax/javascript al servidor a traves de una petición post, el servidor solo devolvía un mensaje "OK", -> luego javascript al saber que el servidor retornó ese OK refrescaba el contenido de los comentarios apareciendo el comentario insertado. Bueno, esto era vulnerable a un XSS persistente.

[          Usuario envía comentario         ]
                      ↓
[            javascript: HTTP/POST          ]
                      ↓
[ Detección Google Chrome: Input: positivo  ] <-
                      ↓
[              Solicitud HTTP               ]
                      ↓
[    Respuesta WEB: "OK" text/plaintext     ]
                      ↓
[ Detección Google Chrome: Output: negativo ] <- !!


¿Donde estaba el problema? que Google Chrome perdió la segunda capa de validación debido a que el sistema WEB no retorna el contenido enviado, por lo cual para el navegador no hay ataque y tampoco tiene como saber que el contenido HTML que aparecerá después en un comentario fue el ingresado en la solicitud HTTP/POST.

Explotación: se ćreó un formulario html oculto dentro de una página de pruebas y al momento de ingresar este se enviaba al sitio web con el contenido HTML a insertar en el comentario (XSS), el sitio web original al solo responder un "OK" imposibilitó a Google Chrome entender si se trataba de un ataque o no por lo cual no lo detuvo, luego de esto el mismo sitio web de pruebas redireccionó al usuario hacia la página de comentarios para que le apareciese el XSS y listo!

Como ves, el filtro anti XSS no sirvió de nada porque para detener ataques de debe cumplir todo un flujo y puedes interrumpirlo en diferentes partes no solo bypaseando reglas.

Por otro lado si colocas un caracter que el contenido HTML no imprime entonces tampoco lo detecta, por ejemplo: <script>/*%01*/alert(0);</script> ya que el filtro esperará a que aparezca toda la cadena no solo una parte de ella y en la mayoría de los servidores webs estos caracteres no se interpretan como por ejemplo .net sobre IIS., también es posible crear un bypass utilizando filtros de eliminación de caracteres nativo como un censurador de palabras, por ejemplo si te censuran "fuck" entonces escribes: <scrifuckpt>alert(0)</script>, entonces el filtro esperará a que la etiqueta completa aparezca en el contenido HTML para detectar si realmente fue un ataque pero como el sistema WEB eliminó la palabra censurada dejó al descubierto la etiqueta script.

Y de esta manera hay muchas maneras de bypasear filtros, otra manera es creando etiquetas personalizadas no estandarizadas pero si interpretables abusando de la tecnología que vienen en todos los navegadores WEBs sobre la "tolerancia a errores", por ejemplo: <x style="position:absolute;left:0;width:100%;height:100%;background-image:url(http://...phishing.jpg)"> ya que la etiqueta x no existe, por lo general tanto google chrome como internet explorer y mas del 90% de los waf solo buscan etiquetas conocidas ya que se apegan mucho al estandard de la w3c, pero no funcionan como un navegador web el cual interpreta contenido, los navegadores no funcionan de manera tan estricta como un waf y ahi es donde es posible aprovecharse para realizar un bypass.

En fin, podría estar todo el día sobre como bypasear filtros anti xss, aunque tampoco quiero decir que sean un desperdicio, respeto mucho a la gente que hace estos tipos de filtros porque se requiere mucho conocimiento y dedicación, a demás si frena ataques básicos, pero nunca será algo efectivo como para depositar la confianza en ellos.

Artículos sobre esto? pues no conozco muchos, he visto uno o dos en pdf escritos en ingles y la verdad es que entiendo poco porque no me gusta el inglés. Pero deben haber muchos dando vuelta por internet, basta buscar sobre "xss filter bypass", hay algunos de defcon y otros de whitehat.

No conozco tu interés en conocer del tema pero si buscas como atacar averigua más, pero si buscas como solucionar entonces no pierdas tu tiempo y enfócate en como aumentar la productividad y seguridad en los aplicativos con buenas prácticas.

Saludos.
« Última modificación: 30 Septiembre 2017, 20:37 por WHK » En línea

Telegram: @WHK102
Ethicalsk

Desconectado Desconectado

Mensajes: 113



Ver Perfil
Re: Firefox es inseguro contra ataques XSS reflejados?
« Respuesta #4 en: 30 Septiembre 2017, 23:27 »

Muchisimas gracias WHK! Entre ayer y hoy leí tu post sobre el arte del bypassing, y agregando ésto que me respondiste hoy me hiciste abrir la cabeza un montón. No tenía idea de la segunda capa de comprobación, y que solo bypasseando a ésta ya es suficiente para bypassear el sistema completo del navegador o de ISS. Estaría genial que escribieras un libro en español sobre todo lo que sabes de bypassing, ya que si bien hay mucha información dando vueltas, la mayoría está en inglés, y no está todo tan bien organizado y en un solo lugar como el post que hiciste por ejemplo. Gracias nuevamente.

Saludos!
« Última modificación: 30 Septiembre 2017, 23:35 por Ethicalsk » En línea

Páginas: [1] Ir Arriba Respuesta Imprimir 

Ir a:  

Mensajes similares
Asunto Iniciado por Respuestas Vistas Último mensaje
Protección contra ataques (DDOS)
Seguridad
Eleкtro 6 5,634 Último mensaje 13 Julio 2013, 11:43
por Eleкtro
Seguridad contra ataques de XSS « 1 2 »
Seguridad
Yaldabaot 17 6,637 Último mensaje 22 Agosto 2013, 23:29
por #!drvy
Seguridad contra ataques ddos... « 1 2 »
Seguridad
@Zaηυт Sєc 10 3,775 Último mensaje 5 Marzo 2015, 20:42
por nevachana
Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines