¿Cómo proteger SQL Server y una Aplicación Web (o de otro tipo) de ataques SQL Injection?

Ahora que ya comprendemos qué es SQL Injection y cuáles son las principales formas en que nos pueden realizar un ataque de SQL Injection, estamos en situación de definir diferentes alternativas (que no tienen porque ser únicas ni exclusivas) para protegerse de ataques SQL Injection. Recordemos que los daños producidos por un Ataque SQL Injection pueden ser plurales: daños técnicos (ej: caídas del servicio por ataques de Denegación de Servicio a través de SQL Injection), daños de imagen (ej: pérdida de confianza por parte de los Usuarios con el correspondiente impacto económico), daños económicos (ej: costes de reparación de daños físicos, como pueda ser borrados o modificaciones de datos), etc.

Antes de empezar la enumeración y descripción de las diferentes alternativas existentes para protegerse de SQL Injection, es importante introducir el concepto de cadenas peligrosas ¿A qué podemos denominar una cadena peligrosa en términos de SQL Injection? Pues a cualquier cadena que potencialmente pueda alterar el comportamiento de la consulta SQL que deseamos ejecutar, como es el caso (entre otros) de:

• Comentarios.
• Delimitadores de Cadena (ej: comillas simples y/o dobles).
• Delimitadores de línea (ej: punto y coma).
• Palabras reservadas como DELETE, UPDATE, ALTER, DROP, etc.
• Llamadas a Procedimientos Almacenados del Sistema.

Y ahora, si que estamos en situación de estudiar las diferentes alternativas que tenemos para protegernos de ataques SQL Injection, como resultado de las pruebas realizadas en el Laboratorio de GuilleSQL:

• Utilizar Procedimientos Almacenados (o en su defecto Consultas SQL) de forma parametrizada y evitar la utilización de consultas SQL al vuelo y de SQL Dinámico. Esta es la opción más recomendable, y requiere en consecuencia utilizar Procedimientos Almacenados para el acceso a la base de datos, los cuales deben ser invocados de forma parametrizada (llamar a Procedimientos Almacenados desde consultas SQL al vuelo o desde código SQL Dinámico, sigue siendo una operación de riesgo para SQL Injection). También es posible utilizar parámetros con consultas SQL construidas dinámicamente. La utilización de Parámetros, permite además la realización implícita de comprobaciones de tipo de dato y de longitud.
  
  
• Validar los datos introducidos por el Usuario (QueryStrings, Campos de Formularios, valores almacenados en el Registro de Windows o en ficheros de configuración, etc.). Validar el tipo de dato, longitud, formato y rango, y además, comprobar la existencia de cadenas peligrosas en las entradas de la aplicación (ej: cajas de texto, QueryStrings, valores del Registro de Windows, etc.). En caso de detectar cadenas peligrosas en las entradas de la aplicación, mostrar un mensaje informativo, y no realizar ningún acceso a base de datos. Es una buena práctica identificar una lista con los caracteres de entrada permitidos, y utilizar Expresiones Regulares (Regular Expressions) para validar la entrada.
  
  En el caso de Aplicaciones Web (ej: Aplicaciones ASP y Aplicaciones ASP.Net), utilizar siempre validaciones de servidor (server-side validations), empleando validaciones de cliente (client-side validations) para minimizar las recargas de página (round trips) y mejorar la experiencia del Usuario.
  
  En el caso de Aplicaciones ASP.Net, pueden utilizarse controles como el RegularExpressionValidator y el RangeValidator, así como la clase Regex para la utilización de Expresiones Regulares por código (ej: en el evento OnClick de un botón de servidor, como parte de una validación personalizada de un control CustomValidator, etc.). Hemos evaluado la utilización de estos Controles de ASP.Net en el Laboratorio de GuilleSQL, y el resultado ha sido satisfactorio (evidentemente).
  
  
• Sustituir o eliminar cadenas peligrosas al construir consultas SQL al vuelo (o SQL Dinámico). Antes de construir una consulta SQL al vuelo, sustituir o eliminar las cadenas peligrosas que puedan encontrarse en las entradas de la aplicación, y seguidamente construir la correspondiente consulta SQL, ejecutándola contra la base de datos. Como vimos antes, la cantidad de cadenas peligrosas existentes es muy alta, pero el hecho de al menos eliminar los delimitadores de cadena (las comillas simples o comillas dobles, dependiendo del caso) y también eliminar los delimitadores de comentarios, resulta relativamente sencillo y evita bastantes riesgos.
  
  
• Minimizar los permisos concedidos al usuario utilizado para acceder a base de datos. Es decir, en la medida de lo posible evitar que el usuario utilizado para acceder a SQL Server sea miembro de sysadmin, evitar conceder permisos directos sobre las tablas (conceder permisos sólo sobre los Procedimientos Almacenados que se necesiten utilizar), etc. También lo hemos probado en el Laboratorio de GuilleSQL, evidentemente con éxito.
  
  
• Evitar revelar información de errores de base de datos (correcta Gestión de Errores), ya que dicha información podría ser utilizada por el atacante (Hacker) para averiguar o revelar parcial o totalmente el esquema (nombres de campos, nombres de tablas, etc.) de la base de datos fruto de su ataque SQL Injection, lo cual nos hace aún más vulnerables.
  
  
• Utilizar dispositivos cortafuegos (Firewall) que trabajen al nivel OSI de Aplicación. Algunos fabricantes de cortafuegos (Firewall) introducen en sus productos (sean firewalls por hardware o por software) funciones de seguridad a nivel de Aplicación, de tal modo que son capaces de recolectar y reconstruir paquetes y tramas de red para inspeccionar su contenido en busca de intentos de ataques de naturalezas dispares, incluyendo SQL Injection. Por desgracia no hemos podido evaluar esta alternativa en el Laboratorio de GuilleSQL, pero quería introducirlo aquí para quién le pueda resultar de interés, pueda plantearse su evaluación (para muchos, el hecho de poder adquirir un dispositivo hardware que una vez enchufado puedan olvidarse de él, es una comodidad por la que están dispuestos a pagar dinero).
  
  

Es probable que alguien pueda conocer otras alternativas adicionales para proteger una aplicación de ataques SQL Injection, pero lo que si es seguro, es que con las alternativas anteriores, es posible dejar suficientemente securizada una aplicación de base de datos SQL Server frente a posibles ataques SQL Injection.