Inyección SQL

Clasificación de los vectores de ataque de inyección SQL en 2010

En seguridad informática la inyección SQL es una técnica de inyección de código , utilizada para atacar aplicaciones que gestionan datos a través de bases de datos relacionales utilizando el lenguaje SQL . La falta de verificación de la entrada del usuario le permite insertar artificialmente cadenas de código SQL que serán ejecutadas por la aplicación del servidor : gracias a este mecanismo, es posible ejecutar comandos SQL, incluso los más complejos, alterando los datos (por ejemplo, creación de nuevos usuarios) hasta la descarga completa de los contenidos en la base de datos.

Historia

Las primeras discusiones públicas relacionadas con la inyección SQL aparecieron alrededor de 1998. Por ejemplo, un artículo de 1998 en Phrack Magazine .

Descripción

Explota las vulnerabilidades de seguridad del código de la aplicación que se conecta a la fuente de datos SQL, por ejemplo, aprovechando la falta de filtrado de entrada del usuario (p. ej., 'caracteres de escape' en cadenas SQL) o la falta de tipificación segura de las variables utilizadas. Es más conocido como ataque a una aplicación web , pero también se utiliza para atacar cualquier otro tipo de aplicación que utilice bases de datos SQL de forma insegura.

Permite a los atacantes suplantar la identidad , modificar datos existentes, causar problemas de repudio, como cancelar transacciones o cambiar estados financieros, obtener todos los datos del sistema, eliminar o hacer que los datos sean inaccesibles y crear o comprometer usuarios (por ejemplo, administradores) del servidor de la base de datos.

En un estudio de 2012, se observó que, en promedio, las aplicaciones web reciben 4 ataques por mes y los minoristas reciben el doble de ataques que las industrias.

Tipos de inyección SQL

El Open Web Application Security Project considera que la inyección de SQL (SQLI) es una de las 10 mayores vulnerabilidades de aplicaciones web en 2007 y 2010. En 2013 y 2017, SQLI fue considerado el ataque número uno en el OWASP top 10. Hay cuatro subclases principales de inyección SQL:

• SQLI clásico
• Inyección SQL ciega o de inferencia
• Sistema de gestión de base de datos -SQLI específico
• SQLI compuesto

• Inyección SQL + autenticación insuficiente
• Inyección SQL + ataques DDoS
• Inyección SQL + secuestro de DNS
• Inyección SQL + XSS

Storm Worm es un ejemplo del uso de SQLI compuesto.

Esta clasificación del estado del SQLI representa su evolución hasta el año 2010.

Implementaciones técnicas

Caracteres de escape no filtrados correctamente

Este tipo de inyección SQL ocurre cuando la entrada del usuario no se filtra mediante caracteres de escape y luego se pasa dentro de una declaración. Esto puede provocar la manipulación de las declaraciones realizadas en la base de datos por parte de los usuarios finales de la aplicación.

La siguiente línea de código ilustra este tipo de vulnerabilidad:

statement = "SELECT * FROM users WHERE name = '"+ userName + "';"

Este código SQL recupera todos los registros que tienen un determinado nombre de usuario de la tabla de usuarios. Sin embargo, si un atacante escribe la variable "nombre de usuario" de cierta manera, la instrucción SQL puede hacer más de lo que pretendía el autor del código. Por ejemplo, establecer la variable "nombre de usuario" como:

'O' 1 '=' 1

O usando comentarios para detener la ejecución del resto de la consulta (hay tres tipos de comentarios SQL ). Las tres líneas tienen un espacio al final:

'O' 1 '=' 1 '-
'O' 1 '=' 1 '({
'O' 1 '=' 1 '/ *

Así es como se ve la representación de la declaración SQL después de insertar una de las líneas de código con comentario y sin:

SELECCIONE  *  DE  usuarios  DONDE  nombre  =  ''  O  '1' = '1' ;

SELECCIONE  *  DE  usuarios  DONDE  nombre  =  ''  O  '1' = '1'  - ';

Si este código se usara en un procedimiento de autenticación, entonces este ejemplo podría usarse para forzar la selección de todos los campos de datos (*) de "todos" los usuarios en lugar de un solo nombre de usuario como pretende el código, esto sucede porque la evaluación de ' 1' = '1' siempre es verdadero ( evaluación de cortocircuito ).

