Como evitar SQL Injection (& Blind SQL Injection) en .NET. Code Analysis y FXCop

Blind SQL Injection es una forma de explotación de las vulnerabilidades SQL Injection, luego evitando problemas de SQL Injection se acabó el problema. Evidente ¿no?. Para evitar vulnerabilidades de SQL Injection se deben usar consultas pre-compiladas, realizar filtrado de parámetros robusto, etc... Todos los manuales de seguridad para todos los lenguajes tienen un capítulo para ayudar a los desarrolladores a evitar SQL Injection en ese lenguaje. En .NET la recomendación es utilizar consultas parametrizadas que evitan completamente la inyección de comandos.

Hoy no es sobre recomendaciones de desarrollo de lo que quería hablar, sino de un par de herramientas de Análisis Estático de Código para evitar las inyecciones SQL. Estas herramientas permiten buscar errores de desarrollo en el código fuente de las aplicaciones .NET. Lógicamente buscan los fallos en la creación de consultas que generan bugs de SQL Injection, pero también miran fallos de compatibilidad de código para versiones antiguas, o si se ha hardcodeado código, o si se ha utilizado o no la ofuscación de punteros, etc… Estas herramientas no te hacen mejor programador, pero te ayudan a detectar los fallos.

FXCop & Code Analysis

FXCop es una herramienta gratuita que se puede descargar desde la siguiente URL: http://www.gotdotnet.com/Team/FxCop/, mientras que Code Analysis es una herramienta que sirve para el mismo fin, pero viene integrada dentro de Visual Studio Team System. Cuando realizan un análisis evalúan más de 150 tipos distintos de posibles fallos que están catalogados en las siguientes categorías: Reglas de Diseño, Globalización, Interoperatibilidad, Movilidad, Mantenibilidad, Nombrado, Rendimiento, Portabilidad, Confiabilidad, Seguridad y Usabilidad.

Categorías de Reglas en FxCop
En cada una de estas secciones podremos marcar las reglas que queramos comprobar para que se efectúe el análisis según estas reglas. Por defecto están todas marcadas, pero puede ser necesario desactivar algunas comprobaciones que no son necesarios en nuestro proyecto o que, aunque no sean una recomendación correcta, debemos realizar en contra de las recomendaciones del aplicativo.

Ejemplo de Análisis con FxCop

En este ejemplo he cogido una dll de las que se encuentran en mi sistema instalada por uno de esos programas que te descargas por Internet y la he importado. El siguiente paso es dar al botón de Analizar y leer resultados. Tras analizarla, FxCop detecta posibles fallos en la aplicación. Cada uno de los fallos es marcado con un ratio de certeza que indica la posibilidad o no de que sea un Falso Positivo y con un nivel de criticidad. Además el programa nos da la información necesaria sobre dicho posible defecto. A partir de ahí es labor del programador comprobar si realmente es o no un fallo.

Análisis con FxCop
Con estas ayudas el programador debe ser capaz de investigar y encontrar el posible agujero de seguridad. No son perfectas, no van a encontar todos los bugs, pero seguro que aumentan la seguridad del código y la destreza del programador.

Ejemplo con SQL Injection & Code Analysis

Vamos a ver cómo funciona la regla de seguridad que busca fallos que permitan ataques del tipo SQL Injection, en este caso, usando Code Analysis de Team System:

Código .NET vulnerable
En rojo una sentencia vulnerable XXL. Es decir, si has hecho alguna sentencia así, concatenando tan alegremente, tu código tiene un buen agujero de seguridad.. En verde una sentencia SQL Parametrizada que no es vulnerable ya que está pre-compilada y validada por el sistema.

El siguiente paso es activar el análisis de código estático en VS Team System. En las propiedades del proyecto habilitamos en la sección Code Analysis la casilla “Enable Code Analysis”. Además marcamos la regla “CA2100:Review sql queries for security vulnerabilities” para que cuando se encuentre una sentencia vulnerable nos de un ERROR en lugar de un WARNING.

Selección de reglas en Code Analysis
Acto seguido compilamos el proyecto. Justo antes de realizar la compilación ejecutará el análisis de código, de forma que si encuentra alguna sentencia vulnerable nos dará un ERROR. Como se ve en la siguiente imagen sólo aparece el error en la primera consulta SQL, ya que es la única que es vulnerable. La segunda consulta, que ha sido parametrizada, no produce error, ya que al insertar el dato que proviene del usuario dentro de un parámetro, no va a poder ejecutar el código “malicioso” que pudiera contener.

Mensaje de Error de Code Analysis
La pregunta es, ¿por qué sigue habiendo tantos fallos de Inyecciones SQL? Las herramientas no son perfectas pero sí que ayudan.

Aquí tenéis una lista de productos que realizan Análisis de Código Estático en otros lenguajes: List of tools for static code analysis

Saludos!