¡No te pierdas nuestro canal en Youtube!

Nuestras otras creaciones:
La-biblioteca.com | Cineactual.es | Mundofriki.es


SQL injection: Definición, tipos y cómo defenderse  SQL injection: Definición, tipos y cómo defenderse

Valoración de éste post
4.24 / 5 de 334 votos



Mensajes: 951


Puntos totales:

Enhorabuena!

34




SQL injection: Definición y métodos

La inyección SQL ha sido un riesgo importante para la seguridad desde los primeros días de Internet. Descubre cuál es el riesgo y cómo los profesionales de la ciberseguridad pueden defender a sus organizaciones.

Pocas cosas aterran tanto a los profesionales de la seguridad informática -y a las organizaciones que protegen- como el robo de datos. En un momento, los datos privados de una empresa, los registros de los clientes, las identificaciones de los empleados y otros muchos tipos de datos confidenciales pueden ser sustraídos de los servidores internos.

Un momento más, y esos datos están disponibles para su venta al mejor postor.

Uno de los métodos más comunes para robar datos confidenciales es la inyección SQL (SQLi), que se centra en las vulnerabilidades de seguridad de las aplicaciones web para inyectar una sentencia SQL maliciosa en la base de datos que almacena los registros de la aplicación web.

Las bases de datos SQL almacenan información crítica y, a pesar de ello, muchos sitios web siguen siendo vulnerables a los ataques SQLi, como los que se dirigen a SQL, que siguen siendo el riesgo de seguridad más crítico de las aplicaciones web.

Es esencial que no sólo los profesionales de la seguridad informática, sino también los responsables de la toma de decisiones a los que protegen, comprendan el riesgo de esta amenaza para la seguridad.

¿Qué son los ataques de inyección SQL?:

El lenguaje de consulta estructurado, o SQL, es un método de gestión de bases de datos relacionales que se concibió por primera vez en la década de 1970. Desde entonces, se ha convertido en el estándar de los sistemas de gestión de bases de datos (DBMS) y se encuentra en innumerables organizaciones de todo el mundo.

Cuando el auge de las aplicaciones web en Internet que se conectaban a bases de datos SQL se convirtió en algo habitual, los ataques de inyección SQL no tardaron en hacerse realidad.
Desde que se descubrió por primera vez en 1998, SQLi ha sido la perdición de casi todas las organizaciones con una aplicación web basada en datos.

SQLi funciona, al menos en la superficie, de una manera muy sencilla: Un atacante envía una sentencia SQL maliciosa en un campo rellenable que explota una vulnerabilidad en la implementación SQL de la aplicación web.

Si tiene éxito, la sentencia SQL maliciosa podría volcar todo el contenido de una base de datos, o seleccionar datos como registros de clientes, combinaciones de ID/contraseña de empleados, o cualquier otra cosa que contenga la base de datos objetivo.

SQLi también puede dar a un atacante acceso de administrador a una base de datos, permitiéndole borrar o modificar datos.

Dependiendo de la naturaleza de la base de datos SQL, un ataque SQLi puede incluso dar a un atacante acceso al sistema operativo de la máquina que la aloja, lo que puede permitir al atacante obtener acceso a otros recursos de la red.

Las inyecciones SQL suelen presentarse de tres formas: SQLi clásico (también conocido como SQLi en banda), SQLi ciego (también conocido como SQLi de inferencia) y SQLi fuera de banda (OOB) (también conocido como SQLi específico de DMS).

Los ataques SQLi clásicos son la forma más común y sencilla de SQLi. Los ataques clásicos pueden ocurrir siempre que una base de datos SQL permita a los usuarios enviar una sentencia SQL.

Existen dos variedades:

SQLi basado en errores, que consiste en hacer que una aplicación web lance un error SQL que proporcione al atacante información sobre la estructura de la base de datos o la información concreta que busca.

Los ataques basados en UNION, que utilizan el operador SQL UNION para determinar detalles de la estructura de la base de datos con el fin de extraer información.

