Inyección SQL

En informática, 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 agresor). 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 literales de cadena incrustados en declaraciones SQL o la entrada del usuario no está fuertemente tipada y se ejecuta inesperadamente. La inyección SQL se conoce principalmente como un vector de ataque para sitios web, pero puede usarse para atacar cualquier tipo de base de datos SQL.

Los ataques de inyección SQL permiten a los atacantes falsificar la identidad, alterar 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 hacerlos no disponibles de otro modo, y convertirse en administradores del servidor de base de datos. Las bases de datos NoSQL orientadas a documentos también pueden verse afectadas por esta vulnerabilidad de seguridad.

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

Historia

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

Formulario

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

• Classic SQLI
• Inyección SQL ciega o inferencia
• Sistema de gestión de bases de datos específico SQLI
• SQLI compuesto

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

Storm Worm es una representación de SQLI compuesto.

Esta clasificación representa el estado de SQLI, respetando su evolución hasta 2010; se están realizando mejoras adicionales.

Implementaciones técnicas

Declaraciones 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 select * de persona donde nombre = 'susan' y edad = 2 la cadena 'susan' son datos y el fragmento y edad = 2 es un ejemplo de un comando (el valor 2 también son datos en este ejemplo).

La inyección 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 e ingrese a un contexto de comando. Esto permite al atacante alterar la estructura de la declaración SQL que se ejecuta.

Como ejemplo sencillo, imagine que los datos 'susan' en la declaración anterior fue proporcionada por la entrada del usuario. El usuario ingresó la cadena 'susan< /código>' (sin los apóstrofos) en un campo de entrada de texto de un formulario web, y el programa utilizó declaraciones de concatenación de cadenas para formar la declaración SQL anterior a partir de los tres fragmentos select * de persona donde nombre=', la entrada del usuario de 'susan' y ' y edad = 2.

Ahora imagina que en lugar de ingresar 'susan< /span>' el atacante ingresó ' o 1=1; --.

El programa utilizará el mismo enfoque de concatenación de cadenas con los 3 fragmentos de seleccione * de persona dónde nombre=', la entrada del usuario de ' o 1=1; -- y ' y edad = 2 y construya la declaración select * de persona dónde nombre ='' o 1=1; -- y edad = 2. Muchas bases de datos ignorarán el texto después de '--' cadena ya que esto denota un comentario. La estructura del comando SQL ahora es select * de persona dónde nombre='&# 39; o 1=1; y esto seleccionará todas las filas de personas en lugar de solo aquellas llamadas 'susan' cuya edad es 2. El atacante logró crear una cadena de datos que sale del contexto de datos e ingresó a un contexto de comando.

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 cadenas:

var declaración = "SELECCIONAR * DE usuarios DONDE nombre = '" + nombre de usuario + "'";

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

O '1'=1

o usar comentarios para incluso bloquear el 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' / 

presenta una de las siguientes sentencias SQL según el idioma principal:

SELECT * DESDE usuarios Donde Nombre = ' ' O '1 '='1 ';

SELECT * DESDE usuarios Donde Nombre = ' ' O '1 '='1 ' - ';

Si este código fuera a usarse 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 codificador. intencionado, porque la evaluación de '1'='1' siempre es cierto.

