Hispanopedia Wiki
Articulo de referencia

Inyección SQL

Clasificación de los vectores 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 aplicacio...

Hispanopedia WikiContenido en espanolLectura gratuita

Clasificación de los vectores de ataque de inyección SQL en 2010
Clasificación de los vectores 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 sentencias SQL o cuando la entrada del usuario no está fuertemente tipada y se ejecuta inesperadamente. La inyección SQL es conocida principalmente como un vector de ataque para sitios web, pero puede utilizarse para atacar cualquier tipo de base de datos SQL .

Los ataques de inyección SQL permiten a los atacantes suplantar identidades, manipular datos existentes , provocar problemas de repudio, como la anulación de transacciones o la modificación de saldos, obtener acceso completo a todos los datos del sistema, destruirlos o impedir su acceso, y convertirse en administradores del servidor de la base de datos. Las bases de datos NoSQL orientadas a documentos también pueden verse afectadas por esta vulnerabilidad de seguridad. [ 3 ]

La inyección SQL sigue siendo un riesgo de seguridad ampliamente reconocido debido a su potencial para comprometer datos confidenciales. El Proyecto Abierto de Seguridad de Aplicaciones Web (OWASP) la describe como una vulnerabilidad que se produce cuando las aplicaciones construyen consultas de base de datos utilizando datos de usuario no validados. Al explotar esta vulnerabilidad, los atacantes pueden ejecutar comandos de base de datos no deseados, lo que podría permitir el acceso, la modificación o la eliminación de datos. OWASP describe varias estrategias de mitigación, como sentencias preparadas , procedimientos almacenados y validación de entrada , para evitar que los datos de usuario se interpreten erróneamente como código SQL ejecutable. [ 4 ]

Historia

Las discusiones sobre la inyección SQL comenzaron a finales de la década de 1990, incluyendo un artículo de 1998 en la revista Phrack . [ 5 ] La inyección SQL fue clasificada entre las 10 principales vulnerabilidades de aplicaciones web de 2007 y 2010 por el Open Web Application Security Project (OWASP). [ 6 ] En 2013, la inyección SQL fue catalogada como la vulnerabilidad de aplicación web más crítica en el Top 10 de OWASP. [ 7 ]

En 2017, el OWASP Top 10 Application Security Risks agrupó la inyección SQL dentro de la categoría más amplia de "Inyección", clasificándola como la tercera amenaza de seguridad más crítica. Esta categoría incluía varios tipos de ataques de inyección, como SQL, NoSQL , comandos del sistema operativo e inyección LDAP . Estas vulnerabilidades surgen cuando una aplicación procesa datos no confiables como parte de un comando o consulta, lo que potencialmente permite a los atacantes ejecutar acciones no deseadas u obtener acceso no autorizado a los datos. [ 8 ]

Para 2021, la inyección seguía siendo un problema generalizado, detectado en el 94 % de las aplicaciones analizadas, con tasas de incidencia reportadas que alcanzaban hasta el 19 %. El OWASP Top 10 de ese año amplió aún más la definición de vulnerabilidades de inyección para incluir ataques dirigidos a sistemas de mapeo objeto-relacional (ORM), lenguaje de expresiones (EL) y biblioteca de navegación de grafos de objetos (OGNL). Para abordar estos riesgos, OWASP recomienda estrategias como el uso de API seguras , consultas parametrizadas, validación de entrada y escape de caracteres especiales para evitar que se ejecuten datos maliciosos como parte de una consulta. [ 9 ] [ 10 ]

Causa principal

La inyección SQL es una vulnerabilidad de seguridad común que surge al permitir que los datos proporcionados por el atacante se conviertan en código SQL. Esto ocurre cuando los programadores ensamblan consultas SQL mediante interpolación de cadenas o concatenando comandos SQL con datos proporcionados por el usuario. Por lo tanto, la 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 su ejecución. Por ejemplo, en la sentencia SQL, la cadena ' ' es un dato y el fragmento es un ejemplo de un comando (el valor también es un dato en este ejemplo). [ 11 ]select*frompersonwherename='susan'andage=2susanandage=22

La inyección SQL se produce cuando un programa receptor procesa una entrada de usuario especialmente diseñada, permitiendo que dicha entrada salga de un contexto de datos y entre en un contexto de comandos. Esto permite al atacante alterar la estructura de la sentencia SQL que se ejecuta.

