inyección SQL

Técnica de piratería informática

Una clasificación del vector de ataque de inyección SQL a partir de 2010

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 atacante). ^{[1] [2]} La inyección SQL debe explotar 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 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 hacerlos no disponibles de otro modo y convertirse en administradores del sistema. servidor de base de datos. Las bases de datos NoSQL orientadas a documentos también pueden verse afectadas por esta vulnerabilidad de seguridad. ^[3]

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. ^[4]

Historia

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

Forma

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 . ^[7] En 2013, SQLI fue calificado como el ataque número uno en el top ten de OWASP. ^[8] Hay cuatro subclases principales de inyección SQL:

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

• Inyección SQL + autenticación insuficiente ^[9]
• Inyección SQL + ataques DDoS ^[10]
• Inyección SQL + secuestro de DNS ^[11]
• Inyección SQL + XSS ^[12]

Storm Worm es una representación de SQLI compuesto. ^[13]

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

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 declaració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 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 simple, imagine que los datos ' susan' en la declaración anterior fueron proporcionados por entrada del usuario. El usuario ingresó la cadena ' susan' (sin los apóstrofes) en un campo de entrada de texto de un 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 construirá la declaración . Muchas bases de datos ignorarán el texto después de la cadena '--' ya que indica 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 logró crear una cadena de datos que sale del contexto de datos e ingresó a 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 cadenas:

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 diseña la variable "nombre de usuario" 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, configurando la variable "nombre de usuario" como:

' O '1'='1

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

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

representa una de las siguientes declaraciones SQL según el idioma principal:

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

SELECCIONE * DE 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 pretendía el codificador, porque la evaluación de '1'= '1' siempre es cierto.