Los ataques SQLi ciegos pueden ser uno de los diferentes tipos de ataques, como los basados en errores o los basados en UNION, con la principal diferencia de que al atacante no se le presenta un mensaje de error ni ningún otro tipo de texto que indique el éxito o el fracaso de su ataque.

Los ataques ciegos, sin embargo, hacen que una aplicación web se comporte de diferentes maneras, dependiendo de cómo la base de datos responda a la consulta SQL. Los atacantes pueden entonces inferir la estructura de la base de datos basándose en cómo responde la aplicación web, lo que les permite construir una copia de la base de datos carácter por carácter.

Dado que los ataques ciegos reconstruyen una base de datos carácter por carácter, se considera que consumen mucho tiempo. Cuanto mayor sea la base de datos, más lenta será la respuesta, lo que puede hacer que los ataques ciegos sean poco prácticos en muchas situaciones.

SQLi fuera de banda es un enfoque mucho menos común para atacar un servidor SQL. Depende de que ciertas características de una base de datos SQL estén habilitadas; si esas características no lo están, el ataque OOB no tendrá éxito.

Los ataques OOB implican el envío de una consulta DNS o HTTP al servidor SQL que contenga una sentencia SQL. Si tiene éxito, el ataque OOB puede escalar los privilegios del usuario, transmitir el contenido de la base de datos y, en general, hacer las mismas cosas que hacen otras formas de ataques SQLi.

Existe un cuarto tipo de ataque SQLi, pero fue excluido de la lista anterior porque implica la combinación de ataques SQLi con otros ciberataques.

Denominados SQLi compuestos, estos ataques implican el uso de SQLi junto con ataques de cross-site scripting, denegación de servicio, secuestro de DNS o autenticación insuficiente.
La combinación de SQLi con otros métodos de ataque proporciona a los hackers formas adicionales de evitar la detección y eludir los sistemas de seguridad.

El resultado final de todas estas formas diferentes de SQLi es el mismo: el robo de datos confidenciales que no sólo puede poner en peligro a una organización, sus empleados y sus clientes, sino también erosionar la confianza en la capacidad de esa organización para mantener los datos confidenciales a salvo.

¿Quiénes corren el riesgo de sufrir un ataque de inyección SQL y qué les puede pasar a las víctimas?:

El riesgo organizativo de un ataque SQLi sólo requiere cumplir dos simples criterios: Tener un sitio web, y que ese sitio web interactúe con una base de datos SQL.

Sin la seguridad adecuada, y a la luz de los informes de que algunas industrias se enfrentan a más de 1.000 ciberataques al día, es fácil imaginar que se es víctima de un ataque SQLi.

Aunque cualquier sitio web que dependa de una base de datos SQL puede ser objeto de ataques SQLi, las aplicaciones web basadas en datos son objetivos especialmente tentadores para los hackers debido a toda la información que recogen y almacenan.

Una aplicación web basada en datos es cualquier aplicación que cambia su comportamiento en función de los datos que introduce el usuario. Algunos ejemplos de aplicaciones basadas en datos son:

Aplicaciones de encuestas.

Aplicaciones de generación de informes.

Aplicaciones de búsqueda.

Libros de visitas.

Aplicaciones de flujo de trabajo.

Aplicaciones que generan notificaciones/recordatorios y sitios web de redes sociales.

Todos estos tipos de aplicaciones web -y más- están potencialmente expuestos a un mayor riesgo de ataque SQLi.

Con todos esos datos potencialmente en juego, es fácil ver lo que puede ser de las organizaciones que sufren un ataque SQLi. En particular, los efectos de una inyección SQL exitosa pueden incluir:

Un atacante que crea una copia de toda la base de datos (o de partes específicas).

Un atacante que suplante las credenciales de acceso, que se haga pasar por un usuario o incluso que se salte la autenticación por completo.

La modificación de la base de datos (por ejemplo, cambiando, borrando o añadiendo registros),
el robo de archivos que no sean de la base de datos y que se encuentren en el sistema de archivos de la DMBS.

La ejecución de comandos del sistema operativo que dan al atacante acceso a otros activos de la red que alberga la base de datos SQL; y la desconexión de la aplicación web/DBMS objetivo.

