Artículos sobre desarrollo de software en general
Interesante artículo publicado en un journal de IEEE (Julio-Agosto de 2004) donde Martin Stytz y James Whittaker explican la razón de porque los fallos de seguridad son más difíciles de encontrar que los fallos funcionales.
Pueden descargar este artículo de manera gratuita desde http://tinyurl.com/2jrmph (PDF, 81.3 KB)
Actualización (09/03/2007): Finalmente ya existe un parche oficial para el problema reportado el lunes pasado (Secunia Advisory SA24430, Ticket WordPress), como había comentado estos fallos afectaban a la rama 2.x y a la última versión de desarrollo, adicionalmente se han hecho correcciones en otros archivos más:
wp-admin/admin-functions.php (equivale al problema reportado en wp-admin/import/mt.php)wp-admin/admin-functions.phpwp-admin/custom-header.phpwp-admin/upload-functions.php (no reportado previamente)wp-includes/script-loader.php (no reportado previamente)wp-admin/admin-functions.phpwp-admin/custom-header.phpwp-admin/upload-functions.php (no reportado previamente)wp-includes/script-loader.php (no reportado previamente)El fallo todavía persiste en el plugin akismet, hasta que lo solucionen pueden usar la versión modificada que puse hace unos días.
Desde los casi tres años que vengo usando WordPress, es la primera vez que veo que se reportan con mayor frecuencia fallos de seguridad en este CMS, imagino que esto se debe a la popularidad que alcanzó y también a nuevas características que se añaden en cada versión mayor.
Por otro lado, uno de los aspectos que hace de WordPress una aplicación muy extensible y a la vez bastante insegura son los plugins, puesto que los que alguna vez desarrollamos uno de éstos, probablemente hayamos introducido algún fallo de tipo SQL Injection, XSS o el menos tomado en cuenta CSRF, que entre otras cosas van a comprometer la instalación principal de WordPress e inclusive el servidor donde se aloja éste.
Me parece que alguien debería evangelizar la escritura de plugins seguros por el daño que pueden causar sin son mal programados -de nada sirve que los desarrolladores de este CMS se "rompan el lomo" añadiendo características para hacer más seguro el core, si en los plugins casi nadie más las usa por desconocimiento o falta de documentación.
En fin, hago el comentario anterior, puesto gran parte de los plugins que actualmente estoy usando, tienen problemas de seguridad* (XSS y CSRF principalmente), que en la medida de lo posible, intentaré reportarlo a sus autores.
Luego de la larga y aburrida queja, paso a comentar que existen vulnerabilidades de tipo XSS en los siguientes archivos.
wp-admin/edit-comments.php: no se escapan parámetros arbitrarios al momento de realizar la paginación. Prueba de concepto.wp-admin/import/mt.php: no se escapa la url que se genera para el atributo action del formulario para importar un blog del tipo Movable Type. Prueba de concepto.wp-admin/custom-header.php: el mismo problema de validación de datos, no pongo una prueba de concepto porque no se puede acceder directamente a esta página.wp-content/plugins/akismet/akismet.php: el mismo problema del punto 1 al momento de paginar los comentarios de tipo spam, la prueba de concepto es parecida, sólo hay que agregar el parámetro page=akismet-admin.Al momento de publicar esta entrada programada, seguramente ya habrá un parche oficial en la página de reporte de incidencias de WordPress (aunque hice el reporte a través de security@wordpress.org), pero para los impacientes pongo una solución temporal (**).
Actualización (06/03/2007): Los fallos en wp-admin/edit-comments.php y wp-admin/custom-header.php sólo se pueden reproducir a partir de la rama 2.1.x, el de wp-admin/import/mt.php y akismet me parece que a partir de la rama 2.0.x.
*: Si, también los plugins que desarrollé tienen estos problemas 😀 , pero estoy aprendiendo.
**: Los archivos modificados corresponden a la versión 2.1.2 (ver diferencias), úsenlo bajo vuestra responsabilidad.
Esta es la primera de dos entradas donde mostraré -de manera básica, como realizar reportes usando NHibernate , PostgreSQL y los controles para Reportes (ReportViewer) que trae cualquier instalación de Visual Studio 2005 -corríjanme si me equivoco 🙂 .
NHibernate es un framework que hace el mapeo de un modelo orientado a objetos a uno relacional.
Al usar NHibernate para el acceso a datos el desarrollador se asegura de que su aplicación es agnóstica en cuanto al motor de base de datos a utilizar en producción, pues NHibernate soporta los más habituales en el mercado: MySQL, PostgreSQL, Oracle, MS SQL Server, etc.
NHibernate tiene demasiadas características como para hablar sobre alguna en especial en este par de entradas, además que ya se ha escrito bastante sobre estos temas. En este apartado, sólo quiero hacer notar un pequeño detalle al momento de trabajar con PostgreSQL como base de datos.
Como se puede apreciar en el código mostrado, la cadena de conexión incluye un parámetro Encoding -sólo sirve para PostgreSQL, donde se especifica la codificación de caracteres que usará nuestra aplicación en la comunicación con el servidor de Base de Datos, si bien es cierto que PostgreSQL intentará hacer automáticamente una conversión entre la codificación definida en el servidor y la del cliente, es recomendable utilizar explícitamente la misma codificación en ambos extremos.
En la siguiente entrada, se tocará específicamente el diseño de reportes usando un ensamblado que contiene nuestro modelo.
Al parecer ayer se liberó una nueva versión de Reflector, una herramienta muy útil que permite explorar, analizar, ver, etc. los ensamblados de .NET.
Entre las novedades que trae esta versión, están:
Para sacarle más provecho a esta herramienta, se pueden agregar plugins de acuerdo a las necesidades que tenga uno.
Existen algunos escenarios donde hay la necesidad de que antes de autorizar la descarga de un archivo desde nuestra aplicación, debamos realizar algún tipo de proceso. En estos casos lo que básicamente hacía es lo siguiente:
Response.Clear();
Response.ContentType = "application/octect-stream";
Response.AddHeader("Content–Disposition", "attachment; filename=foo.xyz");
Response.WriteFile(file);
Response.End();
}