Hoy acaban de anunciar que ya existe un versión estable de PHPIDS, un sistema de detección de intrusos basado en expresiones regulares. Pueden descargar el código desde el repositorio o hacer pruebas para ver como funciona esta pequeña librería.
Por otro lado, también existe .NETIDS, que es una versión en .NET -- realizada por Martin Hinks -- de PHPIDS.
El primero tiene que ver con un pequeño problema de seguridad que permite a cualquier usuario eliminar los archivos adjuntos que se suben utilizando WordPress, para corregirlo tienen que buscar la función mw_newMediaObject en xmlrpc.php. En la siguiente porción de código, se muestra como debería quedar finalmente esa función.
global $wpdb;
$blog_ID = (int) $args[0];
$user_login = $wpdb->escape($args[1]);
$user_pass = $wpdb->escape($args[2]);
$data = $args[3];
$name = sanitize_file_name( $data['name'] );
$type = $data['type'];
$bits = $data['bits'];
if(!empty($data["overwrite"]) && ($data["overwrite"] == true)) {
// Get postmeta info on the object.
$old_file = $wpdb->get_row("
SELECT ID
FROM {$wpdb->posts}
WHERE post_title = '{$name}'
AND post_type = 'attachment'
");
// Delete previous file.
wp_delete_attachment($old_file->ID);
// Make sure the new name is different by pre-pending the
// previous post id.
$filename = preg_replace("/^wpid\d+-/", "", $name);
$name = "wpid{$old_file->ID}-{$filename}";
}
$upload = wp_upload_bits($name, $type, $bits, $overwrite);
if ( ! empty($upload['error']) ) {
$errorString = 'Could not write file ' . $name . ' (' . $upload['error'] . ')';
logIO('O', '(MW) ' . $errorString);
return new IXR_Error(500, $errorString);
}
// Construct the attachment array
// attach to post_id -1
$post_id = -1;
$attachment = array(
'post_title' => $name,
'post_content' => '',
'post_type' => 'attachment',
'post_parent' => $post_id,
'post_mime_type' => $type,
'guid' => $upload[ 'url' ]
);
// Save the data
$id = wp_insert_attachment( $attachment, $upload[ 'file' ], $post_id );
wp_update_attachment_metadata( $id, wp_generate_attachment_metadata( $id, $upload['file'] ) );
return apply_filters( 'wp_handle_upload', array( 'file' => $name, 'url' => $upload[ 'url' ], 'type' => $type ) );
}
El segundo cambio, es más cosmético y es para que los emoticonos se muestren aún cuando éstos no estén rodeados de espacios o inicio y fin de cadena ;).
Tienen que cambiar la siguiente línea (vars.php:90 en la versión 2.1 y wp-includes/functions.php:1477 en la versión 2.2):
por
*: Este problema si no me equivoco, afecta a la versión 2.2 y 2.1.
Una pregunta que normalmente veo en los foros que participo, se relaciona con el tema de la codificación de una aplicación Web, normalmente se ven preguntas como: configuración para admitir caracteres como la "ñ", codificación de caracteres deseada, problema con tildes, tildes y caracteres especiales o algunas variantes más.
La mayoría de veces intentan establecer esta codificación usando el elemento HTML meta:
En otros lenguajes de programación como PHP esto funciona sin problemas porque no se envía automáticamente una cabecera HTTP que indique el tipo de documento y la codificación, pero en el caso de páginas que son procesadas por ASP.NET no ocurre esto, puesto que en cada documento que se envía al cliente, se especifica explícitamente el tipo y la codificación de la página. Si observamos parte del código del método GenerateResponseHeaders de la clase HttpResponse, se puede apreciar porque pasa eso.
Si no se especifica algún otro valor para la codificación (Charset) desde el código, este es tomado del elemento globalization del Web.config o machine.config.
En conclusión, utilizar sólo el elemento meta en páginas procesadas por ASP.NET no es suficiente, puesto que los navegadores -- al parecer -- prefieren el valor que se envía en las cabeceras HTTP.
WordPress MU, es una versión de WordPress que soporta múltiples blogs. Tanto WordPress como WordPress MU comparten gran parte de código y por lo tanto, es lógico que casi siempre sufran los mismos problemas de seguridad*.
Luego de mirar un rato el código de la última versión estable de WordPress MU, veo que el casi inofensivo** problema de seguridad que reporté el lunes pasado en WordPress, tiene consecuencias más peligrosas en la versión multiblog puesto que cualquiera puede registrarse en sitios que usen este CMS. Por las pruebas que hice, el exploit funciona sin realizar ningún cambio.
Por otro lado, las versiones menores iguales a 1.2.1 son posiblemente vulnerables a todos los bugs reportados meses atrás. Por tanto, lo más seguro mientras liberan actualizaciones de seguridad es usar la versión en desarrollo.
*: un problema similar existe entre menéame y pligg, este último no ha corregido varios de los fallos reportados en el primero (y viceversa).
**: pocos blogs dejan que los usuarios se registren libremente.
Este es el resultado de tener abierto Firefox durante unos días:
Este consumo de memoria no sería problema siempre y cuando me deje trabajar bien, pero al llegar a este punto, el navegador se pone bastante lento al abrir/cerrar pestañas y entrar a cierto tipo de páginas (aquellas que contienen flash o hacen uso intensivo de javascript -- google reader, gmail).
Por el momento, no tengo intenciones de usar Internet Explorer u Opera (ninguno provee la misma funcionalidad que consigo con las extensiones de Firefox), así que tendré que seguir sufriendo hasta que los desarrolladores de este navegador provean mejoras en el consumo de memoria y rendimiento.