Inyección SQL
En esta sección, explicaremos qué es la inyección de SQL, describiremos algunos ejemplos comunes, explicaremos cómo encontrar y explotar varios tipos de vulnerabilidades de inyección de SQL y resumiremos cómo prevenir la inyección de SQL.
¿Qué es la inyección SQL (SQLi)?
La inyección SQL es una vulnerabilidad de seguridad web que permite a un atacante interferir con las consultas que una aplicación realiza a su base de datos. Por lo general, permite que un atacante vea datos que normalmente no puede recuperar. Esto puede incluir datos pertenecientes a otros usuarios o cualquier otro dato al que la propia aplicación pueda acceder. En muchos casos, un atacante puede modificar o eliminar estos datos, provocando cambios persistentes en el contenido o el comportamiento de la aplicación.
En algunas situaciones, un atacante puede escalar un ataque de inyección SQL para comprometer el servidor subyacente u otra infraestructura de back-end, o realizar un ataque de denegación de servicio.
Solicita una cotización del mejor escaner de vulnerabilidades de sitios web y aplicativos expuestos, con precios por anualidad e intercambio de targets, BURP SUITE ENTERPRISE es el único que lo ofrece, cambia YA!
¿Cuál es el impacto de un ataque de inyección SQL exitoso?
Un ataque de inyección SQL exitoso puede resultar en un acceso no autorizado a datos confidenciales, como contraseñas, detalles de tarjetas de crédito o información personal del usuario. Muchas violaciones de datos de alto perfil en los últimos años han sido el resultado de ataques de inyección de SQL, lo que ha provocado daños a la reputación y multas reglamentarias. En algunos casos, un atacante puede obtener una puerta trasera persistente en los sistemas de una organización, lo que lleva a un compromiso a largo plazo que puede pasar desapercibido durante un período prolongado.
Ejemplos de inyección SQL
Existe una amplia variedad de vulnerabilidades, ataques y técnicas de inyección SQL, que surgen en diferentes situaciones. Algunos ejemplos comunes de inyección de SQL incluyen:
- Recuperando datos ocultos, donde puede modificar una consulta SQL para devolver resultados adicionales.
- Subvirtiendo la lógica de la aplicación, donde puede cambiar una consulta para interferir con la lógica de la aplicación.
- Ataques UNION, donde puede recuperar datos de diferentes tablas de bases de datos.
- Examinar la base de datos, donde se puede extraer información sobre la versión y estructura de la base de datos.
- Inyección ciega de SQL, donde los resultados de una consulta que controlas no se devuelven en las respuestas de la aplicación.
Recuperando datos ocultos
Considere una aplicación de compras que muestre productos en diferentes categorías. Cuando el usuario hace clic en la categoría Regalos, su navegador solicita la URL:
https://insecure-website.com/products?category=Gifts
Esto hace que la aplicación realice una consulta SQL para recuperar detalles de los productos relevantes de la base de datos:
SELECT * FROM products WHERE category = 'Gifts' AND released = 1
Esta consulta SQL solicita a la base de datos que devuelva:
- Todos los detalles (*)
- de la tabla de productos
- donde la categoría es Regalos
- y lanzado es 1.
La restricción released = 1se utiliza para ocultar productos que no se lanzan. Para productos inéditos, presumiblemente released = 0.
La aplicación no implementa ninguna defensa contra los ataques de inyección de SQL, por lo que un atacante puede construir un ataque como:
https://insecure-website.com/products?category=Gifts'--
Esto da como resultado la consulta SQL:
SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1
La clave aquí es que la secuencia de dos guiones --es un indicador de comentario en SQL y significa que el resto de la consulta se interpreta como un comentario. Esto elimina efectivamente el resto de la consulta, por lo que ya no incluye AND released = 1. Esto significa que se muestran todos los productos, incluidos los productos inéditos.
Yendo más allá, un atacante puede hacer que la aplicación muestre todos los productos en cualquier categoría, incluidas las categorías que no conoce:
https://insecure-website.com/products?category=Gifts'+OR+1=1--
Esto da como resultado la consulta SQL:
SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1
La consulta modificada devolverá todos los elementos en los que la categoría sea Regalos o 1 sea igual a 1. Dado 1=1que siempre es verdadera, la consulta devolverá todos los elementos.
Subvirtiendo la lógica de la aplicación
Considere una aplicación que permite a los usuarios iniciar sesión con un nombre de usuario y una contraseña. Si un usuario envía el nombre de usuario wiener y la contraseña bluecheese, la aplicación verifica las credenciales realizando la siguiente consulta SQL:
SELECT * FROM users WHERE username = 'wiener' AND password = 'bluecheese'
Si la consulta devuelve los detalles de un usuario, entonces el inicio de sesión es exitoso. De lo contrario, se rechaza.
Aquí, un atacante puede iniciar sesión como cualquier usuario sin contraseña simplemente usando la secuencia de comentarios SQL --para eliminar la verificación de contraseña de la WHEREcláusula de la consulta. Por ejemplo, enviar el nombre de usuario administrator'--y una contraseña en blanco da como resultado la siguiente consulta:
SELECT * FROM users WHERE username = 'administrator'--' AND password = ''
Esta consulta devuelve el usuario cuyo nombre de usuario es administratory registra correctamente al atacante como ese usuario.
Recuperar datos de otras tablas de bases de datos
En los casos en que los resultados de una consulta SQL se devuelven dentro de las respuestas de la aplicación, un atacante puede aprovechar una vulnerabilidad de inyección SQL para recuperar datos de otras tablas dentro de la base de datos. Esto se hace usando la UNIONpalabra clave, que le permite ejecutar una SELECTconsulta adicional y agregar los resultados a la consulta original.
Por ejemplo, si una aplicación ejecuta la siguiente consulta que contiene la entrada del usuario «Regalos»:
SELECT name, description FROM products WHERE category = 'Gifts'
entonces un atacante puede enviar la entrada:
' UNION SELECT username, password FROM users--
Esto hará que la aplicación devuelva todos los nombres de usuario y contraseñas junto con los nombres y descripciones de los productos.
Examinando la base de datos
Después de la identificación inicial de una vulnerabilidad de inyección de SQL, generalmente es útil obtener información sobre la base de datos en sí. Esta información a menudo puede allanar el camino para una mayor explotación.
Puede consultar los detalles de la versión de la base de datos. La forma en que se hace esto depende del tipo de base de datos, por lo que puede inferir el tipo de base de datos a partir de cualquier técnica que funcione. Por ejemplo, en Oracle puede ejecutar:
SELECT * FROM v$version
También puede determinar qué tablas de base de datos existen y qué columnas contienen. Por ejemplo, en la mayoría de las bases de datos puede ejecutar la siguiente consulta para listar las tablas:
SELECT * FROM information_schema.tables
Vulnerabilidades de inyección SQL ciega
Muchas instancias de inyección SQL son vulnerabilidades ciegas. Esto significa que la aplicación no devuelve los resultados de la consulta SQL o los detalles de los errores de la base de datos dentro de sus respuestas. Las vulnerabilidades ciegas aún pueden explotarse para acceder a datos no autorizados, pero las técnicas involucradas son generalmente más complicadas y difíciles de realizar.
Dependiendo de la naturaleza de la vulnerabilidad y la base de datos involucrada, se pueden utilizar las siguientes técnicas para explotar vulnerabilidades de inyección SQL ciega:
- Puede cambiar la lógica de la consulta para desencadenar una diferencia detectable en la respuesta de la aplicación según la verdad de una sola condición. Esto podría implicar inyectar una nueva condición en alguna lógica booleana o desencadenar condicionalmente un error como una división por cero.
- Puede activar condicionalmente un retraso de tiempo en el procesamiento de la consulta, lo que le permite inferir la verdad de la condición en función del tiempo que tarda la aplicación en responder.
- Puede desencadenar una interacción de red fuera de banda utilizando técnicas OAST. Esta técnica es extremadamente poderosa y funciona en situaciones donde las otras técnicas no lo hacen. A menudo, puede extraer datos directamente a través del canal fuera de banda, por ejemplo, colocando los datos en una búsqueda de DNS para un dominio que usted controla.
Cómo detectar vulnerabilidades de inyección de SQL
La mayoría de las vulnerabilidades de inyección de SQL se pueden encontrar de forma rápida y confiable utilizando el escáner de vulnerabilidades web de Burp Suite .
La inyección de SQL se puede detectar manualmente mediante el uso de un conjunto sistemático de pruebas contra cada punto de entrada en la aplicación. Por lo general, esto implica:
- Enviar el carácter de comilla simple
'y buscar errores u otras anomalías. - Enviar alguna sintaxis específica de SQL que evalúe el valor base (original) del punto de entrada y un valor diferente, y buscar diferencias sistemáticas en las respuestas de la aplicación resultante.
- Enviar condiciones booleanas como
OR 1=1yOR 1=2, andbuscar diferencias en las respuestas de la aplicación. - Enviar cargas útiles diseñadas para desencadenar retrasos cuando se ejecutan dentro de una consulta SQL y buscar diferencias en el tiempo necesario para responder.
- Enviar cargas útiles de OAST diseñadas para desencadenar una interacción de red fuera de banda cuando se ejecuta dentro de una consulta SQL y monitorear cualquier interacción resultante.
Inyección SQL en diferentes partes de la consulta.
La mayoría de las vulnerabilidades de inyección de SQL surgen dentro de la WHEREcláusula de una SELECTconsulta. Este tipo de inyección SQL generalmente es bien entendido por probadores experimentados.
Pero, en principio, las vulnerabilidades de inyección de SQL pueden ocurrir en cualquier ubicación dentro de la consulta y dentro de diferentes tipos de consultas. Las otras ubicaciones más comunes donde surge la inyección de SQL son:
- En
UPDATEdeclaraciones, dentro de los valores actualizados o laWHEREcláusula. - En
INSERTdeclaraciones, dentro de los valores insertados. - En
SELECTdeclaraciones, dentro del nombre de la tabla o columna. - En
SELECTdeclaraciones, dentro de laORDER BYcláusula.
Inyección SQL de segundo orden
La inyección SQL de primer orden surge cuando la aplicación toma la entrada del usuario de una solicitud HTTP y, en el curso del procesamiento de esa solicitud, incorpora la entrada en una consulta SQL de una manera insegura.
En la inyección SQL de segundo orden (también conocida como inyección SQL almacenada), la aplicación toma la entrada del usuario de una solicitud HTTP y la almacena para uso futuro. Esto generalmente se hace colocando la entrada en una base de datos, pero no surge ninguna vulnerabilidad en el punto donde se almacenan los datos. Posteriormente, al manejar una solicitud HTTP diferente, la aplicación recupera los datos almacenados y los incorpora a una consulta SQL de manera insegura.
La inyección de SQL de segundo orden a menudo surge en situaciones en las que los desarrolladores son conscientes de las vulnerabilidades de inyección de SQL y, por lo tanto, manejan de manera segura la ubicación inicial de la entrada en la base de datos. Cuando los datos se procesan posteriormente, se consideran seguros, ya que previamente se colocaron en la base de datos de manera segura. En este punto, los datos se manejan de manera insegura, porque el desarrollador erróneamente los considera confiables.
Factores específicos de la base de datos
Algunas características centrales del lenguaje SQL se implementan de la misma manera en las plataformas de bases de datos populares, y muchas formas de detectar y explotar las vulnerabilidades de inyección de SQL funcionan de manera idéntica en diferentes tipos de bases de datos.
Sin embargo, también existen muchas diferencias entre las bases de datos comunes. Esto significa que algunas técnicas para detectar y explotar la inyección de SQL funcionan de manera diferente en diferentes plataformas. Por ejemplo:
- Sintaxis para la concatenación de cadenas.
- Comentarios.
- Consultas por lotes (o apiladas).
- API específicas de la plataforma.
- Error de mensajes.
Descubre todo tipo de Vulnerabilidades. Con el escáner para sitios y aplicaciones web habilitado para empresas. «BURP SUITE ENTERPRISE»
Cómo prevenir la inyección de SQL
La mayoría de las instancias de inyección de SQL se pueden evitar mediante el uso de consultas parametrizadas (también conocidas como declaraciones preparadas) en lugar de la concatenación de cadenas dentro de la consulta.
El siguiente código es vulnerable a la inyección de SQL porque la entrada del usuario se concatena directamente en la consulta:
String query = "SELECT * FROM products WHERE category = '"+ input + "'";
Statement statement = connection.createStatement();
ResultSet resultSet = statement.executeQuery(query);
Este código se puede reescribir fácilmente de manera que evite que la entrada del usuario interfiera con la estructura de la consulta:
PreparedStatement statement = connection.prepareStatement("SELECT * FROM products WHERE category = ?");
statement.setString(1, input);
ResultSet resultSet = statement.executeQuery();
Las consultas parametrizadas se pueden utilizar para cualquier situación en la que la entrada que no es de confianza aparece como datos dentro de la consulta, incluida la WHEREcláusula y los valores en una declaración INSERTo UPDATE. No se pueden usar para manejar entradas que no sean de confianza en otras partes de la consulta, como nombres de tablas o columnas, o la ORDER BY cláusula. La funcionalidad de la aplicación que coloca datos que no son de confianza en esas partes de la consulta deberá adoptar un enfoque diferente, como la inclusión de valores de entrada permitidos en la lista blanca o el uso de una lógica diferente para ofrecer el comportamiento requerido.
Para que una consulta parametrizada sea eficaz en la prevención de la inyección de SQL, la cadena que se utiliza en la consulta siempre debe ser una constante codificada de forma rígida y nunca debe contener datos variables de ningún origen. No se sienta tentado a decidir caso por caso si un elemento de datos es confiable y continúe usando la concatenación de cadenas dentro de la consulta para los casos que se consideran seguros. Es muy fácil cometer errores sobre el posible origen de los datos, o que los cambios en otro código violen las suposiciones sobre qué datos están contaminados.
La heramienta lider en el mercado que te ofrece la detección de vulnerabilidades en sitios web y aplicativos expuestos es BURP SUITE ENTERPRISE, atrévete a conocer y usar las herramientas de última generación, no expongas a tu empresa al desastre, ya después.. ya después no tiene caso buscarnos..
NORTH NETWORKS es Distribuidor de BURP SUITE con valor agregado, solicita una cotización o demo ahora mismo y no expongas a tu empresa o los recursos de de esta.
Si te ha gustado, ¡compártelo con tus amigos!