Como ejemplo sencillo, imaginemos que los datos ' susan' en la instrucción anterior fueron proporcionados por el usuario. El usuario ingresó la cadena ' susan' (sin los apóstrofes) en un campo de texto de un formulario web, y el programa utilizó instrucciones de concatenación de cadenas para formar la instrucción SQL anterior a partir de los tres fragmentos '', la entrada del usuario ' ' y ' '. [ 11 ]select*frompersonwherename='susan'andage=2

Ahora imagina que en lugar de ingresar ' susan' el atacante ingresó . [ 11 ]'or1=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 instrucció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 ahora es 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 entra en un contexto de comando. [ 11 ]select*frompersonwherename=''or1=1;--'andage=2select*frompersonwherename=''or1=1;--' and age = 2select*frompersonwherename=''or1=1;

Formas de explotar

Si bien la causa fundamental de todas las inyecciones SQL es la misma, existen diferentes técnicas para explotarlas. Algunas de ellas se describen a continuación:

Obtener resultados o acciones directas

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

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

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

' O '1'='1

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

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

Genera una de las siguientes sentencias SQL mediante el lenguaje padre:

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

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

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

a';DROPTABLEusers;SELECT*FROMuserinfoWHERE't'='t

Esta entrada genera la instrucción SQL final de la siguiente manera y especificada:

SELECCIONAR * DE users DONDE name = 'a' ; ELIMINAR TABLA users ; SELECCIONAR * DE userinfo DONDE 't' = 't' ;

Si bien la mayoría de las implementaciones de SQL Server permiten ejecutar varias sentencias con una sola llamada, algunas API de SQL, como la función de PHPmysql_query() , no lo permiten por motivos de seguridad. Esto impide que los atacantes inyecten consultas completamente independientes, pero no les impide modificar las consultas existentes.

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. La página con la vulnerabilidad puede no ser una que muestre datos, pero se mostrará de forma diferente según los resultados de una instrucción lógica inyectada en la instrucción SQL legítima que se llama para esa página. Este tipo de ataque se ha considerado tradicionalmente lento porque se necesitaba crear una nueva instrucció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 múltiples bits, sin solicitudes fallidas, lo que permite una extracción más consistente y eficiente. [ 13 ] Existen varias herramientas que pueden automatizar estos ataques una vez que se ha establecido la ubicación de la vulnerabilidad y la información objetivo. [ 14 ]

Respuestas condicionales

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

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

a partir de lo cual se rellenaría la página de reseñas con datos de la reseña con ID 5, almacenada en la tabla bookreviews. La consulta se realiza completamente en el servidor; el usuario no conoce los nombres de la base de datos, la tabla o los campos, ni tampoco la cadena de consulta. El usuario solo ve que la URL anterior devuelve una reseña de libro. Un hacker puede cargar las URL y , lo que puede dar lugar a consultashttps://books.example.com/review?id=5' OR '1'='1https://books.example.com/review?id=5' AND '1'='2

SELECCIONAR * DE reseñasdelibros DONDE ID = '5' O '1' = '1' ; SELECCIONAR * DE reseñasdelibros 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 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 es probable que la consulta se haya ejecutado 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: , lo 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 hacker 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. [ 15 ] [ 16 ]https://books.example.com/review?id=5ANDsubstring(@@version,1,INSTR(@@version,'.')-1)=4

Inyección SQL de segundo orden

La inyección SQL de segundo orden se produce cuando una aplicación solo protege su SQL contra la entrada inmediata del usuario, pero tiene una política menos estricta al tratar con datos ya almacenados en el sistema. Por lo tanto, aunque dicha aplicación logre procesar y almacenar la entrada del usuario de forma segura, también almacenará la instrucción SQL maliciosa. Posteriormente, cuando otra parte de la aplicación utilice esos datos en una consulta que no esté protegida contra la inyección SQL, esta instrucción maliciosa podría ejecutarse. Este ataque requiere un conocimiento más profundo de cómo se utilizan posteriormente los valores enviados. Los escáneres de seguridad automatizados para aplicaciones web no detectarían fácilmente este tipo de inyección SQL y podrían necesitar instrucciones manuales para buscar indicios de que se está intentando.

Para protegerse de este tipo de ataques, todo el procesamiento SQL debe ser uniformemente seguro, independientemente del origen de los datos.

Mitigación de inyección SQL

