Protección de QueryString en ASP clásico contra inyección SQL

Hace un mes comenté que nos habían atacado por SQL, pero la cosa ha ido a más durante este tiempo y los ataques han proliferado y han ido variando ligeramente con el tiempo siendo en algunos casos menos destructivos pero más efectivos.
El problema son las aplicaciones legadas, en mi caso hechas en ASP clásico, en las que no hay ni tiempo ni ganas de revisar y cambiar todo lo que habría que cambiar para proteger adecuadamente estas aplicaciones (algunas datan del 2000).
A esto se une la propia inutilidad del IIS6 (por no hablar del IIS5 que también anda por ahí) para filtrar adecuadamente las QueryStrings contra ciertos patrones.
Para el ataque en cuestión, una primera aproximación es protección a través de TSQL, denegando el permiso de acceso a sysobjects y syscolumns al usuario que accede a la base de datos desde la aplicación ASP:

USE [database]
DENY SELECT ON ..sysobjects TO [login]
DENY SELECT ON ..syscolumns TO [login]

Esto puede ser suficiente para la oleada de ataques actuales pero no siempre es posible cambiar esos permisos ya que no se puede acceder con una cuenta con privilegios a la base de datos.
Entonces queda la protección por código, a través de algún archivo básico que se incluya en todas las páginas (si la aplicación es más o menos seria seguro que tiene alguno de estos). Casi seguro que al código hay acceso de algún modo para poder realizar actualizaciones. Si ni SQL, ni código, ni nada pues entonces solo hay que esperar que esté todo bien protegido de serie.
La protección por ASP es bastante simple y limitada pero sirve para el caso que nos ocupa como solución de emergencia sin tener que cambiar demasiadas cosas. Se basa en recoger los parámetros de la URL y buscar una serie de cadenas que seguramente aparecen en un ataque y improbablemente en una página bien formada, pero allá cada uno:

const ERR_BAD_QUERY = 1 ' El valor que se desee realmente

if request.servervariables("QUERY_STRING") <> "" then
    dim testQueryString, vDangerousStrings, dangerousString

    testQueryString = request.servervariables("QUERY_STRING")

    vDangerousStrings = split("CAST(,DECLARE%20,VARCHAR(,EXEC(",",")

    for each dangerousString in vDangerousStrings
        if instr(1, testQueryString, dangerousString, vbTextCompare) <> 0 then
            err.raise vbObjectError + ERR_BAD_QUERY, "AppName", "Los parámetros ("&dangerousString&") de la URL no son correctos: " & testQueryString
        end if
    next
end if

Con esto, cuando intenten atacar, fallará estrepitosamente y si están adecuadamente configurados los errores personalizados en el IIS para el error HTTP 500 aparecerá una bonita página al atacante. En mi caso, cada error manda un mail a una cuenta de monitorización.
Espero que a alguien le haya servido, aunque repito, no es una solución demasiado elegante ni infalibre. Además, no protege los parámetros pasados por POST, aunque de momento los ataques no están funcionando de ese modo, podrían hacerlo en algún momento.
Para implementar una solución más completa, estos consejos para la detección XSS y SQL Injection pueden ser bastante útiles.

Actualización 06/06/2008:
Después de hacer algunas pruebas de rendimiento, usar expresiones regulares no es realmente más lento que usar instr, así que allá va una versión mejorada:

const ERR_BAD_QUERY = 1 ' El valor que se desee realmente

if request.servervariables("QUERY_STRING") <> "" then
    dim re, testQueryString, vDangerousStrings, dangerousString

    set re = new regexp
    re.ignorecase = true

    testQueryString = request.servervariables("QUERY_STRING")

    vDangerousStrings = split("CAST(%20)*(,DECLARE(%20)+,VARCHAR(%20)*(,EXEC(%20)*(",",")

    for each dangerousString in vDangerousStrings
        re.pattern = dangerousString

        if re.test(testQueryString) then
            set vMatches = re.execute(testQueryString)
            err.raise vbObjectError + ERR_BAD_QUERY, "AppName", "Los parámetros ("&vMatches(0)&") de la URL no son correctos: " & testQueryString
        end if
    next

    set re = nothing
end if

Con esto se flexibilizan las cadenas a buscar de modo que se adapten a variaciones del ataque que añadan espacios entre los comandos TSQL, que seguirían siendo perfectamente válidos para el intérprete de SQL Server.

Si te ha gustado esta entrada, por favor deja un comentario o suscríbete al RSS para que puedas recibir todas las novedades en tu lector de feeds favorito.
This entry was posted in Seguridad and tagged , , , . Bookmark the permalink.

2 Responses to "Protección de QueryString en ASP clásico contra inyección SQL"

Leave a reply