En la primera parte vimos un poco de los problemas que tiene usar $_SERVER['PHP_SELF'] sin ningún tipo de validación. Para esta segunda parte, he preparado un pequeño quiz que básicamente refleja los problemas reportados en WordPress.
La siguiente porción de código es una versión resumida del contenido de los archivos wp-includes/vars.php y wp-includes/functions.php (función wp_nonce_ays):
$PHP_SELF = $_SERVER['PHP_SELF'];
if ( preg_match('#([^/]+\.php)$#', $PHP_SELF, $self_matches) ) {
$pagina_actual = $self_matches[1];
} else {
$pagina_actual = 'wp.php';
}
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" lang="es">
<head>
<title>Wordpress demo</title>
</head>
<body id="main">
<form action="<?php echo $pagina_actual; ?>" method="post">
<input name="foo" id="foo" type="text" tabindex="0" />
<input name="postback" id="postback" type="submit" value="Enviar" tabindex="1" />
</form>
</body>
</html>
¿Algún ejemplo que aproveche el bug que existe en el código de prueba? (de preferencia que funcione en varios navegadores)
Nota: Por motivos de seguridad no voy a facilitarles una página de prueba, puesto que por más que ponga los ejemplos en un subdominio, éstos son accesibles también desde el dominio principal, haciendo vulnerable a XSS mi instalación de WordPress 😀 --quise usar Dreamhost, pero para este caso no sirve.
5 replies on “WordPress, XSS y CSRF – Parte 2”
Bueno es muy facil...
Realmente el chiste es que no usemos "/" y que todo termine como .php, lo ultimo es muy facil y el primero es un poquito (muy poquito) mas dificil, realmente usando algun tag que no se tenga que cerrar y puedes meter codigo "malicioso" lo pasas
Bueno tus website/filtros no me dejan pues poner mi respuesta de manera completa asi que la explicare...
Usamos el atributo onload del tag body, -asi como tu caso de meneame-, para evitar usar algun tag de cierre como lo tiene el tag script y claro para hacer que se mueva a otro sitio digamos la "web-del-atacante.com" donde lo espera un script en php que tome la variable por GET cookie para guardar la cookie procedente del website de la victima.
Ahora solo queda pues poner eso en lugar de XSS y terminarlo con .php para que se ejecute...
Para evitar el uso de "/" dentro de la cadena de url usamos el metodo fromCharCode de la clase String y asi podremos pasar bastante la proteccion...
Eso es todo, asi de simple y facil...
Saludos
En efecto g30rg3_x, sólo es usar una etiqueta que no necesite cerrarse.
El ejemplo que envié al equipo de WordPress es el siguiente, dependiendo de los permisos que tenga la víctima, es posible sobreescribir los archivos del tema actual sin ser afectados por la protección contra ataques CSRF que ofrece WordPress.
http://www.buayacorp.com/files/wordpress/wordpress-theme-exploit.txt
Saludos
PS. Si deseas poner código "peligroso", puedes hacerlo usando las etiquetas [ code][ /code] (sin los espacios)
[...] Últimos comentarios Alex en: WordPress, XSS y CSRF - Parte 2 [...]
Bueno realmente lo intente meter dentro de ese tag [ code][ /code]
Pero siempre se filtra todo lo que entre directamente entre "<" y ">", ahora (por que a la hora que vi tu quiz y lo respondi era bastante tarde aqui en mex :P) pues que ya tuve mas tiempo pude ver que tengo que meter esos caracteres como su Entidad HTML para evitar el filtrado.
Aqui te dejo lo considere mi respuesta a tu quiz...
Saludos
[...] WordPress, XSS y CSRF - Parte 2 [...]