En el ejemplo a continuación, el valor de "nombre de usuario" provocaría la eliminación de la tabla "usuario" y la selección de todos los datos en la tabla "información de usuario" (básicamente revelando la información de todos los usuarios), utilizando una API que permite múltiples declaraciones :

a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't

Ingresar la entrada especificada anteriormente hace que la declaración SQL se vuelva así:

SELECCIONE  *  DE  usuarios  DONDE  nombre  =  'a' ; Usuarios de DROP  TABLE  ; SELECCIONE * DESDE información de usuario DONDE 't' = 't' ;        

Si bien muchas de las implementaciones del servidor SQL le permiten ejecutar varias declaraciones con una sola llamada, algunas de estas API, como en la función PHP, mysql_query()no lo permiten por razones de seguridad. Esto evita que los atacantes inyecten consultas completamente separadas en la declaración, pero eso no les impide modificarlas.

Manejo incorrecto del tipo

Este tipo de inyección SQL se produce cuando un campo proporcionado por el usuario no está fuertemente tipado o no se comprueban las restricciones de tipo. Esto puede suceder, por ejemplo, cuando se usa un campo numérico en una instrucción SQL, pero el programador no verifica que la entrada ingresada por el usuario sea realmente numérica. Por ejemplo:

sentencia: = " " + una_variable + ";"
SELECT * FROM userinfo WHERE id =

De esta declaración es evidente que el autor quería que la variable fuera un número que se refiriera al campo "id". Sin embargo, si de hecho es una cadena , el usuario final podría manipular la declaración a voluntad y, por lo tanto, eludir la necesidad de caracteres de escape. Por ejemplo, establecer una variable para

1; usuarios de DROP TABLE

La tabla de "usuarios" se elimina de la base de datos, ya que la instrucción SQL se convierte en:

SELECCIONE  *  DESDE información de  usuario  DONDE  id = 1 ;  Usuarios de DROP  TABLE  ;

Inyección ciega de SQL

Blind SQL Injection se utiliza cuando una aplicación web es vulnerable a SQLI pero los resultados de la operación no son visibles para el atacante. Es posible que la página con la vulnerabilidad no muestre datos, pero se puede mostrar de manera diferente según el resultado de la declaración de tipo lógico inyectada en la declaración SQL original llamada para esa página. Este tipo de ataque puede llevar mucho tiempo porque debe crear una nueva declaración para cada bit recuperado. Existen diversas herramientas que permiten automatizar estos ataques una vez identificadas las vulnerabilidades y cuál es la información del objetivo.

Respuestas condicionales

Uno de los tipos de inyección ciega de SQL obliga a la base de datos a evaluar una declaración lógica en una pantalla de aplicación ordinaria. Por ejemplo, un sitio de reseñas de libros usa una cadena de consulta para decidir qué reseña de libros mostrar. Luego, la URL http://books.example.com/showReview.php?ID=5 hará que el servidor ejecute la consulta.

SELECCIONE  *  DE  reseñas de libros  WHERE  ID  =  'Valor (ID)' ;

Con lo cual llenará la página con los datos de revisión con ID 5, almacenados en la tabla de reseñas de libros. La consulta se ejecuta completamente en el servidor; por lo que el usuario no conocerá los nombres de la base de datos, la tabla o los campos, ni conocerá la cadena de consulta. El usuario solo verá que la URL anterior devuelve una reseña de un libro. Un hacker puede cargar las siguientes URLs y , lo que podría generar la ejecución de estas consultas respectivamente: http://books.example.com/showReview.php?ID=5 OR 1=1http://books.example.com/showReview.php?ID=5 AND 1=2

SELECCIONE  *  DE  reseñas de libros  WHERE  ID  =  '5'  OR  '1' = '1' ; 
SELECCIONE  *  DE  reseñas de libros  WHERE  ID  =  '5'  AND  '1' = '2' ;

