Probas para vulnerabilidades de inyección de SQL

Os ataques de inyección de SQL supoñen enormes riscos para as aplicacións web que dependen dun backend de base de datos para xerar contido dinámico. Neste tipo de ataque, os hackers manipulan unha aplicación web co obxectivo de inxectar os seus propios comandos SQL aos emitidos pola base de datos. Por exemplo, consulte o artigo SQL Injection Attacks on Databases. Neste artigo, botamos unha ollada a varias formas de probar as aplicacións web para determinar se son vulnerables aos ataques de inyección de SQL.

Escaneo automático de inxección de SQL

Unha posibilidade é usar un escáner de vulnerabilidade de aplicacións web automatizado, como WebInspect de HP, AppScan de IBM ou Hailstorm de Cenzic. Todas estas ferramentas ofrecen formas fáciles e automatizadas de analizar as aplicacións web para posibles vulnerabilidades de inyección de SQL. Non obstante, son moi caros, correndo ata 25.000 dólares por asento.

Probas de inxección de SQL manual

¿Que facer un desenvolvedor de aplicacións malo? Realmente pode executar algunhas probas básicas para avaliar as súas aplicacións web para vulnerabilidades de inxección de SQL usando nada máis que un navegador web. En primeiro lugar, unha palabra de precaución: as probas que describo só buscan erros básicos de inyección de SQL. Non detectarán técnicas avanzadas e son algo tediosas de usar. Se pode permitilo, vaia cun escáner automatizado. Non obstante, se non pode manipular ese prezo, as probas manuais son un gran primeiro paso.

A forma máis sinxela de evaluar se unha aplicación é vulnerable é experimentar con ataques de inxección inofensivos que en realidade non danan a súa base de datos se o tiveron éxito pero proporcionaran probas de que precisa corrixir un problema. Por exemplo, supoña que tiña unha aplicación web sinxela que busca un individuo nunha base de datos e proporciona información de contacto como resultado. Esa páxina pode empregar o seguinte formato de URL:

http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike

Podemos supoñer que esta páxina realiza unha busca de base de datos, usando unha consulta similar á seguinte:

SELECCIONAR un teléfono DO directorio DONDE lastname = 'chapple' e firstname = 'mike'

Imos experimentar un pouco con isto. Coa nosa suposición anterior, podemos facer un cambio sinxelo á URL que proba para os ataques de inxección de SQL:

http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike'+AND+(select+count(*)+de+fake)+%3e0+OR+'1'%3d'1

Se a aplicación web non foi debidamente protexida contra a inxección de SQL, simplemente conecta este nome falso á instrución SQL que executa contra a base de datos, obtendo:

SELECCIONAR un teléfono DO directorio DONDE lastname = 'chapple' e firstname = 'mike' E (seleccione reconto (*) de falso)> 0 Ou '1' = '1'

Notarás que a sintaxe anterior é un pouco diferente á que aparece no URL orixinal. Tomé a liberdade de converter a variable URL codificada para os seus equivalentes ASCII para facer máis doado seguir o exemplo. Por exemplo,% 3d é a codificación URL para o carácter '='. Engadín tamén algúns saltos de liña para fins similares.

Valoración dos resultados

A proba vén cando intenta cargar a páxina web coa URL enumerada anteriormente. Se a aplicación web está ben comportada, eliminará as comiñas simples da entrada antes de pasar a consulta á base de datos. Isto simplemente dará lugar a unha busca estraña por alguén cun nome que inclúa unha morea de SQL. Verás unha mensaxe de erro da aplicación similar á seguinte:

Erro: Non se atopou un usuario co nome mike + E + (seleccione + contar (*) + de + falso) +% 3e0 + Ou + 1% 3d1 Chapple!

Doutra banda, se a aplicación é vulnerábel á inxección de SQL, pasará a declaración directamente á base de datos, obtendo unha das dúas posibilidades. En primeiro lugar, se o seu servidor ten activado mensaxes de erro detalladas (que non debería!), Verá algo como isto:

Proveedor de OLE DB de Microsoft para ODBC Controladores de erro '80040e37' [Microsoft] [ODBC SQL Server Driver] [SQL Server] Nome de obxecto non válido 'falso'. /directorio.asp, liña 13

Doutra banda, se o seu servidor web non mostra mensaxes de erro detalladas, terá un erro máis xenérico, como:

Erro do servidor interno O servidor atopou un erro interno ou configuración incorrecta e non puido completar a súa solicitude. Póñase en contacto co administrador do servidor para informar sobre o momento en que ocorreu o erro e sobre o que puido causar que provocase o erro. Pode estar dispoñible máis información sobre este erro no rexistro de erros do servidor.

Se recibe un dos dous erros arriba, a súa aplicación é vulnerable ao ataque de inxección de SQL. Algúns pasos que pode tomar para protexer as súas aplicacións contra ataques de inyección de SQL inclúen:

• Implementar comprobación de parámetros en todas as aplicacións. Por exemplo, se está a pedir a alguén que ingrese un número de cliente, asegúrese de que a entrada é numérica antes de executar a consulta .
• Limite os permisos da conta que executa consultas SQL . Existe a regra de menos privilexio. Se a conta usada para executar a consulta non ten permiso para executala, non terá éxito.
• Use procedementos almacenados (ou técnicas similares) para evitar que os usuarios interactúen directamente co código SQL.