Category: Seguridad
Artículos y opiniones sobre seguridad Web, SQL Injection, XSS, etc.
Muchas veces he querido habilitar la suscripción de usuarios en este blog por diferentes motivos: problemas con el spam, evitar que se muestre publicidad a lectores habituales, etc; pero todas esas veces tuve que desistir porque de un modo u otro he ido descubriendo que esta opción puede "costarme caro" si es que algún usuario malintencionado tiene algo en contra mía. 😀
Entre los problemas que recuerdo haber reportado y que requerían del registro de usuarios activado tenemos los siguientes:
- Inyección de SQL en WordPress 2.2 a través del método
wp.suggestCategories - Usuarios sin privilegios de administrador podían realizar ciertas acciones como activación/desactivación de plugins, cambiar la apariencia del sitio, etc.
- Problemas de seguridad variados: XSS, inyección de SQL, etc.
Volviendo al tema central, este problema de seguridad del que había comentado meses atrás en el blog de David, permite que un usuario registrado obtenga la lista completa de usuarios, roles y correos electrónicos del blog o sitio afectado. El proceso para recuperar esta lista es bastante sencilla y sólo basta invocar al método wp.getAuthors a través de la interface XMLRPC:
php:
<?php
include './class-IXR.php';
include './class-IXR.php';
$client = new IXR_Client('http://dominio.com/xmlrpc.php');
$client->query('wp.getAuthors', 1, 'alex', '1234');
$response = $client->getResponse();
print_r($response);
?>
Luego de reportar este problema leve en wordpress.com (y por consiguiente cualquier otro sitio basado en WordPress MU), ya existe un ticket con parche incluido que pone fin a esta situación y es recomendable que actualicen aquellos sitios que tengan la suscripción de usuarios habilitada.
Desde hace dos semanas aproximadamente, cambió la forma como se almacenan las contraseñas en la versión en desarrollo de WordPress, ahora ya no se almacena el hash md5 de la contraseña en la base de datos -- como se hace en muchos otros CMS, sino se usa phpass (Portable PHP password hashing framework) para esta tarea.
Por otro lado, también hubo un cambio en generación de cookies de autenticación, que en la actualidad son fácilmente generados a partir del hash de la contraseña almacenada en la base de datos. Esta nueva implementación está basado en el paper "A Secure Cookie Protocol" (pdf).
Sin duda estos cambios son importantes y de seguro reducirán la acción de ciertos problemas de seguridad que se basaban sólo en obtener el hash almacenado.
Luego de que alguien hiciera eco sobre un falso problema de inyección de SQL en WordPress 2.3.1, esta vez han publicado detalles de un bug que permite realizar este tipo de ataques en las ramas 2.2 y 2.3 (podría afectar a versiones anteriores también). Antes de pegar un grito al cielo y maldecir a los programadores de WordPress, vale aclarar que este bug sólo se puede reproducir siempre y cuando la codificación de la base de datos sea SJIS, BIG5 o GBK.
El problema radica en que en los juegos de caracteres de ancho variable mencionados, es posible que a partir de secuencias de caracteres no válidas y luego de aplicar la función addslashes, se pueda realizar ataques de inyección de SQL. Por ejemplo en la prueba de concepto del mencionado bug envían la secuencia 0xb327 (caracter multi-byte no válido en Big5) que luego de aplicarle la función addslashes la cadena resultante será 0xb35c27 (notar que el caracter \ = 0x5c se agregó antes de la comilla simple ' = 0x27), sin embargo en esta codificación la secuencia 0xb35c (許) es un caracter multi-byte válido por lo que en realidad la cadena resultante tendría la comilla simple sin escapar (許').
Dado que WordPress cambia la codificación de la conexión con SET NAMES 'GBK' (que es lo que hace cuando se especifica un valor para DB_CHARSET en el archivo de configuración), este problema de seguridad tendrá los mismos efectos aún usando la función mysql_real_escape_string.
Actualización: He subido un ejemplo que ilustra el problema descrito. El código de ese ejemplo es el siguiente por si quieren hacer pruebas:
php:
<?php
header('Content-Type: text/plain; charset=Big5');
header('Content-Type: text/plain; charset=Big5');
$login = chr(0xB3).chr(0x27) . ' UNION ALL SELECT * FROM foo /*';
if ( isset($_GET['login']) )
$login = stripslashes($_GET['login']);
$sql = "SELECT * FROM wp_posts WHERE login = '%s'\n";
echo sprintf($sql, addslashes($login));
mysql_connect('localhost', 'tests', '1234');
mysql_query('SET NAMES Big5');
echo sprintf($sql, mysql_real_escape_string($login));
mysql_close();
?>
Lectura recomendada
Por si no lo vieron todavía, una serie de videos introductorios -- en inglés -- sobre seguridad en ASP.NET:
- Canonicalization: Explica sobre los ACLs e impersonación de usuarios para acceder a recursos, así como usar
Server.MapPathpara limitar el acceso sólo a rutas que esten dentro del directorio virtual de una aplicación. - Cookies: Muestra como detectar la alteración de cookies.
- Cross-Site Scripting: Explica que es XSS y como prevenir éstos ataques.
- Regular Expressions: Explica el uso de expresiones regulares para la validación de los datos.
- SQL Injection: Explica que es SQL Injection y cómo evitar este tipo de ataques usando consultas parametrizadas.
- Validation Controls
Fuente: Blog de J.D. Meier