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.
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.
Existen ocasiones en que para corregir determinados problemas es necesario deshabilitar ciertas partes de una página ASP.NET, esto en algunos casos puede conseguirse usando sólo los comentarios HTML, pero para otros casos en que cierta funcionalidad no está implementada o los nombres de los controles entran en conflicto, se produce un error porque la página sigue su flujo de ejecución.
En el siguiente ejemplo se produce un error porque el identificador texto se repite:
<!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>
</head>
<body>
<form id="form1" runat="server">
<div>
</asp:Label>-->
</div>
</form>
</body>
</html>
Para solucionar este problema, se debe usar comentarios del lado del servidor (<%-- comentario --%>).
<!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>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:TextBox ID="texto" runat="server"></asp:TextBox>
</div>
</form>
</body>
</html>
Al usar este tipo de comentarios, el texto contenido dentro de <%-- --%> no será enviado al navegador.
Referencia: Tip/Trick: Using Server Side Comments with ASP.NET 2.0
Hay ocasiones en que la forma como interpreta HTML un navegador puede producir algunos problemas de seguridad, esto normalmente se debe a descuidos de un programador que asume cierta funcionalidad.
Veamos el siguiente ejemplo — basado en una aplicación del mundo real ™ — que muestra un caso de estos:
if (empty($_GET['el'])) {
die;
}
/* Función genérica que sirve para eliminar ciertos caracteres */
function clean_input_string($string) {
return preg_replace('/[ <>\'"\r\n\t\\()]/', '', stripslashes($string));
}
?>
<!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="en">
<head>
<title>Demo</title>
<script type="text/javascript">
//<![CDATA[
function ponerFoco(id){
var elemento = document.getElementById(id);
if (!elemento) return;
elemento.focus();
}
//]]>
</script>
</head>
<form method="post" action="foo.php">
<input type="text" name="usuario" id="usuario" />
<input type="text" name="contrasena" id="contrasena" />
<input type="submit" name="postback" value="Entrar »" />
</form>
</body>
</html>
Como se puede observar, el código lo único que hace es intentar poner el foco en el elemento que se especifique en el parámetro el, éste valor antes es filtrado (elimina los caracteres espacio, <, >, ', ", \r, \n, \t, (, ) y \ ) por la función de propósito general clean_input_string — la aplicación de donde se tomó el código hace uso de esa función en varias partes.
Puesto que se eliminan los caracteres \, (, ) y ', en circunstancias normales no debería ser posible ejecutar javascript en el ejemplo mostrado; si el contiene ');alert(document.cookie)// entonces lo que llega al navegador es <body onload="ponerFoco(';alertdocument.cookie//')">, valor completamente inofensivo para nuestros propósitos.
Haciendo unas pruebas con un valor parecido al anterior, pero esta vez usando entidades HTML en lugar de los caracteres que son eliminados por la función clean_input_string, se consiguen resultados interesantes. Por ejemplo, para el = ');alert(document.cookie)//, el HTML generado es:
A simple vista, parece igual de inofensivo que el anterior caso, sin embargo si esa página carga en Firefox o Internet Explorer (no probé con otros navegadores), además de ejecutarse la función ponerFoco, se mostrará un mensaje mostrando las cookies almacenadas.
Este tipo de problemas se pueden solucionar evitando en lo posible enviar directamente los valores que dependen del cliente, definiendo filtros más específicos (formatos de identificadores válidos) o separando la generación de javascript y HTML en documentos distintos.