Cómo es el SQL Injection en SQL Server

La inyeccion de código SQL (SQL Injection) es una vulnerabilidad de las más conocidas en el mundo de la Seguridad de la Información. Veamos entonces cómo es el SQL Injection en SQL Server.

El primer problema de la Inyección de SQL se inicia cuando se tiene una referencia errónea de su concepto.

He visto en diferentes lugares la concepción de que dado que «SQL Injection» expresa «SQL», se asume que la vulnerabilidad proviene del servidor de Base de Datos como tal. Así es. En diferentes oportunidades me han llamado pidiendo hacer una revisión de configuración del servidor y encontrar qué parámetro es el que causa esta vulnerabilidad.

SQL Injection no es un parámetro

Ojalá fuera tan fácil como decir «solo debes colocar en TRUE la configuración X» y así estarás libre de SQL Injection en SQL Server. Sin embargo, el análisis requiere ser mucho más exhaustivo.

Existen sí configuraciones en SQL Server que pueden causar mayor impacto en la explotación de la vulnerabilidad, pero no son el origen de la misma.

Como lo dice su nombre, esta vulnerabilidad es explotada cuando un atacante inyecta un fragmento de código de manera forzada. Usualmente esto con el propósito de causar una reacción «normal» del motor, o para causar un error que pueda dar información importante al atacante.

¿Cómo evitamos inyecciones en SQL Server?

Como en cualquier motor de Base de Datos. Lo más importante es validar en qué lugares un atacante puede intentar inyectar código.

Uno de los escenarios más comunes es el programa de login. Un ejemplo perfecto para entender qué debemos evitar.

/*   Pseudocode   */
var username
var password

var query = 'SELECT * FROM dbo.Users WHERE user = ' + username + ' AND pass = ' + password

EXEC (query)

Observa que el código siempre tomará los valores provenientes de variables para la ejecución. Es justo aquí donde puede darse la inyección; en estos valores de entrada.

Entonces aquí está el foco principal. Es imprescindible que tengamos la certeza de cuáles valores pueden ser parte de estos parámetros y así restringir la introducción de texto. Por ejemplo piensa en:

• El tamaño de valores que pueden escribirse
• Si se aceptan caracteres numéricos o alfanuméricos
• Si puede escribirse caracteres especiales
• La necesidad de validar el contenido antes de enviarlo a los programas

Sigue estos consejos

1. Siempre valida los parámetros de entrada antes de ejecutarlos
2. No permitas tamaños de textos mayores al tamaño de columna con la que se realiza la comparación
3. Si pensaste que no puedes cumplir el punto anterior porque trabajas con tipos de datos de tamaño MAX, lo primero que debes hacer es limitar estos tamaños
4. Evita caracteres que puedan llevar a alterar el comportamiento de una ejecución. Por ejemplo comillas ( ‘ ), guiones ( – ), comas ( ; )

¿Todavía no está claro cómo se materializa la explotación de la vulnerabilidad? Suscríbete al boletín semanal que periodicamente mostramos ejemplos prácticos en las webinars que hacemos.