Inyección SQL: Medidas preventivas

Siempre y cuando el código SQL inyectado sea sintácticamente correcto, no será sencillo detectar alteraciones dañinas en tiempo de depuración. Por ello cobra especial importancia validar todos los datos especificados por el usuario mediante comprobaciones de tipo, longitud, formato e intervalo. A tal fin, es recomendable tener en cuenta las siguientes precauciones:

- No hacer suposiciones sobre el tamaño, tipo o contenido de los datos que recibirá la aplicación.

- Comprobar el tamaño y el tipo de los datos especificados, haciendo uso de unos límites adecuados. Esto puede impedir que se produzcan saturaciones deliberadas del buffer que provoquen DOS.

- Cuando se trabaje con documentos XML, validar todos los datos con respecto a su esquema a medida que se van indicando.

- No crear nunca instrucciones Transact-SQL directamente a partir de datos que indique el usuario.

- Utilizar procedimientos para la validación de los datos indicados por el usuario, ya que el modo en el que se pasan los parámetros a los procedimientos almacenados

evita que la inyección SQL pueda ser usada en la mayoría de los casos.

- En el caso de los entornos multinivel, todos los datos deben validarse antes de que se admitan en la zona de confianza. Los que no superen el proceso de validación deben rechazarse, devolviendo un error al nivel anterior.

- Implementar varias capas de validación. Las precauciones que se tomen contra usuarios malintencionados ocasionales pueden resultar ineficaces contra atacantes más obstinados. Lo más recomendable es validar los datos especificados por el usuario en la interfaz de usuario y después en todos los puntos posteriores que atraviesen un límite de confianza. Por ejemplo, la validación de datos en una aplicación cliente puede evitar la inyección de scripts. Sin embargo, si en el siguiente nivel se asume que ya se ha validado la entrada, cualquier usuario malintencionado que sea capaz de eludir un cliente puede disfrutar de un acceso sin restricciones al sistema.

- No concatenar nunca datos especificados por el usuario que no se hayan validado previamente. La concatenación de cadenas es el punto de entrada principal de una inyección de scripts.

- A ser posible, han de rechazarse los datos que contengan algunos caracteres especiales, como son: (delimitador de consultas), ‘ (delimitador de cadenas de datos de caracteres), -- (delimitador de comentarios), /*…*/ (delimitadores de comentarios que hacen que el servidor no evalúe el texto incluido en medio) y xp_ (se utiliza al principio del nombre de procedimientos almacenados extendidos de catálogo, como xp_cmdshell). Para ello será necesario comprobar determinados valores de la consulta que puedan incluir estos caracteres, como las cadenas.

- Resulta de gran utilidad limitar al máximo los permisos del usuario que ejecuta las sentencias para evitar posibles problemas. Por ejemplo, utilizando un usuario distinto para las sentencias SELECT, DELETE, UPDATE y asegurándose de que cada ejecución de una sentencia ejecute una sentencia del tipo permitido. Por supuesto, utilizar el usuario ‘sa’ (que proporciona control total del SQL Server, incluyendo una Shell a nivel de SO, con los privilegios del servicio MSSQLSERVER, usando el “procedimiento almacenado extendido” xp_cmdshell, y la habilidad de leer, escribir y mutilar todos los datos almacenados en la base de datos SQL Server) o uno que pertenezca al rol ‘db_owner’ (que proporciona habilidad de leer/escribir datos en la base de datos afectada, así como de eliminar tablas, crear nuevos objetos y, en definitiva, tomar el control total) para ejecutar las sentencias de uso habitual de la base de datos debería quedar descartado, ya que son los usuarios por defecto que se implementan en la instalación de SQL Server.

Este tipo de ataques, más allá de actualizaciones o herramientas de protección, requieren para mejorar la seguridad seguir una serie de buenos hábitos como pueden ser los anteriores y conocer a la hora de programar las posibilidades de las sentencias de acceso a las bases de datos. En la medida que los grandes volúmenes de información se afianzan como parte de la red y cada vez se hace más hincapié en su protección, hoy en día resulta mucho más dificil que hace unos años encontrar víctimas indefensas a estos ataques, si bien la creciente cantidad de recursos que se mueve actualmente sigue dando juego a la hora de utilizar la inyección de código para acceder a sistemas como los que implementa SQL Server.