Estos resultados directos de un ataque SQLi exitoso son problemas lo suficientemente grandes por sí mismos, pero no son lo único que hay que tener en cuenta: también están las consecuencias a largo plazo.

La venta de datos confidenciales en la web oscura, la pérdida de clientes, los costes de recuperación, la erosión de la confianza... todas estas consecuencias y otras más pueden ser el resultado de un ataque SQLi con éxito.

¿Cuáles son los ejemplos de ataques de inyección SQL que han tenido éxito?:

Los ataques de inyección SQL llevan más de 20 años asolando Internet; en ese tiempo, se han producido muchos ataques y descubrimientos de vulnerabilidades de gran repercusión.

En 2002, se descubrió una vulnerabilidad en el sitio web de la marca de moda Guess que expuso los nombres, números de tarjetas de crédito y fechas de caducidad de más de 200.000 clientes.

En 2006, unos piratas informáticos supuestamente procedentes de Rusia entraron en el sitio web del gobierno del estado de Rhode Island y robaron más de 4.000 números de tarjetas de crédito.

En 2007, un hacker conocido como rEmOtEr utilizó un ataque de inyección SQL para desfigurar el sitio web de Microsoft en el Reino Unido. El ataque no provocó el robo de ningún dato.

En 2008, se descubrió que el Registro de Delincuentes Sexuales y Violentos de Oklahoma era vulnerable a un ataque SQLi que permitió a los atacantes descargar más de 10.000 registros de delincuentes (incluidos los números de la seguridad social).

En 2009, el gobierno estadounidense acusó a Albert González y a dos cómplices de utilizar ataques SQLi para robar más de 130 millones de números de tarjetas de crédito de 7-Eleven y de otras empresas.

En 2011, piratas informáticos afiliados a Anonymous utilizaron SQLi para tumbar el sitio web de la empresa de seguridad informática HBGary después de que su director general afirmara que había descubierto las identidades de los miembros de Anonymous.

En 2012, los hackers de Team GhostShell publicaron 36.000 conjuntos de registros personales pertenecientes a estudiantes, profesores y personal de más de 53 universidades que robaron utilizando SQLi.

En 2013, el colectivo RedHack utilizó SQLi para irrumpir en un sitio web del gobierno turco y borrar las deudas de las personas con diversas agencias gubernamentales.

En 2014, los investigadores de seguridad fueron capaces de utilizar un ataque SQLi ciego para robar datos de usuarios y obtener acceso administrativo al sitio web del fabricante de automóviles Tesla.

En 2015, el sitio de crowdfunding Patreon fue hackeado mediante un ataque SQLi. La brecha fue tan grave que los atacantes no solo obtuvieron los datos de las contraseñas y los registros de las donaciones, sino que pudieron robar el código fuente de Patreon.

En 2016, un niño finlandés de 10 años llamado Jani encontró una vulnerabilidad SQLi que le permitía borrar los comentarios de las cuentas de otros usuarios de Instagram.

En 2017, la base de datos de registro de votantes de la Junta Estatal de Elecciones de Illinois fue hackeada mediante un ataque SQLi.

En 2018, una vulnerabilidad encontrada en Prime License Manager de Cisco (ahora parcheada) permitió a los atacantes editar la base de datos de gestión de licencias y obtener privilegios elevados de shell en sistemas vulnerables.

En 2019, las fallas descubiertas en el sitio web del popular videojuego Fortnite podrían permitir a los atacantes obtener acceso a las cuentas de los usuarios a través de un ataque SQLi.

¿Cómo puedo prevenir un ataque de inyección SQL contra mi organización?:

No te equivoques: la inyección SQL es increíblemente peligrosa y sorprendentemente común. Afortunadamente, proteger tu sitio o aplicación web contra SQLi no es difícil de hacer.

Para empezar, utiliza una herramienta de sondeo SQLi como Tyrant-SQL para encontrar cualquier vulnerabilidad que pueda tener tu sitio o aplicación. Puede ser difícil reducir el riesgo que se corre, pero una aplicación como Tyrant puede facilitar la búsqueda de puntos débiles.

Hacer este paso inicial no es estrictamente necesario, pero puede darte una mejor idea de a qué te enfrentas.

