Defective code. SQL injection

En este artículo y en varios de los posteriores se va a realizar un inciso dentro de la temática S-SDLC para estudiar con detalle las principales vulnerabilidades contempladas en el TOP 10 de OWASP 2017 dentro del desarrollo WEB. Veremos el código defectuoso que permite que aparezcan este tipo de vulnerabilidades, el primero que vamos a abordar SQL-Injection (inyeccion de codigo SQL), puesto que es el primero de la lista por ser el incidente que en mayor número de WEB se produce .

¿Qué es SQL-Injection?

Se podría definir como un conjunto de vulnerabilidades en la entrada de parámetros a la aplicación WEB. Se trataría de convencer a la aplicación de que ejecute código SQL cuando no lo debe de ejecutar (un código seguro es aquel que realiza lo que debe hacer y nada más). Casi cualquier fuente puede ser un vector de inyección parámetros,como por ejemplo servicios externos e internos y por supuesto los usuarios. El ataque se produce cuando el vector consigue que se interprete ese código SQL en el servidor.

Estos defectos son muy comunes sobre todo cuando el código es heredado, estos errores se pueden dar en todo tipo de bases de datos, la diferencia estaría en las instrucciones inyectadas ya que dependería de las utilizadas por la base de datos que utilice la aplicación WEB.

Cuales podrían ser sus efectos.

La inyección SQL podría permitir a un atacante falsificar una identidad, manipular datos existentes, causar problemas de repudio en transacciones económicas, permitir la divulgación de los datos o borrar dichos datos.

Cómo sería un ataque.

EL ataque podría ser de multitud de maneras, dependiendo de el vector de ataque y el tipo de base de datos pero podría ser tan sencillo como introducir en un panel de autenticación la siguiente secuencia “ ‘or’ ‘a’=’a’” los efectos se pueden observar en la siguiente imagen realizada en una WEB preparada al efecto, pero con un error común que se abordará más adelante cuando estudiemos el error en su código.

Como se ve en la imagen al introducir el código redundante que realiza una función OR a una tautología (puesto que en todas las condiciones va ser verdad) como es a=a la base de datos devuelve todos los nombres de los usuarios guardados en ella, puesto que resuelve que en todos los casos es verdad, haciendo corresponder con todos los “ID”. Esta función representaría las siguiente sentencia en lenguaje de consulta SQL:

SELECT*FROM users WHERE name =''OR'a'='a';

Como se puede deducir del código al ejecutarse la consulta va a ser verdad para todos los usuarios, lo que conlleva que sin tener ningún conocimiento un atacante conseguiría el nombre de todos los usuarios de una WEB.

Código defectuoso.

En la siguiente imagen se puede observar el código de una aplicación WEB en lenguaje PHP (con lo cual se ejecutaría en el lado del servidor) con la vulnerabilidad.

La variable id es vulnerable en este script PHP a la inyección SQL puesto que no tiene ningún tratamiento en la introducción de datos y eso conlleva a que cualquier sentencia que se introduzca sería ejecutada.

En el siguiente código se corrige el error como se va a poder comprobar filtrando los datos insertados en la aplicación WEB.

El error de programación sería corregido con las funciones stripslashes($id) y mysql_real_escape_string($id).

La función stripslashes($id) sirve para retirar las comillas y las barras dobles de los string introducidos antes de su tratamiento por el resto de la aplicación y la consulta SQL, con lo cual deja de ser una sentencia de consulta para ser un simple string, si no coincide con el id de ningún usuario la aplicación devolverá un error al no encontrar dicho usuario.

La segunda función de filtrado que utilizamos en el código es mysql_real_escape_string($id) lo que hace es eliminar los caracteres especiales de la cadena para su uso posterior en la consulta SQL, la función debe de usarse con pocas excepciones para asegurarnos de que los datos son seguros antes de enviar la consulta a la base de datos.

Conclusión.

Se pueden evitar estos ataques tan solo evitando la razón que los produce, siendo esta que, cualquier usuario puede introducir datos sin control en las aplicaciones, para ello introduciremos filtros de algún tipo en los datos introducidos por el usuario. El código anterior tan solo es un pequeño ejemplo en lenguaje PHP, el ataque se puede producir en cualquier lenguaje y por lo tanto en todos los lenguajes también se pueden colocar estos filtros para mitigar la vulnerabilidad.

Espero que este y el resto de artículos sean de vuestra utilidad un saludo.