El siguiente valor de "userName" en la siguiente declaración provocaría la eliminación de la cuenta de "usuarios" tabla, así como la selección de todos los datos de la tabla "userinfo" tabla (en esencia, revela 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 representa la declaración SQL final de la siguiente manera y se especifica:

SELECT * DESDE usuarios Donde Nombre = 'a';DROP CUADRO usuarios; SELECT * DESDE userinfo Donde 't ' = 't ';

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

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 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. Tradicionalmente, este tipo de ataque se ha considerado que consume mucho tiempo porque era necesario crear una nueva declaración para cada bit recuperado y, dependiendo de su estructura, el ataque puede consistir en muchas solicitudes fallidas. Los avances recientes han permitido que cada solicitud recupere varios 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 la pantalla de una 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 * DESDE bookreviews Donde ID = 5 ';

a partir del cual se rellenarí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 sólo ve que la URL anterior devuelve una reseña de un libro. Un hacker puede cargar las URL https< span class="p">://libros.ejemplo.com/ revisión?id=5 O 1=1< /code> y https://libros. ejemplo.com/revisión?id= 5 Y 1=2, lo que puede generar consultas

SELECT * DESDE bookreviews Donde ID = 5 ' O '1 '='1 ';SELECT * DESDE bookreviews Donde ID = 5 ' Y '1 '='2 ';

respectivamente. Si la reseña original se carga con el mensaje "1=1" Se devuelve una URL y una página en blanco o de error desde el comando "1=2" URL y la página devuelta no se ha creado para alertar al usuario de que la entrada no es válida o, en otras palabras, ha sido detectada 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. en ambos casos con éxito. El hacker 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: https://libros.ejemplo.com/revisión?id=5 Y subcadena(@@versión , 1, INSTR(@@versión , '.' ) - 1)=4, que mostraría la reseña del libro en un servidor que ejecuta MySQL 4 y, de lo contrario, una página en blanco o de error. El hacker puede continuar usando código dentro de 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.

Inyección SQL de segundo orden

La inyección SQL de segundo orden se produce 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 declaració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 declaración SQL almacenada. Este ataque requiere más conocimiento sobre 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 SQL y es posible que deban recibir instrucciones manuales sobre 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 sencillas. Después de un aparente ataque de inyección SQL en TalkTalk en 2015, la BBC informó que los expertos en seguridad quedaron atónitos de que una empresa tan grande fuera vulnerable a él.

Mapeadores relacionales de objetos

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

Firewalls de aplicaciones web

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

Declaraciones parametrizadas

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 enlace) en lugar de incorporar la entrada del usuario en la declaración. Un marcador de posición sólo puede almacenar un valor del tipo dado y no un fragmento de SQL arbitrario. Por lo tanto, la inyección SQL simplemente se trataría como un valor de parámetro extraño (y probablemente no válido). En muchos casos, la declaración SQL es fija y cada parámetro es un escalar, no una tabla. Luego, la entrada del usuario se asigna (vincula) a un parámetro.

Cumplimiento a nivel de codificación

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

Escapando

Una forma popular, aunque propensa a errores, de evitar 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 Forme un literal de cadena SQL válido. Por ejemplo, en PHP es habitual escapar de parámetros usando la función mysqli_real_escape_string(); antes de enviar la consulta SQL:

$mysqli = nuevo mysqli()Nombre del anfitrión ', 'db_username ', 'db_password ', 'db_name ');$query = sprintf()"SELECT * DESDE `Users` WHERE UserName='%s' Y Password='%s'", $mysqli-real_escape_string()Nombre de usuario), $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 normalmente se usa 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 usa 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 consultas de bases de datos, etc. Estos caracteres son comillas simples ('), comillas dobles ("), barra invertida () y NUL (el byte NULL).).
Pasar rutinariamente cadenas con escape a SQL es propenso a errores porque es fácil olvidarse de escapar de una cadena determinada. Crear una capa transparente para proteger la entrada puede reducir esta susceptibilidad al error, si no eliminarla por completo.

Verificación de patrón

Se pueden verificar los parámetros de cadena entera, flotante o booleana para determinar si su valor es una representación válida del tipo dado. Las cadenas que deben cumplir con un patrón o condición específica (por ejemplo, fechas, UUID, números de teléfono) también se pueden verificar para determinar si dicho patrón coincide.

Permisos de base de datos

Limitar los permisos de inicio de sesión de la base de datos utilizados por la aplicación web a solo lo necesario puede ayudar a reducir la efectividad de cualquier ataque de inyección SQL que aproveche cualquier error en la aplicación web.

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

Negar seleccionar on Sys.sysobjects a webdatabaselogon;Negar seleccionar on Sys.objetos a webdatabaselogon;Negar seleccionar on Sys.Cuadros a webdatabaselogon;Negar seleccionar on Sys.opiniones a webdatabaselogon;Negar seleccionar on Sys.paquetes a webdatabaselogon;

Ejemplos

• En febrero de 2002, Jeremiah Jacks descubrió que Guess.com era vulnerable a un ataque de inyección SQL, permitiendo a cualquiera capaz de construir una URL debidamente diseñada para eliminar 200.000 nombres más, números de tarjetas de crédito y fechas de caducidad en la base de datos de clientes del sitio.
• El 1 de noviembre de 2005, un hacker adolescente utilizó la inyección SQL para entrar en el sitio de una revista de seguridad de información taiwanesa del grupo Tech Target y robar la información de los clientes.
• On January 13, 2006, Russian computer criminals broke into a Rhode Island government website and allegedly stole credit card data from individuals who have done business online with state agencies.
• El 29 de marzo de 2006, un hacker descubrió un defecto de inyección SQL en un sitio oficial de turismo del gobierno indio.
• On June 29, 2007, a computer criminal defaced the Microsoft UK website using SQL injection. Sitio web del Reino Unido El Registro citó a un portavoz de Microsoft reconociendo el problema.
• El 19 de septiembre de 2007 y el 26 de enero de 2009 el grupo hacker turco "m0sted" utilizó la inyección SQL para explotar el SQL Server de Microsoft para hackear servidores web pertenecientes a McAlester Army Ammunition Plant y el Cuerpo de Ingenieros del Ejército de Estados Unidos, respectivamente.
• En enero de 2008, decenas de miles de PC fueron infectados por un ataque de inyección SQL automatizado que explotó una vulnerabilidad en el código de aplicación que utiliza Microsoft SQL Server como almacén de bases de datos.
• En julio de 2008, el sitio de Malasia de Kaspersky fue hackeado por el grupo de hacker "m0sted" usando inyección SQL.
• On April 13, 2008, the Sexual and Violent Offender Registry of Oklahoma shut down its website for "routine maintenance" after being informed that 10,597 Social Security numbers belonging to sex offenders had been downloaded via an SQL injection attack
• En mayo de 2008, una granja del servidor dentro de China utilizó consultas automatizadas al motor de búsqueda de Google para identificar sitios web del servidor SQL que eran vulnerables al ataque de una herramienta de inyección SQL automatizada.
• En 2008, al menos abril a agosto, un barrido de ataques comenzó a explotar las vulnerabilidades de inyección SQL del servidor web IIS de Microsoft y el servidor de bases 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. Una cadena HTML que hace referencia a un archivo JavaScript de malware se adjunta a cada valor. Cuando ese valor de base se muestra más adelante a un visitante del sitio web, el script intenta varios enfoques para obtener control sobre el sistema de visitantes. El número de páginas web explotadas se estima en 500.000.
• On August 17, 2009, the United States Department of Justice charged an American citizen, Albert Gonzalez, and two unnamed Russians with theft of 130 million credit card numbers using an SQL injection attack. In reportedly "the largest case of identity theft in American history", the man stole cards from a number of corporate victims after researching their payment processing systems. Entre las compañías golpeadas estaban el procesador de tarjetas de crédito Heartland Payment Systems, la cadena de tiendas de conveniencia 7-Eleven, y la cadena de supermercado Hannaford Brothers.
• En diciembre de 2009, un atacante violó una base de datos RockYou que contenía los nombres de usuario no cifrados y contraseñas de unos 32 millones de usuarios usando un ataque de inyección SQL.
• En julio de 2010, un investigador de seguridad sudamericano que pasa por la manija "Ch Russo" obtuvo información de usuarios sensibles del popular sitio BitTorrent La Bahía Pirata. Obtuvo acceso al panel de control administrativo del sitio y explotó una vulnerabilidad de inyección SQL que le permitió recopilar información de la cuenta de usuario, incluyendo direcciones IP, contraseñas MD5 y registros de los cuales los usuarios individuales torrents han subido.
• Del 24 al 26 de julio de 2010, los atacantes de Japón y China utilizaron una inyección SQL para obtener acceso a los datos de tarjetas de crédito de los clientes de Neo Beat, una empresa con sede en Osaka que administra un gran supermercado en línea. El ataque también afectó a siete socios comerciales, incluyendo cadenas de supermercados Izumiya Co, Maruetsu Inc, y Ryukyu Jusco Co. El robo de datos afectó a 12.191 clientes reportados. Al 14 de agosto de 2010 se informó de que había más de 300 casos de información de tarjetas de crédito que estaban siendo utilizados por terceros para comprar bienes y servicios en China.
• El 19 de septiembre, durante las elecciones generales suecas de 2010, un votante intentó una inyección de código escribiendo comandos SQL como parte de un voto escrito.
• El 8 de noviembre de 2010 el sitio web de British Royal Navy fue comprometido por un hacker rumano llamado TinKode usando inyección SQL.
• El 5 de febrero de 2011 HBGary, una firma de seguridad tecnológica, fue rota 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 oficial de MySQL, fue comprometida por un hacker usando inyección de SQL ciega
• El 11 de abril de 2011, Barracuda Networks se comprometió utilizando un defecto de inyección SQL. Las direcciones de correo electrónico y los nombres de usuario de los empleados estaban entre la información obtenida.
• Durante un período de 4 horas el 27 de abril de 2011, se produjo un ataque SQL automatizado en el sitio web Informes de banda ancha que pudo extraer el 8% de los pares de nombre de usuario/palabra: 8.000 cuentas aleatorias de las 9.000 cuentas activas y 90.000 cuentas viejas o inactivas.
• El 1 de junio de 2011, "hacktivists" del grupo LulzSec fue acusado de usar SQLI para robar cupones, claves de descarga y contraseñas que se almacenaban en texto claro en el sitio web de Sony, accediendo a la información personal de un millón de usuarios.
• En junio de 2011, PBS fue hackeado por LulzSec, probablemente mediante el uso de la inyección SQL; el proceso completo utilizado por los hackers para ejecutar las inyecciones SQL fue descrito en este blog de Imperva.
• En mayo de 2012, el sitio web Wurm Online, un juego en línea multijugador masivo, fue apagado desde una inyección SQL mientras el sitio estaba siendo actualizado.
• En julio de 2012 se informó que un grupo hacker había robado 450.000 credenciales de inicio de sesión de Yahoo!. The logins were stored in plain text and were allegedly taken from a Yahoo subdomain, Yahoo! Voces. El grupo violó la seguridad de Yahoo utilizando una "técnica de inyección SQL sin conexión".
• El 1 de octubre de 2012, un grupo de hacker llamado "Team GhostShell" publicó los registros personales de estudiantes, profesores, empleados y ex alumnos de 53 universidades, incluyendo Harvard, Princeton, Stanford, Cornell, Johns Hopkins y la Universidad de Zurich en pastebin.com. Los hackers afirmaron que estaban tratando de "concientizar a los cambios realizados en la educación de hoy", fomentando la modificación de las leyes educativas en Europa y el aumento de la matrícula en los Estados Unidos.
• En febrero de 2013, un grupo de hackers de Maldivas hackeó el sitio web "UN-Maldives" usando SQL Injection.
• El 27 de junio de 2013, el grupo de hackers "RedHack" violó el sitio Administración de Estambul. Afirmaron que, han sido capaces de borrar las deudas de la gente a las compañías de agua, gas, Internet, electricidad y teléfono. Además, publicaron el nombre de usuario administrador y la contraseña para que otros ciudadanos inicien sesión y despejen sus deudas temprano por la mañana. Ellos anunciaron las noticias de Twitter.
• On November 4, 2013, hacktivist group "RaptorSwag" allegedly compromised 71 Chinese government databases using an SQL injection attack on the Chinese Chamber of International Commerce. 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, el Foro de las Naciones Unidas para la Gobernanza de Internet había filtrado 3.215 detalles de la cuenta.
• On February 21, 2014, Hackers of a group called @deletesec hacked Spirol International after allegedly threatening to have the hackers arrested for reporting the security vulnerability. 70.000 datos del usuario fueron expuestos sobre este conflicto.
• El 7 de marzo de 2014, 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 hacktivist "RaptorSwag". Los hackers comprometieron detalles personales de 878 estudiantes y personal, publicando un comunicado de prensa y los datos filtrados en Internet.
• En agosto de 2014, la compañía de seguridad informática de Milwaukee Hold Security reveló que descubrió un robo de información confidencial de casi 420.000 sitios web a través de inyecciones SQL. El New York Times confirmó este hallazgo mediante la contratación de un experto en seguridad para comprobar la reclamación.
• En octubre de 2015, se utilizó un ataque de inyección SQL para robar los detalles personales de 156.959 clientes de los servidores de la empresa de telecomunicaciones británica TalkTalk, explotando una vulnerabilidad en un portal web legado.
• En agosto de 2020, un ataque de inyección SQL se utilizó para acceder a información sobre los intereses románticos de muchos estudiantes de Stanford, como resultado de estándares inseguros de saneamiento de datos por parte de Link, una start-up fundada en el campus por el pregrado Ishan Gandhi.
• A principios de 2021, 70 gigabytes de datos fueron exfiltrados del 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, CTO de Gab. Un segundo ataque contra Gab fue lanzado la próxima semana usando fichas OAuth2 robadas durante el primer ataque.

En la cultura popular

• A 2007 xkcd dibujos animados involucrados un personaje Robert'); DROP TABLE Estudiantes; nombrado para llevar a cabo una inyección SQL. Como resultado de este dibujo animado, la inyección SQL a veces se denomina informalmente "Bobby Tables".
• Acceso no autorizado a sitios web mediante inyección SQL forma la base de uno de los subplotos en la novela de J.K. Rowling 2012 Las vacaciones casuales.
• En 2014, un individuo en Polonia renombra legalmente su negocio a Dariusz Jakubowski x'; DROP TABLE users; SELECT '1 en un intento de interrumpir el funcionamiento de los robots de cosecha de spammers.
• El juego 2015 Hacknet tiene un programa de piratería llamado SQL_MemCorrupt. Se describe como la inyección de una entrada de tabla que causa un error de corrupción en una base de datos SQL, luego consultas dicha tabla, causando un fallo de la base de datos SQL y el vertedero central.