jueves, abril 25, 2013

Navegadores y passwords HTTP en ataques CSRF con IMG

Cuando escribí el artículo sobre el tema de las passwords HTTP en esquemas de Clickjacking y el comportamiento de los navegadores me quedó por probar cómo se comportarían los en un caso de CSRF (Cross-Site Request Forgery) en el que la password HTTP fuera en una URL dentro una etiqueta IMG, ya que me parecía a mí que iban a comérselo con patatas todos, así que le pedí a mi compañero Ricardo que hiciera las pruebas pertinentes. Sin embargo, no ha sido así, todos los navegadores no envían la contraseña... aunque si la gran mayoría.

Para hacer la prueba basta con poner un imagen en un servidor web protegida por usuario y contraseña y ver quién envía esos datos. Parecía lo más evidente sería que los navegadores que ya vimos que no tenían protección para iframe no iban a tener tampoco protección para etiquetas IMG, así que, como era de esperar Google Chrome y Mozilla Firefox envían el usuario y la password por HTTP en esquemas de CSRF.

Figura 1: Google Chrome 26 envía usuario y password en el campo Authorization

Si decodificamos el valor BASE 64 que va en él se verá que el resultado es que aparece el usuario y la contraseña que van en la URL del protocolo HTTP.

Figura 2: Campo Authorization decodificado de BASE 64.

Lo mismo sucede con Mozilla Firefox, tal y como se puede ver en la siguiente captura realizada con la misma prueba.

Figura 3: Mozilla Firefox también envía la password sin decir nada

El navegador en que tenía menos fe para tener protección era Apple Safari, y como era de esperar, en una URL de una etiqueta IMG que envía usuario y contraseña dentro de un posible esquema de CSRF, envía la contraseña. Esto lo suponía ya que en el caso del ataque CSRF de los routers se usaba un iPhone, así que era casi evidente.

Figura 4: Apple Safari envía la password HTTP

El último en discordia de los cuatro navegadores más populares era Internet Explorer, que a diferencia del resto, por motivos de seguridad, desde IE 7 se prohibió enviar las passwords por HTTP en etiquetas IMG para evitar los ataques CSRF.

Figura 5: Internet Explorer bloquea la petición

Supongo que viendo que IE fue el navegador con menos bugs en 2012 muchos ya suponéis que en el equipo de desarrollo de este producto en Microsoft se toman la seguridad en serio... al menos desde IE 7.

Saludos Malignos!

5 comentarios:

Anónimo dijo...

Nos queda la duda de saber quien es naranjitaputona. Pon la foto y no nos dejes con la miel en los labios.
Yo voto por la enana de Jersey Shore

Anónimo dijo...

¿Desde cuando no tener bugs es ser seguro?

Anónimo dijo...

@anonimo
¿Desde cuándo tener vulnerabilidades ya no vale para llamar inseguro a [s]nadie[/s] algunos?.

Anónimo dijo...

@Anónimo
Cierto, tener bugs hace que el programa sea inseguro, no quiere decir que por no tenerlos sea seguro como argumenta Chema en el último párrafo.


Si tiene bugs, entonces es inseguro.
No tiene bugs.
Por lo tanto, no es inseguro.

Falacia como un piano http://es.wikipedia.org/wiki/Negaci%C3%B3n_del_antecedente

Chema Alonso dijo...

@anónimo esta si que es buena. Años metiéndoos con MS porque tenía bugs y era inseguro y ahora me dices que tener menos bugs no lo hace menos inseguro (por tanto más seguro). A ver que utilices la negación de seguro (inseguro) para redactar tus frases no cambia la realidad.

Saludos!

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares