Inyección SQL - SQL injection

Parte de una serie sobre
Seguridad de información
Incidentes de seguridad de la información por categoría, año fiscal 2014.svg
Categorías de seguridad relacionadas
Amenazas
Defensas
Clasificación de los vectores de ataque de inyección SQL en 2010
Una clasificación de vector de ataque de inyección SQL a partir de 2010.

La inyección SQL es una técnica de inyección de código utilizada para atacar aplicaciones basadas en datos, en la que se insertan sentencias SQL maliciosas en un campo de entrada para su ejecución (por ejemplo, para volcar el contenido de la base de datos al atacante). La inyección SQL debe aprovechar una vulnerabilidad de seguridad en el software de una aplicación, por ejemplo, cuando la entrada del usuario se filtra incorrectamente para caracteres de escape literal de cadena incrustados en declaraciones SQL o la entrada del usuario no se escribe fuertemente y se ejecuta inesperadamente. La inyección SQL se conoce principalmente como un vector de ataque para sitios web, pero se puede usar para atacar cualquier tipo de base de datos SQL.

Los ataques de inyección SQL permiten a los atacantes falsificar la identidad, alterar los datos existentes , causar problemas de repudio, como anular transacciones o cambiar saldos, permitir la divulgación completa de todos los datos en el sistema, destruir los datos o hacer que no estén disponibles de otra manera, y convertirse en administradores del servidor de base de datos.

En un estudio de 2012, se observó que la aplicación web promedio recibió cuatro campañas de ataque por mes y los minoristas recibieron el doble de ataques que otras industrias.

Historia

Las primeras discusiones públicas sobre la inyección de SQL comenzaron a aparecer alrededor de 1998; por ejemplo, un artículo de 1998 en Phrack Magazine .

Formulario

La inyección de SQL (SQLI) fue considerada una de las 10 principales vulnerabilidades de aplicaciones web de 2007 y 2010 por Open Web Application Security Project . En 2013, SQLI fue calificado como el ataque número uno en el top ten de OWASP. Hay cuatro subclases principales de inyección SQL:

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

El Storm Worm es una representación de la agravan SQLI.

Esta clasificación representa el estado de SQLI, respetando su evolución hasta 2010; se están perfeccionando más.

Implementaciones técnicas

Sentencias SQL construidas incorrectamente

Esta forma de inyección se basa en el hecho de que las sentencias SQL constan tanto de datos utilizados por la sentencia SQL como de comandos que controlan cómo se ejecuta la sentencia SQL. Por ejemplo, en la instrucción SQL, la cadena " " son datos y el fragmento es un ejemplo de un comando (el valor también son datos en este ejemplo). select * from person where name = 'susan' and age = 2susanand age = 22

La inyección de SQL ocurre cuando el programa receptor procesa una entrada de usuario especialmente diseñada de una manera que permite que la entrada salga de un contexto de datos y entre en un contexto de comando. Esto permite al atacante alterar la estructura de la declaración SQL que se ejecuta.

Como ejemplo simple, imagine que los datos ' susan' en la declaración anterior fueron proporcionados por la entrada del usuario. El usuario ingresó la cadena ' susan' (sin los apóstrofos) en un campo de entrada de texto de formulario web, y el programa usó declaraciones de concatenación de cadenas para formar la declaración SQL anterior a partir de los tres fragmentos , la entrada del usuario de ' ' y . select * from person where name='susan' and age = 2

Ahora imagina que en lugar de entrar ' susan' entró el atacante . ' or 1=1; --

El programa utilizará el mismo enfoque de concatenación de cadenas con los 3 fragmentos de , la entrada del usuario de y y construirá la declaración . Muchas bases de datos ignorarán el texto después de la cadena '-' ya que esto denota un comentario. La estructura del comando SQL es ahora y esto seleccionará todas las filas de personas en lugar de solo aquellas llamadas 'susan' cuya edad es 2. El atacante ha logrado crear una cadena de datos que sale del contexto de datos y entró en un contexto de comando. select * from person where name='' or 1=1; --' and age = 2select * from person where name='' or 1=1; -- and age = 2select * from person where name='' or 1=1;

Ahora se presenta un ejemplo más complejo.

Imagine que un programa crea una declaración SQL utilizando el siguiente comando de asignación de cadena:

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

Este código SQL está diseñado para extraer los registros del nombre de usuario especificado de su tabla de usuarios. Sin embargo, si un usuario malintencionado crea la variable "userName" de una manera específica, la declaración SQL puede hacer más de lo que pretendía el autor del código. Por ejemplo, estableciendo la variable "userName" como: 

' OR '1'='1

o usar comentarios para bloquear el resto de la consulta (hay tres tipos de comentarios SQL). Las tres líneas tienen un espacio al final: 

' OR '1'='1' --
' OR '1'='1' {
' OR '1'='1' /*

renderiza una de las siguientes sentencias SQL por el idioma principal: 

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

SELECT * FROM users WHERE name = '' OR '1'='1' -- ';

Si este código se usara en el procedimiento de autenticación, entonces este ejemplo podría usarse para forzar la selección de cada campo de datos (*) de todos los usuarios en lugar de un nombre de usuario específico como pretendía el codificador, porque la evaluación de '1' = '1' siempre es cierto.

El siguiente valor de "userName" en la declaración a continuación provocaría la eliminación de la tabla "users", así como la selección de todos los datos de la tabla "userinfo" (en esencia, revelando la información de cada usuario), utilizando una API que permite múltiples declaraciones: 

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

Esta entrada muestra la declaración SQL final de la siguiente manera y se especifica: 

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

Si bien la mayoría de las implementaciones de servidor SQL permiten que se ejecuten múltiples declaraciones con una llamada de esta manera, algunas API de SQL, como la función de PHP , mysql_query()no lo permiten por razones de seguridad. Esto evita que los atacantes inyecten consultas completamente separadas, pero no les impide modificar las consultas.

Inyección SQL ciega

La inyección SQL ciega se utiliza cuando una aplicación web es vulnerable a una inyección SQL pero los resultados de la inyección no son visibles para el atacante. Es posible que la página con la vulnerabilidad no sea una que muestre datos, pero se mostrará de manera diferente dependiendo de los resultados de una declaración lógica inyectada en la declaración SQL legítima llamada para esa página. Este tipo de ataque se ha considerado tradicionalmente que requiere mucho tiempo porque es necesario crear una nueva declaración para cada bit recuperado y, según su estructura, el ataque puede consistir en muchas solicitudes fallidas. Los avances recientes han permitido que cada solicitud recupere múltiples bits, sin solicitudes fallidas, lo que permite una extracción más consistente y eficiente. Existen varias herramientas que pueden automatizar estos ataques una vez que se ha establecido la ubicación de la vulnerabilidad y la información del objetivo.

Respuestas condicionales

Un tipo de inyección SQL ciega obliga a la base de datos a evaluar una declaración lógica en una pantalla de aplicación normal. Por ejemplo, un sitio web de reseñas de libros utiliza una cadena de consulta para determinar qué reseña de libros mostrar. Entonces, la URL https://books.example.com/review?id=5 haría que el servidor ejecutara la consulta 

SELECT * FROM bookreviews WHERE ID = '5';

desde el cual llenaría la página de revisión con datos de la revisión con ID 5, almacenados en la tabla bookreviews. La consulta ocurre completamente en el servidor; el usuario no conoce los nombres de la base de datos, la tabla o los campos, ni conoce la cadena de consulta. El usuario solo ve que la URL anterior devuelve una reseña de un libro. Un pirata informático puede cargar las URL y , lo que puede generar consultas https://books.example.com/review?id=5 OR 1=1https://books.example.com/review?id=5 AND 1=2

