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.
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:
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
¿Desde cuando no tener bugs es ser seguro?
@anonimo
¿Desde cuándo tener vulnerabilidades ya no vale para llamar inseguro a [s]nadie[/s] algunos?.
@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
@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!
Publicar un comentario