La inyección SQL es un ataque conocido que puede mitigarse con medidas de seguridad establecidas. Sin embargo, un ciberataque de 2015 contra la empresa británica de telecomunicaciones TalkTalk explotó una vulnerabilidad de inyección SQL, comprometiendo los datos personales de aproximadamente 400 000 clientes. La BBC informó que los expertos en seguridad expresaron su sorpresa de que una empresa tan importante siguiera siendo vulnerable a tal ataque. [ 17 ]

Existen diversas medidas defensivas para mitigar los riesgos de inyección SQL, impidiendo que los atacantes inyecten código SQL malicioso en las consultas de la base de datos. Las estrategias de mitigación principales, según lo descrito por OWASP , incluyen consultas parametrizadas, validación de entrada y controles de acceso de mínimo privilegio, que limitan la capacidad de la entrada del usuario para alterar las consultas SQL y ejecutar comandos no deseados. [ 4 ] Además de las medidas preventivas, las técnicas de detección ayudan a identificar posibles intentos de inyección SQL. Métodos como la coincidencia de patrones , las pruebas de software y el análisis gramatical examinan las estructuras de las consultas y las entradas del usuario para detectar irregularidades que puedan indicar un intento de inyección. [ 2 ]

Mitigación fundamental

Declaraciones parametrizadas

La mayoría de las plataformas de desarrollo admiten sentencias parametrizadas, también conocidas como marcadores de posición o variables de enlace , para gestionar de forma segura la entrada del usuario en lugar de incrustarla en consultas SQL. Estos marcadores de posición almacenan únicamente valores de un tipo definido, lo que impide que la entrada altere la estructura de la consulta. Como resultado, los intentos de inyección SQL se procesan como entrada inesperada en lugar de código ejecutable. Con las consultas parametrizadas, el código SQL permanece separado de la entrada del usuario, y cada parámetro se pasa como un valor distinto, lo que impide que se interprete como parte de la sentencia SQL. [ 4 ]

Validación de entrada de la lista permitida

La validación de entrada mediante listas de permitidos garantiza que solo se acepten entradas definidas explícitamente, lo que reduce el riesgo de ataques de inyección. A diferencia de las listas de denegación , que intentan bloquear patrones maliciosos conocidos pero pueden eludirse, las listas de permitidos especifican entradas válidas y rechazan todo lo demás. Este enfoque es particularmente eficaz para datos estructurados , como fechas y direcciones de correo electrónico, donde se pueden aplicar reglas de validación estrictas. Si bien la validación de entrada por sí sola no previene la inyección SQL ni otros ataques, puede actuar como una salvaguarda adicional al identificar y filtrar entradas no autorizadas antes de que lleguen a una consulta SQL. [ 4 ] [ 18 ]

Menor privilegio

Según OWASP, el principio de mínimo privilegio ayuda a mitigar los riesgos de inyección SQL al garantizar que las cuentas de la base de datos tengan solo los permisos mínimos necesarios. Las cuentas de solo lectura no deben tener privilegios de modificación, y las cuentas de aplicación nunca deben tener acceso administrativo. Restringir los permisos de la base de datos es una parte fundamental de este enfoque, ya que limitar el acceso a las tablas del sistema y restringir los roles de usuario puede reducir el riesgo de ataques de inyección SQL. Separar a los usuarios de la base de datos para diferentes funciones, como la autenticación y la modificación de datos, limita aún más el daño potencial de los ataques de inyección SQL. [ 4 ]

Restringir los permisos de la base de datos en el inicio de sesión de la aplicación web reduce aún más el impacto de las vulnerabilidades de inyección SQL. Asegurarse de que las cuentas tengan solo el acceso necesario, como restringir los permisos SELECT en tablas críticas del sistema, puede mitigar posibles ataques.

En Microsoft SQL Server , limitar el acceso SELECT a las tablas del sistema puede prevenir ataques de inyección SQL que intentan modificar el esquema de la base de datos o inyectar scripts maliciosos. Por ejemplo, los siguientes permisos restringen el acceso de un usuario de la base de datos a los objetos del sistema:

denegar la selección en sys.sysobjects a webdatabaselogon ; denegar la selección en sys.objects a webdatabaselogon ; denegar la selección en sys.tables a webdatabaselogon ; denegar la selección en sys.views a webdatabaselogon ; denegar la selección en sys.packages a webdatabaselogon ;​​​​​

