Protección contra inyección SQL con URLScan 3.0

Últimamente muchos hemos sufrido algún tipo de ataque si nos dedicamos a la creación y mantenimiento de aplicaciones web. No importa la importancia o la visibilidad de estas aplicaciones, con que estén publicadas en Internet son un blanco susceptible de ser atacado por la multitud de bots que pululan por la red.

Lo ideal, como siempre, es que nuestras aplicaciones sean a prueba de bombas de modo que filtren los parámetros que recogen correctamente y no hagan caso de los datos que no tienen sentido, pero esto no siempre es posible ya que hay aplicaciones por el mundo de aquella época en la que los ataques no eran el pan de cada día y nadie se preocupaba por ellos.

Para esto, una buena opción es la protección de los ataques usando algún tipo de firewall o en su defecto algún tipo de filtro de queries, mucho mejor que protecciones a nivel de aplicación. Si trabajamos con IIS6, hasta hace poco había pocas opciones para protegernos ya que el clásico URLScan no permitía manejar Querystrings completas. Una opción gratuita es el IIS 6 SQL Injection ISAPI Wildcard, que filtra de forma básica todo lo que parece sospechoso y desde hace poco también está la opción de usar URLScan 3.0 en su versión beta, que permite añadir filtros a las Querystrings para proteger las páginas devolviendo un error 404 si se incumplen las condiciones.

Uno de los motivos del lanzamiento de esta herramienta ha sido el gran aumento de los ataques SQL en los últimos meses, como queda reflejado en el Security Advisory 954462, donde recomiendan usar este software así como otra interesante herramienta como es el Microsoft Source Code Analyzer for SQL Injection, del que hablaré en otro momento.

URLScan es muy sencillo de instalar, descargamos el instalador y ejecutamos y nos informará de dónde se ha instalado. Después hay que editar urlscan.ini para ajustarlo a nuestras necesidades (las configuraciones de la version 2.x son compatibles) y un buen punto de partida es la página de Common UrlScan Scenarios, donde explican configuraciones básicas para protección contra verbos extraños y contra ataques de inyección SQL.

Los he estado probando y recomiendo cierta prudencia ya que nos podemos encontrar con algunas sorpresas ya que si un parámetro se llama como una de las palabas prohibidas o su valor contiene una de las palabras tendremos un bonito error 404, por lo que convendría monitorizar los logs de URLScan durante los primeros días para evitar sorpresas. En mi caso he tenido que desactivar el filtro de una sola @ (aparecen mails en parámetros) y INSERT y SELECT porque aparece en el nombre de algunos parámetros.

Como opción interesante es que también se filtran los parámetros de las cookies, que muchas veces no se protegen adecuadamente y también se puede hacer inyección editando la información que contienen.

En resumen, URLScan 3.0 añade filtrado por Querystring que tanto había sido demandado y lo convierte en una herramienta potente a la hora de proteger un servidor con SQL Server y IIS 5, 6 o 7.

¡Activa ya la compresión gzip en tu servidor!

Llevo tiempo queriendo escribir sobre este tema pero quería acabar de escribir un pequeño script en Python para si un servidor dado tiene o no activada la compresión.

La importancia de este mecanismo es que sirve para reducir significativamente el ancho de banda utilizado con un coste de CPU bastante bajo. Además, gzip es un mecanismo ampliamente soportado por todos los navegadores (publicado en la RFC 1951) desde hace años y por supuesto por los servidores web. Se basa en el algorimo deflate y permite compresión de un archivo cada vez (es decir, no es como el zip o el rar que pueden almacenar varios achivos y carpetas) y en entornos unix es ampliamiente usado en los archivos .tar.gz (tar almacena la estructura sin comprmir y gzip comprime el resultado).

Evidentemente, no hace milagros pero es muy efectivo para la compresión de HTML (.htm, .html), Javascript (.js), CSS (.css) y por supuesto archivos dinámicos resultado de todo tipo de entornos (.aspx, .asp, .php, .py…). Comprimir las imágenes por ejemplo no sirve para nada salvo para perder el tiempo y desperdiciar CPU (a lo mejor .bmp si que los comprime… pero espero que nadie esté sirviendo estos archivos en su servidor).

En Apache suele estar activada por defecto en la mayoría de instalaciones (a través de mod_gzip), aunque puede que haya que activarla o configurarla manualmente si no se ajusta al las necesidades.

En IIS, el proceso es un tanto más laborioso, aunque con la versión 6 (y la 7, naturalmente) viene de serie todo lo necesario para activar esta compresión (aun así hay módulo ISAPI de terceros). Una buena explicación en español y otra en inglés no vendrán nada mal. Lo único delicado es no poner nada mal en la metabase porque en ese caso no hará ni caso.

Luego, hay unos cuantos sitios para comprobar si todo ha funcionado bien, pero uno de los que más me ha gustado es test mod_gzip/gzip de WhatsMyIP.org. O también se puede adaptar mi pobre script:

import urllib2;
import httplib;
import StringIO;
import gzip;
import zlib;

URL = "http://codelog.climens.net";

httplib.HTTPConnection.debuglevel = 1

req = urllib2.Request(URL);
req.add_header('Accept-encoding', 'gzip');

opn = urllib2.build_opener();
f = opn.open(req);

encoding = f.headers.get('Content-encoding');

gzipped = 0;

if encoding=='gzip':
    cdata = f.read();
    cdatasize = float(len(cdata));

    cstream = StringIO.StringIO(cdata);

    data = gzip.GzipFile(fileobj=cstream).read();
    datasize = float(len(data));

    gzipped = 1;
else:
    data = f.read();
    datasize = float(len(data));

    gzipped = 0;

if gzipped==1:
    print 'Gzip compression: Enabled';
    print 'Compressed size: %d bytes' % cdatasize;
    print 'Full size: %d bytes' % datasize;

    print 'Ratio: %0.2f:1 (%0.1f%%)' % (float(datasize/cdatasize), float(100 - cdatasize*100/datasize));

else:
    print 'Gzip compression: Disabled';
    print 'Content size: %d bytes' % datasize;

Feliz compresión.