Categories
.NET AJAX ASP.NET CSRF Miniposts Seguridad XSS

Bug XSS en ASP.NET 2.0 y video sobre XSS, CSRF, Ajax Hacking

Para los interesados:

Categories
Expresiones Regulares PHP Seguridad XSS

PHP: Uso adecuado de expresiones regulares

Actualización 17/04/2007: Al parecer el problema descrito ya no es válido en versiones recientes de PHP.

PHP incluye el soporte para expresiones regulares usando una sintáxis compatible con Perl (preg_match, preg_replace, preg_split, etc) y también las expresiones con sintáxis POSIX extendido (ereg, eregi, ereg_replace, eregi_replace, etc).

En esta oportunidad no hablaré de los problemas derivados del abuso o uso inadecuado de las expresiones regulares, sino un problema más específico para aquellos que usan las funciones POSIX-extendido de PHP, sobre el cual existe la siguiente advertencia en el manual de PHP:

Estas expresiones regulares no son seguras con material binario. Las Funciones PCRE lo son.

Bien, veamos un ejemplo en el que por usar este tipo de funciones, una aplicación puede llegar a sufrir problemas de XSS o Inyección de SQL (si es que sólo se usa este tipo de cosas para validar los parámetros):

php:

<?php
// re.php

header('Content-type: text/html; charset=utf-8');

if ( eregi('^[a-z0-9]{4}$', $_GET['key']) ) {
        echo $_GET['key'];
} else {
        echo 'Caracteres no válidos';
}

// ...
?>

La expresión regular definida para validar el parámetro key supuestamente debería considerar sólo aquellos valores constituidos por cuatro letras y/o números, pero debido a que éstas funciones no son seguras con material binario, es posible saltar fácilmente esa validación añadiendo el caracter \0 (fin de cadena en C/C++).

Por ejemplo, para el siguiente valor de key:

php:

<?php

header('Content-type: text/html; charset=utf-8');

$_GET['key'] = 'test' . chr(0) . '<script>alert("Texto no tomado en cuenta")</script>';

if ( eregi('^[a-z0-9]{4}$', $_GET['key']) ) {
        echo $_GET['key'];
} else {
        echo 'Caracteres no válidos';
}

// ...
?>

Se mostrará en el navegador lo siguiente:

code:

test?<script>alert("Texto no tomado en cuenta")</script>

Para conseguir este mismo resultado desde el navegador, sólo basta usar %00 en la URL para representar el caracter \0: key=test%00<foo>.

Si están usando este tipo de funciones, ya están advertidos de los problemas que podrían tener si se les olvida la recomendación del manual de PHP.

Categories
Desarrollo de Software Miniposts Seguridad

Why Security Testing is Hard

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)

Categories
Varios

Off Topic: Cierre temporal

Por el feriado de Semana Santa y unos viajes cortos que realizaré, lamentablemente no podré publicar ni responder comentarios o emails durante un lapso de 2 a 3 semanas. Si bien es cierto que pude haberme ido sin decir nada, prefiero evitar que las personas que comentan o me escriben se sientan mal al no recibir una respuesta 😉

Gracias por tomarse la molestia de seguir este blog, que tengan un buen fin de semana 🙂

Categories
Seguridad Web WordPress

WordPress 2.0.10 y 2.1.3

A estas alturas del día, seguramente ya están al tanto de que el equipo de WordPress anunció la liberación de las versiones 2.0.10 y 2.1.3 de este CMS. Los problemas de seguridad que corrigen estas versiones son (se reportaron unos cuantos problemas más pero no tienen un ticket correspondiente para ponerlo):

Lo que me preocupa de estas nuevas versiones, es que todavía siguen incluyendo la versión vulnerable a XSS del plugin akismet.