Mitigación suplementaria

mapeadores objeto-relacionales

Los marcos de mapeo objeto-relacional (ORM) proporcionan una interfaz orientada a objetos para interactuar con bases de datos relacionales . Si bien los ORM suelen ofrecer protecciones integradas contra la inyección SQL, aún pueden ser vulnerables si no se implementan correctamente. Algunas consultas generadas por ORM pueden permitir entradas no sanitizadas, lo que conlleva riesgos de inyección. Además, muchos ORM permiten a los desarrolladores ejecutar consultas SQL sin procesar, lo que, si no se maneja adecuadamente, puede introducir vulnerabilidades de inyección SQL. [ 19 ] [ 20 ]

Enfoques obsoletos/secundarios

El escape de cadenas generalmente se desaconseja como defensa principal contra la inyección SQL. OWASP describe este enfoque como "débil en comparación con otras defensas" y señala que puede no ser efectivo en todas las situaciones. En cambio, OWASP recomienda usar "consultas parametrizadas, procedimientos almacenados o algún tipo de mapeador objeto-relacional (ORM) que construya las consultas automáticamente" como métodos más confiables para mitigar los riesgos de inyección SQL. [ 4 ]

Escape de cadenas

Una de las formas tradicionales de prevenir inyecciones es agregar cada dato como una cadena entre comillas y escapar todos los caracteres que tienen un significado especial en las cadenas SQL. [ 21 ] El manual de un SGBD 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 dada, en lugar de su terminador. El módulo MySQLi de PHP proporciona la función para escapar cadenas según la semántica de MySQL ; en el siguiente ejemplo, el nombre de usuario es un parámetro de cadena y, por lo tanto, se puede proteger mediante el escape de cadenas:'\mysqli_real_escape_string()

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

