Este ataque consiste en agregar código , ya sea SQL, javascript, o comandos de sistema operativo. Este ataque aprovecha la falta o mala implementación de validación en las entradas de una aplicación.
Inyección SQL
Este tipo de inyección consiste en escribir consultas SQL en los campos de un formulario con la finalidad de que se ejecute esta consulta en lugar de la que definió el programador o , en su defecto, intentar adivinar la consulta que se definió y tratar de forzar el resultado.
Ejemplo de ataque a un inicio de sesión
Un inicio de sesión común pide que se ingrese el usuario y la contraseña. Se puede esperar que la consulta que se hace la base de datos sea algo parecido a: “SELECT username FROM user WHERE Username = ‘usuario ingresado en el formulario’ and Password = ‘contraseña ingresada en el formulario'”. El comportamiento normal de esta consulta es devolver un reglón con el nombre de usuario y la contraseña. La validación más utilizada, en el código de la aplicación, es comprobar si la consulta regresó un renglón. Si la consulta regresa un renglón, los datos son correctos. De lo contrario se pide que se ingresen de nuevo.
Se puede intentar que la consulta regrese algo aún sin datos correctos escribiendo ‘ or 1 = 1 en ambos campos del formulario.
La comilla del principio es para cerrar la comilla que llevan las cadenas en SQL y la validación or 1 = 1 hará que se devuelva un renglón con el resultado de la validación, en este caso TRUE.
El servidor SQL ejecutará la consulta SELECT username FROM user WHERE Username = ” or 1 = 1 and Password = ” or 1 = 1. Esto devolverá unun renglón con el resultado de la validación: TRUE.
Prevención
Hay varias maneras de evitar este ataque.
Consultas parametrizadas
Las consultas parametrizadas son una manera de armar consultas SQL. La biblioteca de la consulta se encarga de escapar caracteres especiales, validar el tipo de dato y agregarlo a la consulta.
Ejemplo en java
String query = “SELECT account_balance FROM user_data WHERE user_name = ? “;
PreparedStatement pstmt = connection.prepareStatement( query );
pstmt.setString( 1, custname);
ResultSet results = pstmt.executeQuery( );
Procedimientos almacenados
Otra manera de no armar consultas en el código es realizar procedimientos almacenados en el servidor de base de datos y mandarlo a llamar desde la aplicación.
Escape de caracteres
Existen varias bibliotecas para escapar caracteres especiales. También se pueden escapar de manera manual.
Herramientas para probar inyección de código SQL
Es importante saber si una aplicación desarrollada es vulnerable a este tipo de ataques para corregirlo. Para este fin hay varias herramientas para probarlas.
SQL map es una herramienta con la que se pueden probar varios manejadores de bases de datos como MySQL, Oracle, PostgreSQL, Microsoft SQL Server, entre otros.
SQL Ninja Es una herramienta que funciona para Microsoft SQL Server y puede integrarse con metasploit.
Inyección Javascript
Este tipo de inyección es muy parecido al anterior, pero el código que se inyecta en el campo de un formulario es javascript. Esto implica que toda la ejecución se realizará en el lado del cliente.
Para probar si una aplicación web es vulnerable a este ataque se debe escribir en el campo de texto <script>alert()</script>. Este código producirá una alerta en el navegador cuando se ejecute.
Puede haber dos formas de ejecución. Que se ejecute en el instante en que se envía el formulario o que se almacene en un medio persistente, como una base de datos, y se ejecute al cargar el contenido de este.
Si se ingresara este código en el nombre de usuario al registrar un nuevo usuario, se ejecutaría cada que se muestre el nombre en alguna parte de la aplicación.
Prevención
para evitar la inyección de Javascript generalmente se valida que no se ingrsen caracteres como ‘<‘ o ‘>’ Para evitar la inserción de marcas HTML. pero el se puede el código se puede ofuscar. Para más información consultar Detección automática de ataques con ofuscación en javascript
Inyección de comandos de sistema operativo
La inyección de comandos de sistema operativo funciona de la misma manera que las anteriores. Pero el impacto puede ser mucho mayor, ya que no solo se obtiene acceso a los datos de la aplicación, sino al sistema operativo.
Prevención
La recomendación general es no permitir la ejecución
Referencias
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Defense_Option_1:_Prepared_Statements_.28with_Parameterized_Queries.29