SELECT * FROM bookreviews WHERE ID = '5' OR '1'='1';
SELECT * FROM bookreviews WHERE ID = '5' AND '1'='2';

respectivamente. Si la reseña original se carga con la URL "1 = 1" y se devuelve una página en blanco o de error desde la URL "1 = 2", y la página devuelta no se ha creado para alertar al usuario de que la entrada no es válida, o en otro palabras, ha sido detectado por un script de prueba de entrada, es probable que el sitio sea vulnerable a un ataque de inyección SQL, ya que la consulta probablemente habrá pasado con éxito en ambos casos. El pirata informático puede continuar con esta cadena de consulta diseñada para revelar el número de versión de MySQL que se ejecuta en el servidor:, que mostraría la reseña del libro en un servidor que ejecuta MySQL 4 y una página en blanco o de error en caso contrario. El pirata informático puede seguir utilizando código dentro de las cadenas de consulta para lograr su objetivo directamente o para obtener más información del servidor con la esperanza de descubrir otra vía de ataque. https://books.example.com/review?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 contienen comandos maliciosos que se almacenan en lugar de ejecutarse inmediatamente. En algunos casos, la aplicación puede codificar correctamente una instrucción SQL y almacenarla como SQL válido. Luego, otra parte de esa aplicación sin controles para protegerse contra la inyección de SQL podría ejecutar esa instrucción SQL almacenada. Este ataque requiere más conocimiento de cómo se utilizan posteriormente los valores enviados. Los escáneres de seguridad de aplicaciones web automatizados no detectarían fácilmente este tipo de inyección de SQL y es posible que deban ser instruidos manualmente dónde buscar evidencia de que se está intentando.

Mitigación

Una inyección SQL es un ataque bien conocido y se puede prevenir fácilmente con medidas simples. Después de un aparente ataque de inyección de SQL en TalkTalk en 2015, la BBC informó que los expertos en seguridad estaban sorprendidos de que una empresa tan grande fuera vulnerable a él.

Mapeadores relacionales de objetos

Los desarrolladores pueden usar marcos ORM como Hibernate para crear consultas de bases de datos de una manera segura y amigable para los desarrolladores. Dado que las consultas a la base de datos ya no se construyen como cadenas, no hay peligro de una vulnerabilidad de inyección.

Cortafuegos de aplicaciones web

Si bien los productos WAF como ModSecurity CRS no pueden evitar que las vulnerabilidades de inyección de SQL se introduzcan en una base de código, pueden hacer que el descubrimiento y la explotación sean significativamente más desafiantes para un atacante.

Detección

El filtrado de inyección SQL funciona de manera similar a los filtros de correo no deseado. Los cortafuegos de base de datos detectan inyecciones de SQL en función del número de consultas no válidas del host, la presencia de bloques OR y UNION dentro de la solicitud u otras características.

Declaraciones parametrizadas

Artículo principal: Declaración preparada

Con la mayoría de las plataformas de desarrollo, se pueden usar declaraciones parametrizadas que funcionan con parámetros (a veces llamadas marcadores de posición o variables de vinculación) en lugar de incrustar la entrada del usuario en la declaración. Un marcador de posición solo puede almacenar un valor del tipo dado y no un fragmento de SQL arbitrario. Por lo tanto, la inyección de SQL simplemente se trataría como un valor de parámetro extraño (y probablemente no válido). En muchos casos, la instrucción SQL es fija y cada parámetro es un escalar , no una tabla . A continuación, la entrada del usuario se asigna (enlaza) a un parámetro.