Además, no todos los datos se pueden agregar a SQL como una cadena literal (los argumentos de la cláusula LIMIT de MySQL [ 22 ] o los nombres de tablas/columnas [ 23 ] , por ejemplo) y en este caso escapar los caracteres especiales relacionados con cadenas no servirá de nada, dejando el SQL resultante abierto a inyecciones.

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 cualquiera que pudiera construir una URL correctamente diseñada obtener más de 200.000 nombres, números de tarjetas de crédito y fechas de vencimiento de la base de datos de clientes del sitio. [ 24 ]
  • El 1 de noviembre de 2005, un hacker adolescente utilizó la inyección SQL para infiltrarse en el sitio web 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, ciberdelincuentes rusos irrumpieron en un sitio web del gobierno de Rhode Island y presuntamente robaron datos de tarjetas de crédito de personas que habían realizado trámites en línea con agencias estatales. [ 26 ]
  • El 19 de septiembre de 2007 y el 26 de enero de 2009, el grupo de hackers turcos "m0sted" utilizó la inyección SQL para explotar el SQL Server de Microsoft y hackear servidores web pertenecientes a la Planta de Municiones del Ejército de McAlester y al Cuerpo de Ingenieros del Ejército de los 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 rutinario " después de ser informado de que 10.597 números de Seguro Social pertenecientes a delincuentes sexuales habían sido descargados mediante un ataque de inyección SQL. [ 28 ]
  • El 17 de agosto de 2009, el Departamento de Justicia de Estados Unidos acusó a un ciudadano estadounidense, Albert Gonzalez , y a dos rusos no identificados del robo de 130 millones de números de tarjetas de crédito mediante un ataque de inyección SQL. En lo que se considera "el mayor caso de robo de identidad en la historia de Estados Unidos", el hombre robó tarjetas de varias empresas tras investigar sus sistemas de procesamiento de pagos . Entre las empresas afectadas se encontraban la procesadora 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 conocido como " Ch  Russo" obtuvo información confidencial de usuarios del popular sitio BitTorrent The Pirate Bay . Obtuvo acceso al panel de control administrativo del sitio y explotó una vulnerabilidad de inyección SQL que le permitió recopilar información de las cuentas de usuario, incluyendo direcciones IP , hashes MD5 de contraseñas y registros de los torrents que cada usuario había subido. [ 30 ]
  • Entre el 24 y el 26 de julio de 2010, atacantes de Japón y China utilizaron una inyección SQL para acceder a los datos de tarjetas de crédito de los clientes de Neo Beat, una empresa con sede en Osaka que gestiona un importante supermercado en línea. El ataque también afectó a siete socios comerciales, entre ellos las cadenas de supermercados Izumiya Co., Maruetsu Inc. y Ryukyu Jusco Co. El robo de datos afectó a 12.191 clientes. El 14 de agosto de 2010 se informó de más de 300 casos de uso indebido de información de tarjetas de crédito por parte de terceros para la compra de bienes y servicios en China.
  • El 19 de septiembre, durante las elecciones generales suecas de 2010, un votante intentó inyectar código escribiendo manualmente comandos SQL como parte de un voto por escrito . [ 31 ]
  • El 8 de noviembre de 2010, el sitio web de la Marina Real Británica fue comprometido por un hacker rumano llamado TinKode mediante inyección SQL. [ 32 ] [ 33 ]
  • El 11 de abril de 2011, Barracuda Networks sufrió una brecha de seguridad mediante una vulnerabilidad de inyección SQL. Entre la información obtenida se encontraban las direcciones de correo electrónico y los nombres de usuario de los empleados. [ 34 ]
  • Durante un período de 4  horas el 27 de abril de 2011, se produjo un ataque automatizado de inyección SQL en el sitio web Broadband Reports que logró extraer el 8% de los pares de nombre de usuario/contraseña: 8000 cuentas aleatorias de las 9000 cuentas 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 usar inyección SQL para robar cupones , claves de descarga 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. [ 38 ]
  • En junio de 2011, PBS fue hackeado por LulzSec, muy probablemente mediante inyección SQL; el proceso completo utilizado por los hackers para ejecutar inyecciones SQL se describió en este blog de Imperva . [ 39 ]
  • En julio de 2012, se informó que un grupo de hackers había robado 450.000 credenciales de inicio de sesión de Yahoo !. Las credenciales se almacenaron en texto plano y, supuestamente, fueron extraídas de un subdominio de Yahoo , Yahoo! Voices . El grupo vulneró la seguridad de Yahoo mediante una técnica de inyección SQL basada en uniones . [ 40 ] [ 41 ]
  • El 1 de octubre de 2012, un grupo de hackers llamado "Team GhostShell" publicó en pastebin.com los registros personales de estudiantes, profesores, empleados y exalumnos de 53 universidades, entre ellas Harvard , Princeton , Stanford , Cornell , Johns Hopkins y la Universidad de Zúrich . Los hackers afirmaron que intentaban "concienciar sobre los cambios en la educación actual", lamentando la modificación de las leyes educativas en Europa y el aumento de las matrículas en Estados Unidos . [ 42 ]
  • El 4 de noviembre de 2013, el grupo de hacktivistas "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 en colaboració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 SQL. [ 44 ] El New York Times confirmó este hallazgo al contratar a un experto en seguridad para verificar la afirmación. [ 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 antiguo. [ 46 ]
  • 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 fuente de Gab por Fosco Marotto, CTO de Gab . [ 47 ] Un segundo ataque contra Gab se lanzó la semana siguiente utilizando tokens OAuth2 robados durante el primer ataque. [ 48 ]
  • En mayo de 2023, un ataque de inyección SQL a gran escala tuvo como objetivo MOVEit , un servicio de transferencia de archivos muy utilizado . Los ataques, atribuidos al grupo de ciberdelincuentes de habla rusa Clop , comprometieron a varias organizaciones globales, entre ellas el proveedor de nóminas Zellis, British Airways , la BBC y la cadena minorista británica Boots . Los atacantes explotaron una vulnerabilidad crítica, instalando un webshell personalizado llamado "LemurLoot" para acceder rápidamente y extraer grandes volúmenes de datos. [ 49 ]
  • En 2024, dos investigadores de seguridad descubrieron una vulnerabilidad de inyección SQL en el sistema FlyCASS, utilizado por la Administración de Seguridad del Transporte (TSA) para verificar a los miembros de la tripulación de las aerolíneas. La explotación de esta vulnerabilidad proporcionaba acceso administrativo no autorizado, lo que potencialmente permitía la adición de registros falsos de la tripulación. La TSA declaró que sus procedimientos de verificación no dependían exclusivamente de esta base de datos. [ 50 ]
  • Una viñeta de xkcd de 2007 mostraba a un personaje llamado Robert'); DROP TABLE Students;-- para llevar a cabo una inyección SQL. Como resultado de esta viñeta, la inyección SQL a veces se conoce informalmente como "Bobby Tables". [ 51 ] [ 52 ]
  • El acceso no autorizado a sitios web mediante inyección SQL constituye la base de una de las subtramas de la novela de J.K. Rowling de 2012, Una vacante imprevista .
  • En 2014, un individuo en Polonia cambió legalmente el nombre de su negocio a Dariusz Jakubowski x'; DROP TABLE users; SELECT '1 en un intento de interrumpir el funcionamiento de los bots de recolección de spammers . [ 53 ]
  • El juego Hacknet de 2015 tiene un programa de hackeo llamado SQL_MemCorrupt. Se describe como un programa que inyecta una entrada en una tabla que causa un error de corrupción en una base de datos SQL, luego consulta dicha tabla, lo que provoca un fallo en la base de datos SQL y un volcado de memoria .

