Para los que les interesen estos temas, pueden descargar (requiere tener una cuenta passport) los siguientes libros:
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.
Firefox es, desde que pude pagar por mis propios medios una conexión ADSL --a mediados del 2004 aproximadamente 🙂 , el navegador que uso casi para todo; aunque inicialmente me subí al coche sólo por ser Software Libre, ahora sin duda es una herramienta que no puede faltar en mi entorno de desarrollo.
Retomando el tema de la entrada, puesto que generalmente las cosas que salen de Microsoft sólo funcionan bien en Internet Explorer, el control ReportViewer no genera el HTML/CSS adecuado para que los reportes se muestren correctamente en Firefox:
Luego de revisar un poco la estructura del documento que genera ese control (gracias a Firebug), pude preparar un pequeño código para que al menos se muestre el reporte completo, las líneas que importan están resaltadas:
<%@ Register Assembly="Microsoft.ReportViewer.WebForms, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
Namespace="Microsoft.Reporting.WebForms" TagPrefix="rsweb" %>
<!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" >
<head runat="server">
<title>Untitled Page</title>
<script type="text/javascript">
</script>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:Button ID="cmdExportar" runat="server" OnClick="cmdExportar_Click" Text="Button" />
<rsweb:ReportViewer ID="ReportViewer1" runat="server" Font-Names="Verdana" Font-Size="8pt"
Height="400px" Width="100%">
<LocalReport ReportPath="Productos.rdlc">
</LocalReport>
</rsweb:ReportViewer>
</div>
</form>
</body>
</html>
Es evidente que este hack sólo funcionará si el reporte está en el mismo servidor que la aplicación Web, esto debido a las restricciones de seguridad que imponen los navegadores sobre los i/frames.
No sé si a alguien más aparte de mi le vaya a servir esta entrada, sólo lo comento por el desazón que tuve durante algunas jornadas de trabajo 😉
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:
$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();
?>
Javascript doesn’t suck, you do!