En pocas palabras, el uso de consultas parametrizadas definitivamente puede evitar la inyección de SQL. Esto significa principalmente que sus variables no son cadenas de consulta que acepten entradas SQL arbitrarias, sin embargo, algunos parámetros de tipos dados son definitivamente necesarios. Las consultas parametrizadas requieren que el desarrollador defina todo el código. Por lo tanto, sin consultas parametrizadas, cualquiera podría poner cualquier tipo de código SQL en el campo y borrar la base de datos. Pero si los parámetros se configuraran en '@nombre de usuario', la persona solo podría ingresar un nombre de usuario sin ningún tipo de código.

Ejecución a nivel de codificación

El uso de bibliotecas de mapeo relacional de objetos evita la necesidad de escribir código SQL. En efecto, la biblioteca ORM generará sentencias SQL parametrizadas a partir de código orientado a objetos.

Escapando

Una forma popular, aunque propensa a errores y finalmente condenada al fracaso, de prevenir las inyecciones es intentar escapar de todos los caracteres que tienen un significado especial en SQL. El manual de un DBMS SQL explica qué caracteres tienen un significado especial, lo que permite crear una lista negra completa de caracteres que necesitan traducción. Por ejemplo, cada aparición de una comilla simple ( ') en un parámetro debe reemplazarse por dos comillas simples ( '') para formar un literal de cadena SQL válido. Por ejemplo, en PHP es habitual escapar de los parámetros utilizando la función mysqli_real_escape_string();antes de enviar la consulta SQL: 

$mysqli = new mysqli('hostname', 'db_username', 'db_password', 'db_name');
$query = sprintf("SELECT * FROM `Users` WHERE UserName='%s' AND Password='%s'",
                  $mysqli->real_escape_string($username),
                  $mysqli->real_escape_string($password));
$mysqli->query($query);

Esta función antepone barras invertidas a los siguientes caracteres: \x00, \n, \r, \, ', "y \x1a. Esta función se utiliza normalmente para proteger los datos antes de enviar una consulta a MySQL .
PHP tiene funciones similares para otros sistemas de bases de datos como pg_escape_string () para PostgreSQL . La función addslashes(string $str)funciona para caracteres de escape y se utiliza especialmente para realizar consultas en bases de datos que no tienen funciones de escape en PHP. Devuelve una cadena con barras invertidas antes de los caracteres que deben escaparse en las consultas de la base de datos, etc. Estos caracteres son comillas simples ('), comillas dobles ("), barra invertida (\) y NUL (el byte NULL).
Pasar cadenas de escape de forma rutinaria a SQL es propenso a errores porque es fácil olvidarse de escapar de una cadena dada. Crear una capa transparente para asegurar la entrada puede reducir esta propensión a errores, si no eliminarla por completo.

Verificación de patrón

Los parámetros de cadena enteros, flotantes o booleanos se pueden verificar si su valor es una representación válida para el tipo dado. Las cadenas que deben seguir algún patrón estricto (fecha, UUID, solo alfanumérico, etc.) se pueden verificar si coinciden con este patrón.

Permisos de la base de datos

Limitar los permisos en el inicio de sesión de la base de datos que usa la aplicación web a solo lo que se necesita puede ayudar a reducir la efectividad de cualquier ataque de inyección SQL que explote cualquier error en la aplicación web.

Por ejemplo, en Microsoft SQL Server , un inicio de sesión en la base de datos podría estar restringido para seleccionar algunas de las tablas del sistema, lo que limitaría las vulnerabilidades que intentan insertar JavaScript en todas las columnas de texto de la base de datos. 

deny select on sys.sysobjects to webdatabaselogon;
deny select on sys.objects to webdatabaselogon;
deny select on sys.tables to webdatabaselogon;
deny select on sys.views to webdatabaselogon;
deny select on sys.packages to webdatabaselogon;

Ejemplos de

  • En febrero de 2002, Jeremiah Jacks descubrió que Guess.com era vulnerable a un ataque de inyección SQL, lo que permitía a cualquiera que pudiera construir una URL correctamente diseñada para extraer más de 200.000 nombres, números de tarjetas de crédito y fechas de vencimiento en la base de datos de clientes del sitio.
  • El 1 de noviembre de 2005, un pirata informático adolescente utilizó la inyección SQL para irrumpir en el sitio de una revista taiwanesa de seguridad de la información del grupo Tech Target y robar información de los clientes.
  • El 13 de enero de 2006, delincuentes informáticos rusos irrumpieron en un sitio web del gobierno de Rhode Island y supuestamente robaron datos de tarjetas de crédito de personas que habían hecho negocios en línea con agencias estatales.
  • El 29 de marzo de 2006, un hacker descubrió un fallo de inyección SQL en un funcionario de gobierno de la India 's turismo sitio.
  • El 29 de junio de 2007, un delincuente informático desfiguró el sitio web de Microsoft Reino Unido mediante inyección SQL. El sitio web británico The Register citó a un portavoz de Microsoft reconociendo el problema.
  • El 19 de septiembre de 2007 y el 26 de enero de 2009, el grupo de hackers turco "m0sted" utilizó la inyección SQL para explotar el servidor SQL de Microsoft para piratear servidores web pertenecientes a McAlester Army Ammunition Plant y al US Army Corps of Engineers respectivamente.
  • En enero de 2008, decenas de miles de PC fueron infectadas por un ataque de inyección SQL automatizado que aprovechó una vulnerabilidad en el código de la aplicación que usa Microsoft SQL Server como el almacén de la base de datos.
  • En julio de 2008, el sitio de Kaspersky en Malasia fue pirateado por el grupo de piratas informáticos "m0sted" mediante inyección SQL.
  • El 13 de abril de 2008, el Registro de Delincuentes Sexuales y Violentos de Oklahoma cerró su sitio web para el " mantenimiento de rutina " después de ser informado de que se habían descargado 10,597 números de Seguro Social pertenecientes a delincuentes sexuales a través de un ataque de inyección SQL.
  • En mayo de 2008, una granja de servidores en China utilizó consultas automatizadas al motor de búsqueda de Google para identificar sitios web de servidores SQL que eran vulnerables al ataque de una herramienta de inyección SQL automatizada.
  • En 2008, al menos de abril a agosto, una serie de ataques comenzaron a explotar las vulnerabilidades de inyección SQL del servidor web IIS de Microsoft y el servidor de base de datos SQL Server . El ataque no requiere adivinar el nombre de una tabla o columna y corrompe todas las columnas de texto en todas las tablas en una sola solicitud. A cada valor se le agrega una cadena HTML que hace referencia a un archivo JavaScript de malware . Cuando ese valor de la base de datos se muestra más tarde a un visitante del sitio web, el script intenta varios enfoques para obtener el control sobre el sistema de un visitante. El número de páginas web explotadas se estima en 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 no identificados por el robo de 130 millones de números de tarjetas de crédito mediante un ataque de inyección SQL. Según se informa, en "el mayor caso de robo de identidad en la historia de Estados Unidos", el hombre robó tarjetas de varias víctimas corporativas después de investigar sus sistemas de procesamiento de pagos . Entre las empresas afectadas se encuentran el procesador de tarjetas de crédito Heartland Payment Systems , la cadena de tiendas de conveniencia 7-Eleven y la cadena de supermercados Hannaford Brothers .
  • En diciembre de 2009, un atacante violó una base de datos de texto sin formato de RockYou que contenía los nombres de usuario y contraseñas sin cifrar de unos 32 millones de usuarios mediante un ataque de inyección SQL.
  • En julio de 2010, un investigador de seguridad sudamericano que se hace llamar "Ch Russo" obtuvo información confidencial del usuario del popular sitio de BitTorrent The Pirate Bay . Obtuvo acceso al panel de control administrativo del sitio y aprovechó una vulnerabilidad de inyección SQL que le permitió recopilar información de la cuenta de usuario, incluidas direcciones IP , hashes de contraseña MD5 y registros de los torrents que los usuarios individuales han subido.
  • Del 24 al 26 de julio de 2010, atacantes de Japón y China utilizaron una 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 un gran sitio de supermercados en línea. El ataque también afectó a siete socios comerciales, incluidas las cadenas de supermercados Izumiya Co, Maruetsu Inc y Ryukyu Jusco Co. El robo de datos afectó a 12.191 clientes. Al 14 de agosto de 2010, se informó que ha habido más de 300 casos de información de tarjetas de crédito utilizada por terceros para comprar bienes y servicios en China.
  • El 19 de septiembre, durante la elección general sueca 2010 un votante intentó una inyección de código SQL mediante comandos de escritura a mano como parte de una escritura en la votación.
  • El 8 de noviembre de 2010, el sitio web de la Royal Navy británica fue comprometido por un hacker rumano llamado TinKode usando inyección SQL.
  • El 5 de febrero de 2011, HBGary , una empresa de seguridad tecnológica, fue asaltada por LulzSec usando una inyección SQL en su sitio web impulsado por CMS.
  • El 27 de marzo de 2011, www.mysql.com, la página de inicio oficial de MySQL , fue comprometida por un pirata informático que usaba la inyección ciega de SQL.
  • El 11 de abril de 2011, Barracuda Networks se vio comprometida mediante una falla de inyección SQL. Entre la información obtenida se encuentran 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, se produjo un ataque de inyección SQL automatizado en el sitio web de Broadband Reports que pudo extraer el 8% de los pares de nombre de usuario / contraseña: 8,000 cuentas aleatorias de las 9,000 cuentas activas y 90,000 antiguas o inactivas.
  • El 1 de junio de 2011, " hacktivistas " del grupo LulzSec fueron acusados ​​de utilizar SQLI para robar cupones , descargar claves y contraseñas que estaban almacenadas en texto plano en el sitio web de Sony , accediendo a la información personal de un millón de usuarios.
  • En junio de 2011, PBS fue pirateado por LulzSec, probablemente mediante el uso de inyección SQL; El proceso completo utilizado por los piratas informáticos para ejecutar inyecciones SQL se describió en este blog de Imperva .
  • En mayo de 2012, el sitio web de Wurm Online , un juego en línea multijugador masivo , se cerró debido a una inyección SQL mientras se actualizaba el sitio.
  • En julio de 2012 , se informó que un grupo de piratas informáticos había robado 450.000 credenciales de inicio de sesión de Yahoo! . Los inicios de sesión se almacenaron en texto sin formato y supuestamente se tomaron de un subdominio de Yahoo , Yahoo! Voces . El grupo violó la seguridad de Yahoo utilizando una " técnica de inyección SQL basada en sindicatos ".
  • El 1 de octubre de 2012, un grupo de piratas informáticos llamado "Team GhostShell" publicó los registros personales de estudiantes, profesores, empleados y ex alumnos de 53 universidades, incluidas Harvard , Princeton , Stanford , Cornell , Johns Hopkins y la Universidad de Zúrich en pastebin. com . Los piratas informáticos afirmaron que estaban tratando de "crear conciencia sobre los cambios realizados en la educación actual", lamentando los cambios en las leyes de educación en Europa y los aumentos en la matrícula en los Estados Unidos .
  • En febrero de 2013, un grupo de piratas informáticos de Maldivas pirateó el sitio web "ONU-Maldivas" utilizando SQL Injection.
  • El 27 de junio de 2013, el grupo de hackers " RedHack " violó el sitio de administración de Estambul. Afirmaron que han podido borrar las deudas de las personas con las empresas de agua, gas, Internet, electricidad y telefonía. Además, publicaron el nombre de usuario de administrador y la contraseña para que otros ciudadanos inicien sesión y cancelen sus deudas temprano en la mañana. Anunciaron la noticia desde Twitter.
  • El 4 de noviembre de 2013, el grupo hacktivista "RaptorSwag" supuestamente comprometió 71 bases de datos del gobierno chino mediante un ataque de inyección SQL contra la Cámara de Comercio Internacional de China. Los datos filtrados se publicaron públicamente en cooperación con Anonymous .
  • El 2 de febrero de 2014, AVS TV tenía 40.000 cuentas filtradas por un grupo de piratería llamado @deletesec.
  • El 21 de febrero de 2014, en el Foro de Gobernanza de Internet de las Naciones Unidas se filtraron 3.215 detalles de cuentas.
  • El 21 de febrero de 2014, los piratas informáticos de un grupo llamado @deletesec piratearon Spirol International después de supuestamente amenazar con arrestar a los piratas informáticos por informar sobre la vulnerabilidad de seguridad. Se expusieron 70.000 detalles de usuarios sobre este conflicto.
  • El 7 de marzo de 2014, los funcionarios de la Universidad Johns Hopkins anunciaron públicamente que sus servidores de ingeniería biomédica habían sido víctimas de un ataque de inyección SQL llevado a cabo por un hacker anónimo llamado "Hooky" y alineado con el grupo hacktivista "RaptorSwag". Los piratas informáticos comprometieron los datos personales de 878 estudiantes y personal, publicando un comunicado de prensa y los datos filtrados en Internet.
  • En agosto de 2014, Hold Security, empresa de seguridad informática con sede en Milwaukee , reveló que había descubierto un robo de información confidencial de casi 420.000 sitios web mediante inyecciones de SQL. The New York Times confirmó este hallazgo contratando a un experto en seguridad para verificar el reclamo.
  • En octubre de 2015, se utilizó un ataque de inyección SQL para robar los datos personales de 156.959 clientes de los servidores de la empresa británica de telecomunicaciones TalkTalk , aprovechando una vulnerabilidad en un portal web heredado.
  • En agosto de 2020, se utilizó un ataque de inyección SQL para acceder a información sobre los intereses románticos de muchos estudiantes de Stanford , como resultado de los estándares de desinfección de datos inseguros por parte de Link, una empresa nueva fundada en el campus por el estudiante Ishan Gandhi.
  • A principios de 2021, 70 gigabytes de datos se exfiltraron desde el sitio web de extrema derecha Gab a través de un ataque de inyección SQL. La vulnerabilidad fue introducida en la base de código de Gab por Fosco Marotto, el CTO de Gab . Se lanzó un segundo ataque contra Gab la semana siguiente utilizando tokens OAuth2 robados durante el primer ataque.

En la cultura popular

  • El inicio de sesión no autorizado en sitios web mediante inyección SQL constituye la base de una de las subtramas de la novela de 2012 de JK Rowling , The Casual Vacancy .
  • Una caricatura de xkcd de 2007 involucraba a un personaje de Robert '); Estudiantes de DROP TABLE; - nombrado para realizar una inyección SQL. Como resultado de esta caricatura, la inyección de SQL a veces se conoce informalmente como "Tablas de Bobby".
  • En 2014, un individuo en Polonia renombró legalmente su negocio a Dariusz Jakubowski x '; Usuarios de DROP TABLE; SELECT '1 en un intento de interrumpir el funcionamiento de los robots de recolección de spammers .
  • El juego de 2015 Hacknet tiene un programa de piratería llamado SQL_MemCorrupt. Se describe como inyectar una entrada de tabla que causa un error de corrupción en una base de datos SQL, luego consulta dicha tabla, provocando un bloqueo de la base de datos SQL y un volcado del núcleo.
  • En el 2019 Star Trek: Descubrimiento episodio si la memoria no sirve comandante Airiam descubrió que una sonda que atacó a un almacén de datos en uno de lanzadera de la nave había hecho una serie de inyecciones SQL, pero que no podía encontrar ningún archivo comprometidos.

Ver también

Referencias

enlaces externos