Si usa la URL con "1 = 1", se carga la revisión original y con la URL que tiene "1 = 2", se carga una página en blanco o de error, y la página devuelta no muestra al usuario que es solo una URL no válida. ingresado, es muy probable que el sitio sea vulnerable a ataques de inyección SQL porque significa que ambas consultas podrían haber sido ejecutadas con éxito por el servidor de la base de datos. El pirata informático podría ejecutar la siguiente cadena de consulta para averiguar el número de versión de MySQL presente en el servidor: una vez ejecutado, mostraría la revisión del libro si el servidor usa MySQL 4 y, de lo contrario, una página en blanco o de error. El hacker puede continuar usando el código dentro de las cadenas de consulta para obtener más y más información sobre el servidor hasta que se descubra una nueva vía de ataque o hasta que se cumplan sus objetivos. http://books.example.com/showReview.php?ID=5 AND substring(@@version, 1, INSTR(@@version, '.') - 1)=4

Inyección SQL de segundo orden

La inyección SQL de segundo orden ocurre cuando los valores enviados por el usuario contienen comandos maliciosos que se guardan en el servidor en lugar de ejecutarse de inmediato. En algunos casos, la aplicación puede almacenar la entrada maliciosa como si fuera una instrucción SQL válida, y otra parte de la aplicación que no verifica para protegerse de las inyecciones de SQL podría ejecutar la instrucción almacenada. Este tipo de ataque requiere saber que los valores enviados se utilizan posteriormente. Es posible que los escáneres de seguridad de aplicaciones web no detecten fácilmente este tipo de inyección SQL y es posible que deban recibir instrucciones manuales sobre dónde buscar pistas sobre el ataque.

Prevención

La inyección SQL es un ataque bien conocido que se puede evitar fácilmente con medidas simples. Después de lo que se cree que fue un ataque de inyección SQL a la empresa británica TalkTalk Group, la BBC informó que los expertos en seguridad estaban asombrados de que una empresa tan grande fuera vulnerable a este tipo de ataque.

Sentencia parametrizada

Con muchas de las plataformas de desarrollo, es posible usar declaraciones parametrizadas que funcionan con parámetros (llamados marcadores de posición o variables de vinculación) en lugar de insertar directamente la entrada del usuario directamente en la declaración. Un marcador de posición solo puede almacenar un valor del tipo especificado y no cualquier instrucción SQL. De esta forma, la inyección SQL simplemente se trata como un valor no válido para ese parámetro.

En muchos casos, la instrucción SQL es fija y, por lo tanto, cada parámetro es un escalar y no una tabla. Luego, la entrada del usuario se asigna (vincula) a un parámetro.

Fortalecimiento a nivel de código

El uso de bibliotecas de mapeo relacionales de objetos evita escribir código SQL. Las bibliotecas ORM generan automáticamente declaraciones SQL parametrizadas, a partir de código orientado a objetos.

Escapar