Véase también

Referencias

  1. ↑ Microsoft. "Inyección SQL" . Archivado del original el 2 de agosto de 2013. Recuperado el 4 de agosto de 2013. La inyección SQL es un ataque en el que se inserta código malicioso en cadenas que posteriormente se pasan a una instancia de SQL Server para su análisis y ejecución. Cualquier procedimiento que construya sentencias SQL debe revisarse en busca de vulnerabilidades de inyección, ya que SQL 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. 1 2 Zhuo, Z.; Cai, T.; Zhang, X.; Lv, F. (abril de 2021). "Memoria a corto y largo plazo en árbol de sintaxis abstracta para la detección de inyección SQL" . IET Software . 15 (2): 188– 197. doi : 10.1049/sfw2.12018 . ISSN 1751-8806 . S2CID 233582569 .  
  3. ↑ "Hacking NodeJS and MongoDB" . Consultado el 13 de enero de 2026 .
  4. 1 2 3 4 5 6 "Hoja de trucos para la prevención de inyecciones SQL" . Proyecto de seguridad de aplicaciones web abiertas (OWASP) . Consultado el 10 de marzo de 2025 .
  5. ↑ 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 del original el 19 de marzo de 2014.
  6. ↑ "Categoría:OWASP Top Ten Project" . Open Web Application Security Project (OWASP). Archivado del original el 19 de mayo de 2011. Recuperado el 3 de junio de 2011 .
  7. ↑ "Categoría:OWASP Top Ten Project" . Open Web Application Security Project (OWASP). Archivado del original el 9 de octubre de 2013. Recuperado el 13 de agosto de 2013 .
  8. ↑ "Los 10 principales riesgos de seguridad de las aplicaciones según OWASP - 2017" . Proyecto Abierto de Seguridad de Aplicaciones Web (OWASP) . Consultado el 9 de marzo de 2025 .
  9. ↑ "OWASP Top 10 2021" . Proyecto Abierto de Seguridad de Aplicaciones Web (OWASP) . Consultado el 9 de marzo de 2025 .
  10. ↑ "A03:2021 – Inyección" . Proyecto Abierto de Seguridad de Aplicaciones Web (OWASP) . Consultado el 9 de marzo de 2025 .
  11. 1 2 3 4 SentinelOne (30 de septiembre de 2024). "¿Qué es la inyección SQL? Ejemplos y prevención" . SentinelOne . Consultado el 15 de abril de 2026 .
  12. ↑ "Cómo introducir comentarios SQL" (PDF) , Guía de IBM Informix para SQL: Sintaxis , IBM, págs. 13-14 , archivado del original (PDF) el 24 de febrero de 2021 , consultado el 4 de junio de 2018. 
  13. ↑ "Extracción de múltiples bits por solicitud de vulnerabilidades de inyección SQL totalmente ciegas" . Hack All The Things. Archivado del original el 8 de julio de 2016. Recuperado el 8 de julio de 2016 .
  14. ↑ "Uso de SQLBrute para realizar un ataque de fuerza bruta a datos desde un punto de inyección SQL ciego" . Justin Clarke. Archivado del original el 14 de junio de 2008. Consultado el 18 de octubre de 2008 .
  15. ↑ macd3v. "Tutorial de inyección SQL ciega" . Archivado del original el 14 de diciembre de 2012. Consultado el 6 de diciembre de 2012 .{{cite web}}: CS1 maint: nombres numéricos: lista de autores ( enlace )
  16. ↑ Andrey Rassokhin; Dmitry Oleksyuk. "Red de bots TDSS: divulgación completa" . Archivado del original el 9 de diciembre de 2012. Recuperado el 6 de diciembre de 2012 .
  17. ↑ "Preguntas para TalkTalk - BBC News" . BBC News . 26 de octubre de 2015. Archivado del original el 26 de octubre de 2015. Consultado el 26 de octubre de 2015 .
  18. ↑ "Hoja de referencia rápida para la validación de entradas" . Proyecto Abierto de Seguridad de Aplicaciones Web (OWASP) . Consultado el 10 de marzo de 2025 .
  19. ↑ "Pruebas de inyección ORM" . OWASP . Consultado el 17 de marzo de 2025 .
  20. ↑ "Ataques de inyección SQL y prevención: guía completa" . appsecmonkey.com . 13 de febrero de 2021. Consultado el 24 de febrero de 2021 .
  21. ↑ "Literales de cadena MySQL" .
  22. ↑ "Sentencia SELECT de MySQL" .
  23. ↑ "Nombres de objetos del esquema MySQL" .
  24. ↑ "Las conjeturas dificultan la notificación de vulnerabilidades web" . SecurityFocus . 6 de marzo de 2002. Archivado del original el 9 de julio de 2012.
  25. ↑ "WHID 2005-46: Un adolescente utiliza inyección SQL para acceder ilegalmente al sitio web de una revista de seguridad" . Consorcio de Seguridad de Aplicaciones Web. 1 de noviembre de 2005. Archivado del original el 17 de enero de 2010. Consultado el 1 de diciembre de 2009 .
  26. ↑ "WHID 2006-3: Hackers rusos irrumpen en un sitio web del gobierno de Rhode Island" . Consorcio de Seguridad de Aplicaciones Web. 13 de enero de 2006. Archivado del original el 13 de febrero de 2011. Consultado el 16 de mayo de 2008 .
  27. ↑ "Hackers anti-EE. UU. se infiltran en servidores del ejército" . Information Week . 29 de mayo de 2009. Archivado del 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 Seguro Social y otros datos confidenciales" . The Daily WTF . Archivado del original el 10 de mayo de 2008. Consultado el 16 de mayo de 2008 .
  29. ↑ "Hombre estadounidense 'robó 130 millones de números de tarjetas'"" . BBC. 17 de agosto de 2009. Archivado del original el 18 de agosto de 2009. Consultado el 17 de agosto de 2009 .
  30. ↑ "El ataque a The Pirate Bay" . 7 de julio de 2010. Archivado del original el 24 de agosto de 2010.
  31. ↑ "¿Emigraron las pequeñas mesas Bobby a Suecia?" . Alicebobandmallory.com . Consultado el 3 de junio de 2011 .{{cite web}}: CS1 maint: servicio de archivado obsoleto ( enlace )
  32. ↑ "Ataque de un hacker rumano al sitio web de la Marina Real" . BBC News. 8 de noviembre de 2010. Archivado del original el 9 de noviembre de 2010. Consultado el 15 de noviembre de 2023 .
  33. ↑ Sam Kiley (25 de noviembre de 2010). "Supervirus: un objetivo para los ciberterroristas" . Archivado del original el 28 de noviembre de 2010. Consultado el 25 de noviembre de 2010 .
  34. ↑ "Un hacker irrumpe en la base de datos de Barracuda Networks" . Archivado del original el 27 de julio de 2011.
  35. ↑ "información sobre intrusión de contraseñas de usuarios del sitio" . Dslreports.com. Archivado del original el 18 de octubre de 2012. Recuperado el 3 de junio de 2011 .
  36. ↑ "DSLReports afirma que se robó información de sus miembros" . Noticias de Cnet. 28 de abril de 2011. Archivado del original el 21 de marzo de 2012. Consultado el 29 de abril de 2011 .
  37. ↑ "La filtración de datos de DSLReports.com expuso más de 100.000 cuentas" . The Tech Herald. 29 de abril de 2011. Archivado del original el 30 de abril de 2011. Consultado el 29 de abril de 2011 .
  38. ↑ "LulzSec hackea Sony Pictures y revela 1 millón de contraseñas sin protección" , electronista.com , 2 de junio de 2011, archivado del original el 6 de junio de 2011 , consultado el 3 de junio de 2011.
  39. ↑ "Imperva.com: PBS hackeada - Cómo probablemente lo hicieron los hackers" . Archivado del original el 29 de junio de 2011. Consultado el 1 de julio de 2011 .
  40. ↑ Ngak, Chenda. "Yahoo presuntamente hackeado: ¿Está segura tu cuenta?" . CBS News . Archivado del original el 14 de julio de 2012. Consultado el 16 de julio de 2012 .
  41. ↑ Yap, Jamie (12 de julio de 2012). "Se filtraron 450.000 contraseñas de usuarios en una brecha de seguridad de Yahoo" . ZDNet . Archivado del original el 2 de julio de 2014. Consultado el 18 de febrero de 2017 .
  42. ↑ Perlroth, Nicole (3 de octubre de 2012). «Hackers invaden 53 universidades y publican miles de datos personales en línea» . New York Times . Archivado del original el 5 de octubre de 2012.
  43. ↑ Kovacs, Eduard (4 de noviembre de 2013). "Hackers filtran datos presuntamente robados del sitio web de la Cámara de Comercio China" . Softpedia News . Archivado del original el 2 de marzo de 2014. Consultado el 27 de febrero de 2014 .
  44. ↑ Damon Poeter. Una banda de hackers rusos muy unida acumula 1.200 millones de credenciales de identificación. Archivado el 14 de julio de 2017 en Wayback Machine , PC Magazine , 5 de agosto de 2014.
  45. ↑ Nicole Perlroth. Banda rusa acumula 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 libras por no haber evitado el ataque de octubre de 2015» . 5 de octubre de 2016. Archivado del original el 24 de octubre de 2016. Consultado el 23 de octubre de 2016 .
  47. ↑ Goodin, Dan (2 de marzo de 2021). "El error de programación de principiante anterior al hackeo de Gab provino del CTO del sitio" . Ars Technica .
  48. ↑ Goodin, Dan (8 de marzo de 2021). "Gab, un refugio para teorías conspirativas pro-Trump, ha sido hackeado de nuevo" . Ars Technica .
  49. ↑ "La explotación masiva de una falla crítica de MOVEit está saqueando organizaciones grandes y pequeñas" . Ars Technica . 6 de junio de 2023. Consultado el 9 de marzo de 2025 .
  50. ↑ "Investigadores afirman que un fallo les permitió añadir pilotos falsos a las listas utilizadas para los controles de la TSA" . The Verge . 8 de septiembre de 2024. Consultado el 9 de marzo de 2025 .
  51. ↑ Munroe, Randall. "XKCD: Hazañas de una madre" . Archivado del original el 25 de febrero de 2013. Recuperado el 26 de febrero de 2013 .
  52. ↑ "La guía de Bobby Tables sobre inyección SQL" . 15 de septiembre de 2009. Archivado del original el 7 de noviembre de 2017. Consultado el 30 de octubre de 2017 .
  53. ^ "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 . 
  • Guías rápidas de inyección SQL de OWASP , por OWASP.
  • Clasificación de amenazas de WASC: Entrada de inyección SQL , por el Consorcio de Seguridad de Aplicaciones Web (WASC).
  • Por qué la inyección SQL no desaparece. 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 las vulnerabilidades de seguridad: inyección SQL
Obtenido de " https://en.wikipedia.org/w/index.php?title=SQL_injection&oldid=1357373286 "
Lecturas relacionadas
6 articulos
Inyección de códigoInyección de códigoLas inyecciones de código son una clase de vulnerabilidades de seguridad informática en las que se engaña a un programa informático vulnerable para...CiberataqueCiberataqueUn ciberataque (o ataque cibernético) ocurre cuando hay una acción no autorizada contra la infraestructura informática que compromete la confidenci...SQLSQLEl lenguaje de consulta estructurado ( SQL ) ( pronunciado S-QL ; históricamente "secuela") [4] [5] es un lenguaje específico de dominio utilizado ...Base de datosBase de datosUna sentencia de selección SQL y su resultado En informática , una base de datos es una colección organizada de datos o un tipo de almacenamiento d...Vulnerabilidad (seguridad informática)Vulnerabilidad (seguridad informática)En seguridad informática , una vulnerabilidad es un fallo o debilidad en el diseño, la implementación o la gestión de un sistema que puede ser expl...Secuencia de escapeSecuencia de escapeEn informática , una secuencia de escape es una combinación de caracteres que tiene un significado distinto al de los caracteres literales que cont...