En este post hablaremos sobre un tema que interesa a cualquiera que desarrolle o trabaje con bases de datos en una aplicación web, los ataques con inyección SQL.

¿Que es un ataque con inyección SQL (SQL injection)?

En principio los ataques SQL injection son combinaciones de técnicas para conocer datos sobre la configuración de un servidor web y de su base de datos, de forma que, de manera mas o menos directa, se pueda conseguir acceso a la misma, para usarla en beneficio del atacante, bien borrando datos, copiandolos y vendiendolos posteriormente o manipulandolos para conseguir algún objetivo, como puede ser la propagación de un virus desde esa misma página.

Los ataques consisten en la adición de sentencias SQL especiales que, ejecutadas en el servidor, le den al atacante información tecnica sobre la base de datos y posteriormente acceso de algún tipo.

¿Son evitables todos los ataques  SQL Injection?

Un servidor web publico siempre podrá ser accedido por cualquier usuario que acceda a la página o conecte a través de un programa informático, con lo que siempre estará expuesto. Incluso en servidores internos de redes empresariales podemos tener problemas con cualquier usuario, por eso son importantes el uso de todas las técnicas que vamos a ver en este post.

Es probable que nos dejemos alguna ya que vamos a hablar sobre servidores IIS y SQL Server, podeis dejar vuestras aportaciones en los comentarios si teneis alguna para otras bases de datos o servidor web.

¿Cualquier base de datos es susceptible de un ataque SQL Injection?

En principio las mas usadas en aplicaciones web como Mysql, Oracle, SQL Server y Access (increible que todavia se use para webs) son susceptibles de ser atacadas para conseguir el acceso, cada una con sus diferentes sintaxis, pero en general las técnicas son similares.

Técnicas de defensa ante ataques SQL Injection

1. Páginas de error personalizadas

No hay que ponerselo fácil a los atacantes de nuestras webs.

Al principio de un ataque se usan diferentes sentencias para que la página proporcione errores de sintaxis al intentar ejecutarlas y de esa manera conocer que versión de base de datos usa nuestra aplicación, para ser más precisos en las siguientes oleadas. Si queremos ver los errores cuando estamos desarrollando, pero queremos que sean invisibles al resto de usuarios, podemos generar una página de error personalizada que solo muestre los detalles a una determinada IP o si estas logado en un panel de control de la propia web, mientras que el resto de usuarios veran un bonito mensaje creado por ti sin detalles sobre el error.

2. Uso de procedimientos almacenados.

Una de nuestras experiencias contra ataques de inyeccion SQL fue en un cliente que ya tenia la aplicacion web funcionando y nos llamo para realizar un proyecto de SEO. La web tenia distintas funcionalidades, aunque basicamente era un buscador de textos cientificos. Nuestra sorpresa llego cuando al revisar el código en ASP muchas llamadas a la base de datos se realizaban de manera directa haciendo “select ” con parametros querystring (GET) en vez de usar procedimientos almacenados contra SQL Server.

¿Que implica ejecutar selects con parametros?

Los select con parametros son la puerta de entrada a los ataques SQL injection ya que salvo excepciones que ya veremos mas abajo, su uso deja abierta la puerta para que poniendo un simple punto y coma “;” todo lo que venga detras en el querystring sea ejecutado en la base de datos.

/pagina.asp?id=1;update users set name=’codigo javascript con enlace a un virus’

si en el script pagina.asp usamos una select abierta podemos hacer que la base de datos ejecute la sentencia detrás del ; en este caso cambiando el valor de un campo en toda la tabla de usuarios por un codigo javascript que nos lleve a una pagina con virus, que fue lo que ocurrió en este cliente. Todos los que trabajamos con bases de datos usamos nombres muy parecidos en muchas aplicaciones, por comodidad y sencillez de mantenimiento, con lo que determinadas tablas suelen tender a tener el mismo nombre en muchas webs haciendo mas fácil un ataque dirigido en este sentido.

¿Cual es la ventaja de los procedimientos almacenados?

En el caso de los procedimientos los parametros entran por separado y ademas “tipados”, esto significa que si el servidor espera un valor numerico (int) al recibir el “update …” fallará y no se ejecutará. Y en el caso de varchars podria incorporar el texto en un update, pero nunca se ejecutaría directamente minimizando el riesgo.

¿Tiene alguna debilidad un procedimiento almacenado?

Si, en general en el momento que un procedimiento almacenado se hace “dinámico”, es decir, que no ejecuta directamente siempre la misma operación, sino que recibe en un parámetro la sentencia sql y la ejecuta de manera interna. En este caso el problema es el mismo que en las selects abiertas.

Siempre hay que usar procedimientos parametrizados (ejemplo en ASP):

set cmd=Server.CreateObject(“ADODB.Command”)
Set Cmd.ActiveConnection = wConn
Cmd.CommandType = adCmdStoredProc
Set rs= Server.CreateObject(“ADODB.Recordset”)
Cmd.CommandText = “PROCEDIMIENTO_ALMACENADO”
Cmd.Parameters(“@ID”) = request.QueryString(“id”)
set RS=Cmd.Execute()