Una forma sencilla, aunque propensa a errores, de evitar los ataques SQLI es evitar los caracteres que tienen un significado especial en SQL. Los manuales de SQL DBMS explican qué caracteres tienen significados especiales, esto le permite crear una lista de caracteres que deben reemplazarse porque son potencialmente dañinos. Por ejemplo, cada apóstrofo ( ') en un parámetro se debe reemplazar con dos apóstrofes ('') para obtener una cadena SQL válida de literales. Por ejemplo, en PHP solemos evitar los caracteres especiales en los parámetros usando la función mysqli_real_escape_string();antes de enviar la consulta SQL:

$ mysqli  =  new  mysqli ( 'hostname' ,  'db_username' ,  'db_password' , 'db_name  ' ); 
$ consulta  =  sprintf ( "SELECCIONE * DE` Usuarios` DONDE Nombre de usuario = '% s' Y Contraseña = '% s' " , 
                  $ mysqli -> real_escape_string ( $ nombre de usuario ), 
                  $ mysqli -> real_escape_string ( $ contraseña )); 
$ mysqli -> consulta ( $ consulta );

Esta función antepone barras invertidas a los siguientes caracteres : \x00,,, \ny . Por lo general, se utiliza para asegurar las consultas antes de enviarlas a una base de datos MySQL . En PHP hay tantas otras funciones para varios tipos de bases de datos como para PostgreSQL . La función se usa para evitar caracteres especiales, y se usa en particular para consultar bases de datos que no tienen funciones de escape en PHP, devuelve una cadena con barras invertidas antes de los caracteres que deben citarse. Estos caracteres son el apóstrofe ('), las comillas dobles ("), la barra invertida y el carácter NULL. Escapar siempre las cadenas SQL es una práctica propensa a errores porque es fácil olvidarse de escapar de las cadenas SQL. una determinada cadena. una capa transparente para asegurar la entrada puede reducir los errores o eliminarlos por completo. \r\'"\x1a
pg_escape_string()addslashes(string $str)

Control de patrón

Puede verificar parámetros con cadenas de números enteros, flotantes o booleanos, y verificar si su valor tiene una estructura válida para el tipo de datos verificados. Las cadenas que tienen una estructura bastante rígida (fecha, UUID, solo alfanumérico, etc.) se pueden verificar para ver si reflejan la estructura del tipo de datos.

Permisos de base de datos

Restringir los permisos en el inicio de sesión que utiliza la aplicación web para acceder a la base de datos, poniendo solo los permisos necesarios, puede servir para reducir la efectividad de cualquier ataque de inyección SQL, dirigido a los errores de la aplicación.

Por ejemplo, en Microsoft SQL Server , se puede prohibir el inicio de sesión de la base de datos para realizar una selección a algunas de las tablas del sistema, de esta forma se evita que JavaScript se inserte en todas las columnas de la base de datos.

denegar seleccionar en sys . sysobjects a webdatabaselogon ;     
denegar seleccionar en sys . objetos a webdatabaselogon ;     
denegar seleccionar en sys . tablas a webdatabaselogon ;     
denegar seleccionar en sys . vistas a webdatabaselogon ;     
denegar seleccionar en sys . paquetes a webdatabaselogon ;     

Conversión hexadecimal

La conversión hexadecimal se realiza convirtiendo texto sin formato a su representación hexadecimal antes de usarlo en un comando SQL. En PHP, las funciones utilizadas son function bin2hex() o dechex . Se prefiere la función bin2hex()ya que convierte cualquier carácter y no solo números. En esta sección sólo se utilizará la función bin2hex().

Ejemplo de uso de la función PHP bin2hex():

echo  bin2hex ( "prueba" );

La salida de la función anterior es:

74657374

Como ejemplo hablamos únicamente de la base de datos MySQL . En MySQL, la función unhex() se utiliza para convertir una cadena hexadecimal en texto sin formato.

Ejemplo de la función unhex()en MySQL:

SELECCIONE  *  DE  myTable  DONDE  id = unhex ( '32' );

Si convertimos la cadena unhex()en texto sin formato, se convertiría en:

SELECCIONE  *  DESDE  myTable  DONDE  id = 2 ;

La conversión hexadecimal elimina los ataques de inyección SQL porque la cadena hexadecimal enviada a la función unhex()se devuelve como una cadena utilizada anteriormente y no se interpreta.

Ejemplo de programación

El siguiente programa breve presenta un programa PHP y su función. El programa muestra un ataque de inyección SQL en un simple comando SQL. A continuación, muestra cómo al convertir todos los datos entrantes a hexadecimales, logra detener el ataque. La función PHP es un conjunto simple de comandos para la base de datos y para recuperar la salida de la base de datos SQL. Como se mencionó anteriormente, la base de datos utilizada es MySQL.

Código de muestra

Archivo: prueba.php 
<?php

    include_once  "dosql.php" ; 
# 
# Ponga aquí la información de su base de datos. Estoy usando datos de mi archivo de registro. 
# 
    $ nombre de host  =  "mihost" ; 
    $ nombreusuario  =  "miUsuario" ; 
    $ contraseña  =  "miContraseña" ; 
    $ base de datos  =  "miBase de datos" ;

    $ mysqli  =  new  mysqli ( $ nombre de host ,  $ nombre de usuario ,  $ contraseña ,  $ base de datos );

    if  ( $ mysqli -> connect_errno )  { 
        echo  "Error al conectarse a MySQL: (" ,  $ mysqli -> connect_errno ,  ")" ,  $ mysqli -> connect_error ; 
        salida ; 
    } 
    echo  "INYECCIÓN SQL - Simple \ n " ; 
    $ sql  =  "SELECCIONE * DESDE registro DONDE log_id = '2' O 1 = 1; # '" ; 
    $res  =  dosql ( $sql ); 
    foreach  ( $ res [ 0 ]  as  $ k  =>  $ v )  { 
        echo  "RES [ $ k ] = $ v \ n " ; 
    }

    echo  " \n\n INYECCIÓN SQL = Hexadecimal \n " ; 
    $ sql  =  "SELECT * FROM log WHERE log_id = unhex ('"  .  bin2hex ( "2' o 1 = 1; # '" )  .  "')" ; 
    $res  =  dosql ( $sql ); 
    foreach  ( $ res [ 0 ]  as  $ k  =>  $ v )  { 
        echo  "RES [ $ k ] = $ v \ n " ; 
    }

    salida ; 
?>

Archivo: dosql.php 
<?php

############################################## ############################################## ## ############################### 
# dosql (). Haz el comando SQL. 
############################################## ############################################## ## ############################# 
función  dosql ( $ sql ) 
{ 
    global  $ mysqli ;

    $ cmd  =  "INSERTAR EN EL registro (fecha, entrada) VALORES (AHORA (), unhex ('"  .  bin2hex ( $ sql )  .  "'))" ; 
    $res  =  $mysqli -> consulta ( $cmd );

    $res  =  $mysqli -> consulta ( $sql ); 
    if  ( ! $ res )  { 
        $ matriz  =  debug_backtrace (); 
        if  ( isset ( $ arreglo [ 1 ]))  {  $ a  =  $ arreglo [ 1 ] [ 'línea' ];  } 
        else  if  ( isset ( $ arreglo [ 0 ]))  {  $ a  =  $ arreglo [ 0 ] [ 'línea' ];  } 
        más  {  $ a  =  "???" ;  }

        echo  "ERROR @" ,  $ a ,  ": (" ,  $ mysqli -> errno ,  ") \ n " ,  $ mysqli -> error ,  " \ n \ n " ; 
        echo  "SQL= $sql\n " ; 
        salida ; 
    }

    if  ( preg_match ( "/ INSERTAR / i" ,  $ sql ))  {  return  $ mysqli -> insert_id ;  } 
    if  ( preg_match ( "/ DELETE / i" ,  $ sql ))  {  return  null ;  } 
    if  ( ! is_object ( $ res ))  {  return  null ;  }

    $ cuenta  =  - 1 ; 
    $ matriz  =  matriz (); 
    $ res -> buscar_datos ( 0 ); 
    while  ( $ fila  =  $ res -> fetch_assoc ())  { 
        $ cuenta ++ ; 
        foreach  ( $fila  como  $k  =>  $v )  {  $array [ $contar ] [ $k ]  =  $v ;  } 
    }

    devuelve  $matriz ; 
}

Salida del programa

INYECCIÓN SQL - Simple
RES [id_registro] = 1
RES [fecha] = 2015-03-25 10:40:18
RES [entrada] = MOSTRAR columnas completas DESDE el registro

INYECCIÓN SQL = hexadecimal
RES [id_registro] = 2
RES [fecha] = 2015-03-25 10:40:18
RES [entrada] = SELECCIONAR * DESDE registro ORDENAR POR título ASC

La primera parte de la salida del programa muestra el comando SQL que se envía sin realizar comprobaciones ni cambios. La solicitud original debería devolver el segundo registro, pero gracias a la inyección de SQL, se devuelve el primer registro. La segunda parte de la salida muestra lo que sucede si todos los datos de entrada se convierten a hexadecimales. Mediante la conversión, todos los caracteres del comando, incluidos los ingresados ​​por inyección SQL, se convierten a hexadecimales y ya no son un peligro porque no se interpretan como comandos sino como cadenas. Dado que todos los caracteres se tratan como parte de la cadena completa, si MySQL entiende que necesita un número, convierte la cadena en un número. Las reglas para la conversión de cadena a número son convertir la cadena hasta que alcance un carácter no numérico o el final de la cadena. Cuando ocurre cualquiera de estos dos eventos, la conversión se detiene en ese punto. Luego, se ve el "2" y luego el apóstrofe ('), que le dice a My SQL que termine de convertir la cadena. Finalmente, el valor numérico dos (2) se utiliza para determinar qué registro devolver. Este proceso o método de evaluación de los datos entrantes es la razón por la cual los ataques de inyección SQL no pueden ocurrir si se usa una conversión hexadecimal.

Consideraciones Adicionales

Además, usar BIN2HEX y UNHEX requiere menos tiempo de ejecución que los otros métodos presentados. Esto se debe principalmente a la naturaleza simplista de ambas funciones. Como se muestra en el fragmento de JavaScript, la conversión a hexadecimal es bastante sencilla y directa:

Código de muestra

Archivo :  toHex . js 
////////////////////////////////////////////////// /////////////////////////////// 
// toHex (). Convierte una cadena a hexadecimal. 
/////////////////////////////////////////////////// ////////////////////////////// 
función  toHex ( s ) 
{ 
	var  l  =  "0123456789ABCDEF" ; 
	var  o  =  "" ;

	if  ( tipo  de s  ! =  "cadena" )  {  s  =  s . a la cadena ();  } 
	para  ( var  i  =  0 ;  i  <  s . longitud ;  i ++ )  { 
		var  c  =  s . charCodeAt ( i ); 
		o  =  o  +  l [( c  >>  4 )]  +  l [( c  &  0xf )]; 
	}

	volver  o ; 
}

Como se muestra, a diferencia mysqli_real_escape_string() que debe escaparse para cada uno diferente, bin2hex()simplemente convierte todos los caracteres a su hexadecimal correspondiente. Y la función unhex()hace la operación contraria. Dado que no es necesario realizar pruebas para un carácter o caracteres en particular, el ciclo de conversión es pequeño y eficiente. Además, a diferencia mysqli_real_escape_string()de , si se descubre un nuevo método en el futuro, la función bin2hex()deshabilitará automáticamente la combinación de caracteres, porque devuelve una cadena hexadecimal. Un ejemplo de esto es el carácter Control-D ASCII. Control-D puede causar una condición de "Fin de transmisión" en algunos idiomas. Si se utiliza la función, bin2hex()Control-D se convierte simplemente en texto ASCII "04" que no puede causar ningún problema.

Ejemplos

• En febrero de 2002, Jeremiah Jacks descubrió que Guess.com era vulnerable a un ataque de inyección SQL, lo que permitía que cualquier persona que pudiera crear una URL personalizada recuperara más de 200.000 nombres, números y fechas de vencimiento de tarjetas de crédito en la base de datos de clientes del sitio.
• El 1 de noviembre de 2005, un hacker menor de edad usó un ataque de inyección SQL para ingresar al sitio de una revista taiwanesa de seguridad cibernética de Tech Target Group y robar información de los clientes.
• El 13 de enero de 2006, ciberdelincuentes rusos ingresaron al sitio del gobierno de Rhode y robaron información de tarjetas de crédito de personas que habían hecho negocios con agencias estatales.
• El 29 de marzo de 2006, un hacker descubrió una vulnerabilidad de inyección SQL en un sitio web oficial de turismo del gobierno indio.
• El 29 de junio de 2009, un ciberdelincuente desfiguró el sitio web de Microsoft en el Reino Unido mediante un ataque SQLI. Un sitio web británico, The Register informó que un portavoz de Microsoft había confirmado el problema.
• En enero de 2008, decenas de miles de PC se infectaron con un ataque de inyección SQL automatizado que aprovechaba las vulnerabilidades del código utilizando Microsoft SQL Server
• En enero de 2008, el sitio web de Kaspersky Lab de Malasia fue pirateado por un hacker turco conocido como "m0sted" que afirmó haber utilizado inyección SQL.
• En febrero de 2013, un grupo de piratas informáticos de Maldivas pirateó el sitio web "ONU-Maldivas" mediante inyección SQL.
• El 27 de mayo de 2009, los investigadores de Anti-US Hackers Infiltrate Army Servers dijeron que creían que habían recibido un ataque llamado inyección SQL que explotaba una vulnerabilidad de seguridad de Microsoft SQL Server para ingresar a los servidores web. Se sabe que "m0sted" ha llevado a cabo ataques similares en muchos otros sitios en el pasado.
• En mayo de 2008, una granja de servidores en China usó consultas automáticas enviadas al motor de búsqueda de Google para identificar sitios web que usaban el servidor SQL, que era vulnerable a una herramienta SQLI.
• En 2008, al menos de abril a agosto, comenzaron una serie de ataques para explotar las vulnerabilidades SQLI del servidor web IIS y SQL Server. El ataque no requería adivinar el nombre de una tabla o una columna, y corrompió todas las columnas de texto en todas las tablas en una sola solicitud. Se agregó una cadena HTML a cada valor con una referencia a un malware de JavaScript . Cuando el valor se mostró posteriormente al visitante del sitio, la secuencia de comandos intentó varios enfoques para tomar el control del sistema del visitante. El número de páginas web explotadas se estima en unas 500.000.
• El 17 de agosto de 2009, el Departamento de Justicia de los Estados Unidos acusó a un ciudadano estadounidense, Albert González , ya dos rusos del robo de 130 millones de números de tarjetas de crédito mediante un ataque SQLI. Se informa como "el caso más grande de robo de identidad en la historia de Estados Unidos".
• En diciembre de 2009, un pirata informático pudo acceder a una base de datos de RockYou que contenía las contraseñas y los nombres de usuario sin cifrar de aproximadamente 32 millones de usuarios mediante un ataque SQLI.
• En junio de 2010, un investigador de seguridad sudamericano que usa el alias "Ch Russo" obtuvo información confidencial sobre los usuarios de un sitio popular de BitTorrent , The Pirate Bay . Obtuvo acceso al panel de control como administrador del sitio y explotó una vulnerabilidad en SQLI que le permitió obtener información de la cuenta del usuario, incluidas direcciones IP, hash de contraseña MD5 y registros de qué torrents había subido cada usuario.
• Del 24 al 26 de julio de 2010, piratas informáticos de Japón y China utilizaron inyección SQL para obtener acceso a los datos de las tarjetas de crédito de los clientes de Neo BEAT, una empresa con sede en Osaka que administra el sitio web de un gran supermercado en línea. El ataque también dañó a siete socios comerciales, como las cadenas de supermercados Izumiya Co, Maruetsu Inc y Ryukyu Jusco Co. El robo de datos afectó a 12 191 clientes. Hasta el 14 de agosto de 2010, se informaron más de 300 casos de información de tarjetas de crédito utilizadas para comprar bienes y servicios en China.
• El 19 de septiembre de 2010, durante las elecciones generales suecas de 2010, un votante intentó inyectar código a mano escribiendo comandos SQL en la papeleta.
• El 8 de noviembre de 2010, el sitio de la Royal Navy británica fue atacado por un hacker rumano llamado TinKode que usó un ataque de inyección SQL.
• El 5 de febrero de 2011, HBGary , una firma de seguridad cibernética, penetró LulzSec mediante inyección SQL en su sitio controlado por CMS.
• El 27 de marzo de 2011, mysql.com, el sitio oficial de MySQL , fue atacado por un hacker que usó un ataque de inyección Blind SQL.
• El 11 de abril de 2011, Barracuda Networks se vio comprometida debido a una vulnerabilidad de SQLi. Se obtuvieron las direcciones de correo electrónico y los nombres de usuario de los empleados.
• Durante un período de 4 horas, el 27 de abril de 2011, ocurrió un ataque de inyección SQL automatizado en el sitio de Broadband Reports que pudo obtener el 8% de los pares de nombre de usuario/contraseña, 8000 cuentas aleatorias de 9000 activas y 90,000 cuentas antiguas o inactivo.
• El 1 de junio de 2011, los " hacktivistas " del grupo LulzSec fueron acusados ​​de robar cupones , claves de descarga y contraseñas que se almacenaban en la base de datos de texto del sitio web de Sony , accediendo a la información personal de millones de usuarios.
• En junio de 2011, PBS fue pirateada, muy probablemente a través de SQLi; el proceso completo utilizado por los hackers para llevar a cabo el ataque se describe en este blog de Imperva .
• En mayo de 2012, el sitio web de Wurm Online , un juego en línea multijugador masivo , fue eliminado mediante un ataque de inyección SQL mientras se actualizaba el sitio.
• En junio de 2012, un grupo de piratas informáticos robó 450 000 credenciales de inicio de sesión de Yahoo! . Los inicios de sesión se almacenaron en texto sin formato. El grupo rompió la seguridad de Yahoo a través de una " técnica de inyección SQL basada en unión ".
• El 1 de octubre de 2012, un grupo de piratas informáticos llamado "Team GhostShell" publicó registros personales de estudiantes, profesores, empleados, graduados de 53 universidades, incluidas Harvard , Princeton , Stanford , Cornell , Johns Hopkins y la Universidad de Zúrich en pastebin. com _ Los piratas informáticos dijeron que querían "crear conciencia sobre los cambios en la educación actual", quejándose del cambio en las leyes educativas en Europa y el aumento de las matrículas en los EE. UU.
• El 27 de junio de 2013, el grupo de hackers " RedHack " irrumpió en el sitio de la administración de Estambul. Afirmaron que cancelarían las deudas que la gente tenía con las empresas de agua, gas, internet, electricidad y teléfono. Además, publicaron un nombre de usuario y contraseña de administrador para que los ciudadanos pudieran iniciar sesión y cancelar sus deudas. Anunciaron esta noticia a través de Twitter.
• El 4 de noviembre de 2014, el grupo hacktivista "RaptorSwag" comprometió 71 bases de datos del gobierno chino mediante un ataque de inyección SQL en el sitio web de la Cámara de Comercio de China. Los datos filtrados se publicaron junto con la cooperación de Anonymous .
• El 2 de febrero de 2014, un grupo de hackers llamado @deletesec filtró 40.000 cuentas del sitio de AVS TV.
• El 21 de febrero de 2014, el foro de Gobernanza de EE. UU. tuvo un ataque que resultó en la exposición de 3215 cuentas.
• El 21 de febrero de 2014, un grupo de piratas informáticos llamado @deletesec pirateó Spirol International después de que amenazaron con arrestar a los piratas informáticos por informar sobre la vulnerabilidad de seguridad. Los detalles de 70.000 usuarios quedaron expuestos durante este conflicto.
• En octubre de 2015, se creía que se había utilizado un ataque de inyección SQL en los servidores de una empresa de telecomunicaciones británica, Talk Talk , robando los datos personales de millones de consumidores.

Referencias en la cultura de masas

• El inicio de sesión no autorizado en un sitio web a través de inyección SQL proporciona una pista narrativa para la novela The Vacant Seat de JK Rowling , publicada en 2012.
• Una caricatura de xkcd trata sobre un personaje llamado "Robert '); estudiantes DROP TABLE; -" que realiza una inyección SQL. Como resultado de esta caricatura, la inyección de SQL a veces se denomina de manera informal como 'Bobby Tables'.
• En 2014, una persona en Polonia cambió legalmente el nombre de su negocio a Dariusz Jakubowski x '; Usuarios de DROP TABLE; SELECT '1 con el propósito de entorpecer las operaciones de los bots de recolección de spam .

Artículos relacionados

• Inyección de código
• Secuencias de comandos entre sitios
• Proyecto Metasploit
• Proyecto de seguridad de aplicaciones web abiertas de OWASP
• Cadena de formato no controlado
• w3af
• seguridad de aplicaciones web
• entidad externa XML

Enlaces externos

• Base de conocimiento de inyección SQL , por Websec.
• Inyección Sql ciega - Ataque de expresiones regulares Inyección Sql ciega con Ataque de expresiones regulares
• Clasificación de amenazas WASC - Entrada de inyección SQL , por el Consorcio de seguridad de aplicaciones web.
• Por qué la inyección SQL no desaparecerá , por Stuart Thomas.
• Ataques de inyección SQL por ejemplo , por Steve Friedl
• Hoja de trucos para la prevención de inyección SQL , por OWASP.
• Tutorial de inyección SQL , por BTS.
• sqlmap: herramienta automática de inyección de SQL y toma de control de la base de datos
• Referencias de seguridad rápidas de SDL sobre la inyección de SQL por Bala Neerumalla.
• Servidor web de puerta trasera que usa MySQL SQL Injection Archivado el 2 de abril de 2013 en Internet Archive . Por Yuli Stremovsky
• Desfigurar sitio web con inyección SQL por sploitswiki
• Aplicación web de ataque con inyección SQL por Abhinav Sejpal