En cuanto a los pasos de protección, la página de prevención de SQLi de OWASP tiene un excelente resumen de cómo defenderse (así como más detalles y ejemplos).

Nota: Estas estrategias se pueden utilizar para proteger otras bases de datos, como XPath y XQuery, también. He aquí un resumen de lo que recomienda OWASP.

1. Utilizar sentencias preparadas en lugar de consultas dinámicas:

Las sentencias preparadas con consultas parametrizadas deberían ser la forma en que se escriben todas las consultas de la base de datos. La parametrización significa que todo el código SQL involucrado en la consulta tiene que ser definido de antemano, lo que significa que la base de datos será capaz de distinguir entre el código y la entrada del usuario.

Si un atacante intenta introducir una sentencia SQL maliciosa, la base de datos tratará la sentencia como datos, no como código, y la consulta no se convertirá en maliciosa.

2. Utilizar procedimientos almacenados:

El uso de procedimientos almacenados es similar al uso de sentencias preparadas, al menos desde el punto de vista de que ambos implican la definición de sentencias SQL válidas de antemano. La diferencia entre los procedimientos almacenados y las sentencias preparadas es el lugar en el que se encuentra el código SQL:

En el caso de las sentencias preparadas, el código SQL se almacena en la propia aplicación web, mientras que los procedimientos almacenados viven en la base de datos y son llamados por la aplicación web.

Hay casos en los que los procedimientos almacenados pueden ser inseguros, especialmente si se utiliza la generación de SQL dinámico dentro de los procedimientos almacenados. Evita esto si es posible; si la generación de SQL dinámico es necesaria, asegúrate de que los procedimientos almacenados utilizan la validación de entrada o el escape adecuado para evitar la inyección de código malicioso.

Los procedimientos almacenados no son tan infalibles como las sentencias preparadas. Siempre que sea posible, opta por las sentencias preparadas en lugar de los procedimientos almacenados.

3. Utiliza la validación de entradas:

En los casos en los que algún código SQL es una parte necesaria de la entrada del usuario, es esencial crear una lista blanca de sentencias SQL válidas. Crea sólo una lista de las sentencias más esenciales para evitar que las sentencias no validadas acaben en una consulta.

La validación de entradas por sí sola no es suficiente para proteger una base de datos SQL, pero debería utilizarse en todos los casos como una capa adicional de protección.

4. Escapar todas las entradas proporcionadas por el usuario:

Escapar la entrada SQL tiene el efecto de eliminar la amenaza que suponen ciertos caracteres en las sentencias SQL. Dependiendo del tipo de función de escape que se utilice, las sentencias de entrada SQL se editarán para anteponer un "\N" u otro carácter delante de ciertos caracteres con el fin de evitar que los comandos maliciosos se ejecuten correctamente.

Esto se considera un método de última instancia para prevenir los ataques SQLi. Por sí mismo, el escape no es fiable y es propenso a errores, especialmente si una función de escape no está codificada correctamente.

Utiliza el escape sólo si no es posible utilizar otros métodos de prevención.

Métodos de defensa adicionales:

OWASP también recomienda limitar los privilegios de las cuentas de la base de datos, especialmente para las cuentas de las aplicaciones. Aunque conceder acceso de administrador a estas cuentas puede hacer que una aplicación funcione sin problemas, también abre la puerta a SQLi al dar a los usuarios acceso de administrador a la base de datos.

Además, puede ser útil utilizar diferentes cuentas de usuario para diferentes aplicaciones web con el fin de limitar el acceso de una cuenta en particular. Además, limitar el acceso de lectura a campos específicos puede evitar que un ataque SQLi exitoso extraiga información, dejando a un atacante con sólo una pequeña parte del contenido de la base de datos que lo hace inútil.

¡Esperamos que este tutorial sobre SQL Injection te haya sido útil, muchas gracias por leernos!.



No te pierdas el tema anterior: Ventajas y desventajas de una red Wifi

Salta al siguiente tema: Ataques de fuerza bruta: Cómo funcionan, pros y contras

Quizás también te interese:

Volver a Seguridad y redes