3. Filtros en la configuración de la web.

En el caso de IIS7 podemos generar un filtro bastante efectivo en toda la página web haciendo uso del archivo web.config, colocando unas cuantas lineas que protejan los parametros hacia ASP y ASP.NET.

Debajo de <system.webServer> colocaremos este código que dejamos, esto filtra en las URL todas las palabras clave listadas, que , salvo excepciones, son usadas solo en entornos de base de datos. Si el servidor IIS encuentra una coincidencia, muestra el error 404 de no encontrado cuando el atacante intente acceder a la página con esos parametros o URL.

<security>
<requestFiltering>
<filteringRules>
<filteringRule name=”SQLInjection2″ scanQueryString=”true”>
<appliesTo>
<add fileExtension=”.asp” />
<add fileExtension=”.aspx” />
</appliesTo>
<denyStrings>
<add string=”–” />
<add string=”/*” />
<add string=”alter” />
<add string=”begin” />
<add string=”create” />
<add string=”cursor” />
<add string=”delete” />
<add string=”drop” />
<add string=”fetch” />
<add string=”insert” />
<add string=”kill” />
<add string=”open” />
<add string=”select” />
<add string=”sys” />
<add string=”table” />
<add string=”union” />
<add string=”update” />
<add string=”top” />
<add string=”iif” />
<add string=”from” />
<add string=” or ” />
<add string=” in ” />
<add string=”chr” />
<add string=”asc(” />
<add string=”curdir” />
<add string=”len(” />
<add string=”ascii” />
<add string=”substring” />
<add string=”length” />
<add string=”@version” />
<add string=”exists” />
</denyStrings>
</filteringRule>
</filteringRules>
</requestFiltering>
</security>

el problema es que puede haber excepciones en las que haya palabras clave que podamos usar en alguna URL, lo que haria que tuviesemos que quitarlas de este filtro inicial.

4. Función de limpieza

Puede no ser técnicamente muy acertada, pero sin duda es muy efectiva, ya que nos permite dejar pasar en primera instancia determinadas palabras y luego filtrarlas en parametros según nuestra conveniencia, en ASP seria tal que así:
function clear_param(texto)

dim texto_final
texto_final=replace(texto, “SELECT”, “”)
texto_final=replace(texto_final, “‘”, “”)
texto_final=replace(texto_final, “UPDATE”, “”)
texto_final=replace(texto_final, “DELETE”, “”)
texto_final=replace(texto_final, “DROP”, “”)
texto_final=replace(texto_final, “UNION “, “”)
texto_final=replace(texto_final, “%”, “&#37;”)
texto_final=replace(texto_final, “%00″, “”)
texto_final=replace(texto_final, ” TOP “, “”)
texto_final=replace(texto_final, ” GROUP “, “”)
texto_final=replace(texto_final, “=”, “”)
‘texto_final=replace(texto_final, “>”, “&#62;”)
‘texto_final=replace(texto_final, “<”, “&#60;”)
texto_final=replace(texto_final, “IIF”, “”)
texto_final=replace(texto_final, “FROM”, “”)
texto_final=replace(texto_final, ” OR “, “”)
texto_final=replace(texto_final, ” AND “, “”)
texto_final=replace(texto_final, ” IN “, “”)
texto_final=replace(texto_final, ” CHR “, “”)
texto_final=replace(texto_final, ” ASC(“, “”)
texto_final=replace(texto_final, ” CurDir “, “”)
texto_final=replace(texto_final, “LEN(“, “”)
texto_final=replace(texto_final, “SHELL”, “”)
texto_final=replace(texto_final, “ASCII”, “”)
texto_final=replace(texto_final, “SUBSTRING”, “”)
texto_final=replace(texto_final, “LENGTH”, “”)
texto_final=replace(texto_final, “version”, “”)
texto_final=replace(texto_final, “exists”, “”)
clear_param=texto_final

End function

una función de este tipo servirá para limpiar un querystring en el caso de que por alguna razón debamos usarlo directamente sobre una select, para complementar el filtro en web.config:

clear_param(request.QueryString(“id”))

5. Bloqueo de IP´s

Como medio de disuasión es interesante si el atacante no es demasiado habil ya que burlar un bloque de Ip es relativamente sencillo con programas para navegación anónima, pero tambien sirve como bandera del ” te hemos visto y estamos preparados” lo que puede hacer que ese hacker se interese por otras webs más faciles que la nuestra. En la página de errores personalizados podemos tener una función que guarde un log con el error y la IP que lo ha producido, si además guardamos los parametros querystring que han producido el fallo podemos identificar los intentos de hacking a la web y la IP del atacante.

Todas estas técnicas de prevención de ataques SQL injection son aplicables en otros lenguajes, servidores web y bases de datos, usando en cada caso su propia sintaxis.

Si te ha servido este post o se nos olvida algo, por favor, deja un comentario y cuéntanos tu experiencia.