El siguiente valor de "nombre de usuario" en la siguiente declaración provocaría la eliminación de la tabla "usuarios", así como la selección de todos los datos de la tabla "información de usuario" (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:

SELECCIONE * DE los usuarios DONDE nombre = 'a' ; Usuarios de DROP TABLE ; SELECCIONE * DE información de usuario 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 de PHPmysql_query() , no lo permiten por razones de seguridad. Esto evita que los atacantes inserten consultas completamente separadas, 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. ^[16] 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. ^[17]

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.

SELECCIONE * DE reseñas de libros DONDE ID = '5' ;       

a partir del 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 sólo ve que la URL anterior devuelve una reseña de un libro. Un hacker puede cargar las URL y , lo que puede generar consultashttps://books.example.com/review?id=5 OR 1=1https://books.example.com/review?id=5 AND 1=2

SELECCIONE * DE reseñas de libros DONDE ID = '5' O '1' = '1' ; SELECCIONE * DE reseñas de libros DONDE ID = '5' Y '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 otros casos En otras 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 se habrá realizado correctamente en ambos casos. 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: , 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. ^{[18] [19]}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 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. ^[20] Técnicas como la coincidencia de patrones, las pruebas de software y el análisis gramatical son algunas formas comunes de mitigar estos ataques. ^[2]

Escapando

La forma más sencilla de evitar inyecciones es 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 de cadena debe ir precedida de una barra invertida ( \) para que la base de datos entienda que la comilla simple es parte de una cadena determinada, en lugar de su terminador. PHP proporciona la mysqli_real_escape_string()función para escapar de cadenas según la semántica de MySQL ; el siguiente ejemplo parametriza una consulta SQL escapando de los parámetros de nombre de usuario y contraseña:

Depender del programador para escapar de todos los parámetros de consulta es propenso a errores, ya que es fácil olvidar escapar de una cadena determinada. Un programador puede optar por implementar sus propias abstracciones para escapar de dichos parámetros automáticamente, lo que puede reducir la susceptibilidad al error, si no eliminarlo por completo. ^[21]

Mapeadores relacionales de objetos

Los marcos de mapeo relacional de objetos (ORM), como Hibernate y ActiveRecord, proporcionan una interfaz orientada a objetos para consultas a través de una base de datos relacional. La mayoría de los ORM, si no todos, manejan automáticamente el escape necesario para evitar ataques de inyección SQL, como parte de la API de consulta del marco. Sin embargo, muchos ORM brindan la capacidad de omitir sus funciones de mapeo y emitir declaraciones SQL sin formato; El uso inadecuado de esta funcionalidad puede introducir la posibilidad de un ataque de inyección. ^[22]

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. ^[23]

Comprobació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.

Denegar selección en sys . objetos del sistema a webdatabaselogon ; Denegar selección en sys . objetos a webdatabaselogon ; Denegar selección en sys . tablas a webdatabaselogon ; Denegar selección en sys . vistas al inicio de sesión de la base de datos web ; Denegar selección en sys . paquetes para webdatabaselogon ;                         

Ejemplos

• En febrero de 2002, Jeremiah Jacks descubrió que Guess.com era vulnerable a un ataque de inyección SQL, lo que permitía a cualquier persona capaz de construir una URL correctamente diseñada para obtener 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. ^[24]
• El 1 de noviembre de 2005, un hacker adolescente utilizó inyección SQL para irrumpir en el sitio de una revista taiwanesa de seguridad informática del grupo Tech Target y robar información de los clientes. ^[25]
• 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. ^[26]
• El 19 de septiembre de 2007 y el 26 de enero de 2009, el grupo de piratas informáticos turco "m0sted" utilizó la inyección SQL para explotar el servidor SQL de Microsoft para piratear servidores web pertenecientes a la planta de municiones del ejército de McAlester y al cuerpo de ingenieros del ejército de EE. UU., respectivamente. ^[27]
• El 13 de abril de 2008, el Registro de Delincuentes Sexuales y Violentos de Oklahoma cerró su sitio web para " 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 mediante un ataque de inyección SQL ^[28].
• El 17 de agosto de 2009, el Departamento de Justicia de los Estados Unidos acusó a un ciudadano estadounidense, Albert González , y a dos rusos anónimos del robo de 130 millones de números de tarjetas de crédito mediante un ataque de inyección SQL. En lo que se dice es "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 . ^[29]
• En julio de 2010, un investigador de seguridad sudamericano que se hace llamar " Ch Russo" obtuvo información confidencial del usuario del popular sitio 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 del usuario, incluidas direcciones IP , hashes de contraseñas MD5 y registros de los torrents que los usuarios individuales habían subido. ^[30]
• 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 gestiona un gran supermercado 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. Hasta el 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 las elecciones generales suecas de 2010, un votante intentó una inyección de código escribiendo a mano comandos SQL como parte de una votación por escrito . ^[31]
• El 8 de noviembre de 2010, el sitio web de la Royal Navy británica fue comprometido por un hacker rumano llamado TinKode mediante inyección SQL. ^{[32] [33]}
• El 11 de abril de 2011, Barracuda Networks se vio comprometida mediante una falla de inyección SQL. Entre la información obtenida se encontraban direcciones de correo electrónico y nombres de usuarios de los empleados. ^[34]
• 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 activas y 90.000 cuentas antiguas o inactivas. ^{[35] [36] [37]}
• El 1 de junio de 2011, los " hacktivistas " del grupo LulzSec fueron acusados ​​de utilizar SQLI para robar cupones , claves de descarga y contraseñas almacenadas en texto plano en el sitio web de Sony , accediendo a la información personal de un millón de usuarios. ^[38]
• En junio de 2011, LulzSec pirateó PBS , muy 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. ^[39]
• 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 plano y supuestamente fueron tomados 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 ". ^{[40] [41]}
• El 1 de octubre de 2012, un grupo de hackers llamado "Team GhostShell" publicó en Pastebin los registros personales de estudiantes, profesores, empleados y ex alumnos de 53 universidades, incluidas Harvard , Princeton , Stanford , Cornell , Johns Hopkins y la Universidad de Zurich . 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 educativas en Europa y los aumentos de las matrículas en los Estados Unidos . ^[42]
• 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 en la Cámara de Comercio Internacional de China. Los datos filtrados se publicaron públicamente en cooperación con Anonymous . ^[43]
• En agosto de 2014, la empresa de seguridad informática Hold Security, 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. ^[44] El New York Times confirmó este hallazgo contratando a un experto en seguridad para verificar el reclamo. ^[45]
• 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 , explotando una vulnerabilidad en un portal web heredado. ^[46]
• 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 estándares inseguros de desinfección de datos por parte de Link, una nueva empresa fundada en el campus por el estudiante Ishan Gandhi. ^[47]
• A principios de 2021, se extrajeron 70 gigabytes de datos del sitio web de extrema derecha Gab mediante un ataque de inyección SQL. La vulnerabilidad fue introducida en el código base de Gab por Fosco Marotto, CTO de Gab . ^[48] ​​La semana siguiente se lanzó un segundo ataque contra Gab utilizando tokens OAuth2 robados durante el primer ataque. ^[49]

En la cultura popular

• Una caricatura de xkcd de 2007 involucró al personaje Robert'); DROP TABLE Estudiantes;-- nombrados para realizar una inyección SQL. Como resultado de esta caricatura, la inyección SQL a veces se denomina informalmente "Tablas Bobby". ^{[50] [51]}
• El inicio de sesión no autorizado en sitios web mediante inyección SQL constituye la base de una de las tramas secundarias de la novela de JK Rowling de 2012, The Casual Vacancy .
• En 2014, un individuo en Polonia cambió legalmente el nombre de su empresa 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 . ^[52]
• El juego Hacknet de 2015 tiene un programa de piratería llamado SQL_MemCorrupt. Se describe como inyectar una entrada de tabla que provoca un error de corrupción en una base de datos SQL, luego consulta dicha tabla, provocando un fallo de la base de datos SQL y un volcado de núcleo.

Ver también

• inyección de código
• secuencias de comandos entre sitios
• Proyecto Metasploit
• Proyecto de seguridad de aplicaciones web abiertas OWASP
• Inyección inmediata , un concepto similar aplicado a la inteligencia artificial
• entidad SGML
• Cadena de formato no controlado
• w3af
• Seguridad de aplicaciones web

Referencias

1. Microsoft. "Inyección SQL". Archivado desde el original el 2 de agosto de 2013 . Consultado el 4 de agosto de 2013 . La inyección SQL es un ataque en el que se inserta código malicioso en cadenas que luego se pasan a una instancia de SQL Server para su análisis y ejecución. Cualquier procedimiento que construya declaraciones SQL debe revisarse para detectar vulnerabilidades de inyección porque SQLi Server ejecutará todas las consultas sintácticamente válidas que reciba. Incluso los datos parametrizados pueden ser manipulados por un atacante hábil y decidido.
2. Zhuo, Z.; Cai, T.; Zhang, X.; Lv, F. (abril de 2021). "Memoria larga a corto plazo en un árbol de sintaxis abstracta para la detección de inyección SQL". Software IET . 15 (2): 188-197. doi :10.1049/sfw2.12018. ISSN  1751-8806. S2CID  233582569.
3. "Hackear NodeJS y MongoDB | Blog de Websecurify" . Consultado el 15 de noviembre de 2023 .
4. Imperva (julio de 2012). "Informe de ataques a aplicaciones web Imperva" (PDF) . Archivado desde el original (PDF) el 7 de septiembre de 2013 . Consultado el 4 de agosto de 2013 . Los minoristas sufren el doble de ataques de inyección SQL que otras industrias. / Si bien la mayoría de las aplicaciones web reciben 4 o más campañas de ataques web por mes, algunos sitios web están constantemente bajo ataque. / Un sitio web observado estuvo bajo ataque 176 de 180 días, o el 98% del tiempo.
5. Sean Michael Kerner (25 de noviembre de 2013). "¿Cómo se descubrió la inyección SQL? El investigador alguna vez conocido como Rain Forrest Puppy explica cómo descubrió la primera inyección SQL hace más de 15 años". Archivado desde el original el 18 de marzo de 2014 . Consultado el 15 de noviembre de 2023 .
6. Jeff Forristal (firmando como rain.forest.puppy) (25 de diciembre de 1998). "Vulnerabilidades de la tecnología web NT". Revista Phrack . 8 (54 (artículo 8)). Archivado desde el original el 19 de marzo de 2014.
7. "Categoría: Proyecto Top Ten de OWASP". OWASP. Archivado desde el original el 19 de mayo de 2011 . Consultado el 3 de junio de 2011 .
8. "Categoría: Proyecto Top Ten de OWASP". OWASP. Archivado desde el original el 9 de octubre de 2013 . Consultado el 13 de agosto de 2013 .
9. "WHID 2007-60: pirateado el blog de un equipo de seguridad de la Universidad de Cambridge". Xiom. Archivado desde el original el 19 de junio de 2011 . Consultado el 3 de junio de 2011 .
10. "WHID 2009-1: ciberguerra del conflicto de Gaza". Xiom. Archivado desde el original el 7 de octubre de 2011 . Consultado el 3 de junio de 2011 .
11. "Lista de incidentes de piratería web: secuestro de DNS". Xiom. Archivado desde el original el 18 de junio de 2009.
12. Bastón de lectura oscura (13 de mayo de 2008). "La tercera ola de ataques web no es la última". Lectura oscura . Informa . Consultado el 1 de enero de 2024 .
13. Danchev, Dancho (23 de enero de 2007). "Flujos mentales de conocimientos sobre seguridad de la información: ingeniería social y malware". Ddanchev.blogspot.com. Archivado desde el original el 21 de julio de 2011 . Consultado el 3 de junio de 2011 .
14. Deltchev, Krassen. "Nuevos ataques a la Web 2.0". Licenciatura en Ciencias. Tesis (en inglés y alemán). Universidad del Ruhr de Bochum. Archivado desde el original el 2 de abril de 2012 . Consultado el 18 de febrero de 2010 .
15. "Cómo ingresar comentarios SQL" (PDF) , Guía de IBM Informix para SQL: sintaxis , IBM, págs. 13-14, archivado desde el original (PDF) el 24 de febrero de 2021 , consultado el 4 de junio de 2018
16. "Extracción de varios bits por solicitud de vulnerabilidades de inyección SQL totalmente ciegas". Hackear todas las cosas. Archivado desde el original el 8 de julio de 2016 . Consultado el 8 de julio de 2016 .
17. "Uso de SQLBrute para forzar datos desde un punto de inyección SQL ciego". Justin Clarke. Archivado desde el original el 14 de junio de 2008 . Consultado el 18 de octubre de 2008 .
18. macd3v. "Tutorial de inyección SQL ciega". Archivado desde el original el 14 de diciembre de 2012 . Consultado el 6 de diciembre de 2012 .{{cite web}}: Mantenimiento CS1: nombres numéricos: lista de autores ( enlace )
19. Andréi Rasokhin; Dmitri Oleksyuk. "Botnet TDSS: divulgación completa". Archivado desde el original el 9 de diciembre de 2012 . Consultado el 6 de diciembre de 2012 .
20. "Preguntas para TalkTalk - BBC News". Noticias de la BBC . 26 de octubre de 2015. Archivado desde el original el 26 de octubre de 2015 . Consultado el 26 de octubre de 2015 .
21. "Capa de consulta transparente para MySQL". Roberto Eisele. 8 de noviembre de 2010. Archivado desde el original el 11 de noviembre de 2010.
22. "Prevención y ataques de inyección SQL: guía completa". appsecmonkey.com . 13 de febrero de 2021 . Consultado el 24 de febrero de 2021 .
23. "Hoja de referencia para la prevención de inyecciones SQL". Abra el proyecto de seguridad de aplicaciones web. Archivado desde el original el 20 de enero de 2012 . Consultado el 3 de marzo de 2012 .
24. "Las conjeturas plagan los informes sobre agujeros en la web". Enfoque de seguridad . 6 de marzo de 2002. Archivado desde el original el 9 de julio de 2012.
25. "WHID 2005-46: un adolescente utiliza la inyección SQL para acceder al sitio web de una revista de seguridad". Consorcio de seguridad de aplicaciones web. 1 de noviembre de 2005. Archivado desde el original el 17 de enero de 2010 . Consultado el 1 de diciembre de 2009 .
26. "WHID 2006-3: piratas informáticos rusos irrumpieron en un sitio web de RI GOV". Consorcio de seguridad de aplicaciones web. 13 de enero de 2006. Archivado desde el original el 13 de febrero de 2011 . Consultado el 16 de mayo de 2008 .
27. "Hackers antiestadounidenses se infiltran en los servidores del ejército". Semana de la Información . 29 de mayo de 2009. Archivado desde el original el 20 de diciembre de 2016 . Consultado el 17 de diciembre de 2016 .
28. Alex Papadimoulis (15 de abril de 2008). "Oklahoma filtra decenas de miles de números de seguridad social y otros datos confidenciales". El diario WTF . Archivado desde el original el 10 de mayo de 2008 . Consultado el 16 de mayo de 2008 .
29. "Un hombre estadounidense 'robó 130 millones de números de tarjetas'". BBC. 17 de agosto de 2009. Archivado desde el original el 18 de agosto de 2009 . Consultado el 17 de agosto de 2009 .
30. "El ataque a la bahía pirata". 7 de julio de 2010. Archivado desde el original el 24 de agosto de 2010.
31. "¿Little Bobby Tables emigró a Suecia?". Alicebobandmallory.com. Archivado desde el original el 1 de julio de 2012 . Consultado el 3 de junio de 2011 .
32. "Sitio web de la Royal Navy atacado por un hacker rumano". Noticias de la BBC. 8 de noviembre de 2010. Archivado desde el original el 9 de noviembre de 2010 . Consultado el 15 de noviembre de 2023 .
33. Sam Kiley (25 de noviembre de 2010). "El supervirus, un objetivo para los ciberterroristas". Archivado desde el original el 28 de noviembre de 2010 . Consultado el 25 de noviembre de 2010 .
34. "Hacker irrumpe en la base de datos de Barracuda Networks". Archivado desde el original el 27 de julio de 2011.
35. "información sobre intrusión de contraseña de usuario del sitio". Dslreports.com. Archivado desde el original el 18 de octubre de 2012 . Consultado el 3 de junio de 2011 .
36. "DSLReports dice que se robó información de los miembros". Noticias Cnet. 28 de abril de 2011. Archivado desde el original el 21 de marzo de 2012 . Consultado el 29 de abril de 2011 .
37. "La violación de DSLReports.com expuso más de 100.000 cuentas". El heraldo tecnológico. 29 de abril de 2011. Archivado desde el original el 30 de abril de 2011 . Consultado el 29 de abril de 2011 .
38. "LulzSec piratea Sony Pictures y revela 1 millón de contraseñas no protegidas", electronista.com , 2 de junio de 2011, archivado desde el original el 6 de junio de 2011 , consultado el 3 de junio de 2011
39. "Imperva.com: PBS pirateado: cómo probablemente lo hicieron los piratas informáticos". Archivado desde el original el 29 de junio de 2011 . Consultado el 1 de julio de 2011 .
40. Ngak, Chenda. "Según se informa, Yahoo fue pirateado: ¿Está segura su cuenta?". Noticias CBS . Archivado desde el original el 14 de julio de 2012 . Consultado el 16 de julio de 2012 .
41. Sí, Jamie (12 de julio de 2012). "Se filtraron 450.000 contraseñas de usuario en una infracción de Yahoo". ZDNet . Archivado desde el original el 2 de julio de 2014 . Consultado el 18 de febrero de 2017 .
42. Perlroth, Nicole (3 de octubre de 2012). "Los piratas informáticos violan 53 universidades y arrojan miles de registros personales en línea". New York Times . Archivado desde el original el 5 de octubre de 2012.
43. Kovacs, Eduard (4 de noviembre de 2013). "Los piratas informáticos filtran datos supuestamente robados del sitio web de la Cámara de Comercio de China". Noticias de Softpedia . Archivado desde el original el 2 de marzo de 2014 . Consultado el 27 de febrero de 2014 .
44. Damon poeta. Una banda de hackers rusos 'muy unida' atesora 1.200 millones de créditos de identificación Archivado el 14 de julio de 2017 en Wayback Machine , PC Magazine , 5 de agosto de 2014
45. Nicole Perlroth. Una banda rusa amasa más de mil millones de contraseñas de Internet Archivado el 27 de febrero de 2017 en Wayback Machine , The New York Times , 5 de agosto de 2014.
46. "TalkTalk recibe una multa récord de £ 400.000 por no evitar el ataque de octubre de 2015". 5 de octubre de 2016. Archivado desde el original el 24 de octubre de 2016 . Consultado el 23 de octubre de 2016 .
47. Catania, Sam (13 de agosto de 2020). "La vulnerabilidad en el sitio web 'Link' puede haber expuesto datos sobre los enamoramientos de los estudiantes de Stanford". El diario Stanfort . Consultado el 5 de septiembre de 2020 .
48. Goodin, Dan (2 de marzo de 2021). "El error de codificación del novato antes del hack de Gab provino del CTO del sitio". Ars Técnica .
49. Goodin, Dan (8 de marzo de 2021). "Gab, un paraíso para las teorías de conspiración pro-Trump, ha sido pirateado nuevamente". Ars Técnica .
50. Munroe, Randall. "XKCD: Las hazañas de una mamá". Archivado desde el original el 25 de febrero de 2013 . Consultado el 26 de febrero de 2013 .
51. "La guía de Bobby Tables para la inyección SQL". 15 de septiembre de 2009. Archivado desde el original el 7 de noviembre de 2017 . Consultado el 30 de octubre de 2017 .
52. "Jego firma ma w nazwie inyección SQL. Nie zazdrościmy tym, którzy będą go fakturowali;)". Niebezpiecznik (en polaco). 11 de septiembre de 2014. Archivado desde el original el 24 de septiembre de 2014 . Consultado el 26 de septiembre de 2014 .

enlaces externos

• Hojas de trucos de inyección SQL de OWASP, por OWASP.
• Clasificación de amenazas WASC: entrada de inyección SQL, realizada por el Consorcio de seguridad de aplicaciones web.
• Por qué la inyección SQL no desaparecerá Archivado el 9 de noviembre de 2012 en Wayback Machine , por Stuart Thomas.
• Referencias rápidas de seguridad de SDL sobre inyección SQL por Bala Neerumalla.
• Cómo funcionan los fallos de seguridad: inyección SQL