Cómo prevenir los ataques de inyección SQL y proteger tu organización

Pocos cosas aterrorizan tanto a los profesionales de seguridad informática y a las organizaciones que protegen como el robo de datos. En un solo momento, los datos privados de una empresa, registros de clientes, identificaciones de empleados y otros tipos de información confidencial pueden ser robados de los servidores internos. Un momento más y esos datos están disponibles para ser vendidos al mejor postor.

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

El lenguaje de consulta estructurado, o SQL por sus siglas en inglés, 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 en sistemas de gestión de bases de datos (DBMS) y se encuentra en innumerables organizaciones en todo el mundo.

Cuando el auge de las aplicaciones web que se conectan a bases de datos SQL se hizo común, no pasó mucho tiempo para que los ataques de inyección SQL se hicieran realidad. Desde que se descubrió por primera vez en 1998, los ataques SQLi han sido el tormento de casi todas las organizaciones con una aplicación web basada en datos.

Los ataques SQLi funcionan, al menos en apariencia, de manera bastante sencilla: un atacante envía una declaración SQL maliciosa en un campo de entrada que explota una vulnerabilidad en la implementación SQL de la aplicación web.

Si tiene éxito, la declaración 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. El SQLi también puede dar a un atacante acceso de administrador a una base de datos, lo que le permite eliminar o modificar datos.

Según la naturaleza de la base de datos SQL, un ataque SQLi incluso puede darle al atacante acceso al sistema operativo de la máquina que la alberga, lo que le permite acceder a otros recursos de la red.

Cómo proteger tus servidores Linux de ataques de fuerza bruta con denyhosts

Las inyecciones SQL suelen presentarse en una de tres formas: SQLi clásica (también conocida como SQLi en banda), SQLi a ciegas (también conocida como SQLi por inferencia) y SQLi fuera de banda (OOB) (también conocida como SQLi específica del DBMS).

Ataques SQLi clásicos son la forma más común y simple de ataques SQLi. Los ataques clásicos pueden ocurrir siempre que una base de datos SQL permita a los usuarios enviar una declaración SQL. Vienen en dos variedades:

• Ataques basados en errores, que implican que una aplicación web arroje un error SQL que le brinda al atacante información sobre la estructura de la base de datos o sobre la información específica que está buscando.
• Ataques basados en UNION, que utilizan el operador UNION SQL para determinar detalles de la estructura de la base de datos con el fin de extraer información.

Ataques SQLi a ciegas pueden ser uno de varios tipos de ataques, como ataques basados en errores o UNION, con la diferencia principal de que al atacante no se le presenta un mensaje de error ni otro tipo de texto para indicar el éxito o fracaso de su ataque.

Sin embargo, los ataques a ciegas hacen que una aplicación web se comporte de diferentes maneras, según cómo responda la base de datos a la consulta SQL. Los atacantes pueden inferir la estructura de la base de datos en función de cómo responda la aplicación web, lo que les permite construir una copia de la base de datos caracter por caracter.

Debido a que los ataques a ciegas reconstruyen una base de datos un caracter a la vez, se consideran extremadamente lentos. Cuanto más grande es la base de datos, más lenta es la respuesta, lo que puede hacer que los ataques a ciegas sean imposibles en muchas situaciones.

La inyección SQL fuera de banda (OOB) es un enfoque mucho menos común para atacar un servidor SQL. Se basa en ciertas características de una base de datos SQL para que se activen; si esas características no están habilitadas, el ataque OOB no tendrá éxito.

OPNsense: Una potente y fácil de usar firewall para proteger tu red

Los ataques OOB implican enviar una consulta DNS o HTTP al servidor SQL que contiene una declaración SQL. Si tiene éxito, el ataque OOB puede otorgar privilegios de usuario, transmitir el contenido de la base de datos y realizar las mismas acciones que otros tipos de ataques SQLi.

Existe un cuarto tipo de ataque SQLi, pero se excluyó de la lista anterior porque implica combinar ataques SQLi con otros ciberataques.

Llamados ataques SQLi compuestos, estos ataques implican el uso de SQLi junto con scripting entre sitios, denegación de servicio, secuestro de DNS o ataques de autenticación insuficientes. Al combinar SQLi con otros métodos de ataque, los piratas informáticos tienen 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 sensibles que no solo puede poner en peligro a una organización, sus empleados y sus clientes, sino que también puede erosionar la confianza en la capacidad de esa organización para mantener seguros los datos confidenciales.

¿Quiénes están en riesgo de sufrir un ataque de inyección SQL y qué puede sucederles a las víctimas?

El riesgo organizativo de un ataque SQLi solo requiere cumplir dos criterios simples: tener un sitio web y que ese sitio web interactúe con una base de datos SQL.

Sin la seguridad adecuada en su lugar y en vista de informes que indican que algunas industrias enfrentan más de 1,000 ciberataques al día, es fácil imaginar caer víctima de un ataque SQLi.

Cómo generar y administrar pares de claves SSH en Windows para una conexión segura

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 particularmente tentadores para los hackers debido a toda la información que recopilan y almacenan.

Una aplicación web basada en datos es cualquier aplicación que cambia su comportamiento en función de los datos que ingresa un usuario. Ejemplos de aplicaciones basadas en datos incluyen:

• Aplicaciones de encuestas;
• Aplicaciones para generar informes;
• Aplicaciones de búsqueda;
• Libros de visitas;
• Aplicaciones de flujo de trabajo;
• Aplicaciones que generan notificaciones/recordatorios;
• Sitios web de redes sociales;

Todos esos tipos de aplicaciones web, y más, son potencialmente más susceptibles a los ataques SQLi.

Con todos esos datos potencialmente al alcance de los atacantes, es fácil ver qué puede sucederle a las organizaciones que sufren un ataque SQLi. En particular, los efectos de una inyección SQL exitosa pueden incluir:

• Un atacante creando una copia de toda la base de datos (o partes específicas);
• un atacante falsificando credenciales de inicio de sesión, suplantando a un usuario o incluso eludiendo la autenticación por completo;
• modificación de la base de datos (por ejemplo, cambiar, eliminar o agregar registros);
• robo de archivos no relacionados con la base de datos ubicados en el sistema de archivos del DMBS;
• ejecución de comandos del sistema operativo que dan a un atacante acceso a otros activos en la red que aloja la base de datos SQL; y
• dejar sin conexión la aplicación web/DBMS objetivo.

Esos resultados directos de un ataque SQLi exitoso son problemas lo suficientemente grandes por sí mismos, pero no son lo único a considerar; también está el impacto a largo plazo. La venta de datos confidenciales en la web oscura, la pérdida de clientes, los costos de recuperación, la erosión de la confianza, todos esos resultados y más pueden ser el resultado de un ataque SQLi exitoso.

¿Cuáles son ejemplos de ataques de inyección SQL exitosos?

Los ataques de inyección SQL han estado plagando Internet durante más de 20 años; en ese tiempo, han ocurrido muchos ataques destacados y descubrimientos de vulnerabilidades.

La importancia de la encriptación: Protege tus datos con seguridad

• 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 vencimiento de más de 200,000 clientes.
• En 2006, hackers supuestamente provenientes de Rusia irrumpieron en el sitio web del gobierno estatal 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 resultó en 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 permitía a los atacantes descargar más de 10,000 registros de delincuentes (incluidos los números de seguro social).
• En 2009, el gobierno de Estados Unidos acusó a Albert González y a otros 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 varias otras compañías.
• En 2011, hackers afiliados a Anonymous utilizaron SQLi para derribar el sitio web de la empresa de seguridad informática HBGary después de que su CEO afirmara haber descubierto las identidades de los miembros de Anonymous.
• En 2012, hackers de Team GhostShell publicaron 36,000 conjuntos de registros personales pertenecientes a estudiantes, profesores y personal de más de 53 universidades que habían robado utilizando SQLi.
• En 2013, el colectivo RedHack utilizó SQLi para hackear un sitio web del gobierno turco y borrar las deudas de las personas con varias agencias gubernamentales.
• En 2014, investigadores de seguridad pudieron utilizar un ataque SQLi a ciegas para robar datos de usuario y obtener acceso administrativo al sitio web del fabricante de automóviles Tesla.
• En 2015, el sitio web de crowdfunding Patreon fue hackeado utilizando un ataque SQLi. La violación fue tan grave que los atacantes no solo obtuvieron datos de contraseñas y registros de donaciones, sino que también pudieron robar el código fuente de Patreon.
• En 2016, un niño finlandés de 10 años llamado Jani encontró una vulnerabilidad de SQLi que le permitió eliminar comentarios en las cuentas de otros usuarios de Instagram.
• En 2017, la base de datos de registro de votantes de la Junta Electoral del Estado de Illinois fue hackeada utilizando un ataque SQLi.
• En 2018, se encontró una vulnerabilidad en el Licenciamiento Principal de Cisco (ahora parcheado) que permitía a los atacantes editar la base de datos de administración de licencias y obtener privilegios de shell elevados en sistemas vulnerables.
• En 2019, se descubrieron fallos en el sitio web del popular videojuego Fortnite que podrían permitir a los atacantes acceder a las cuentas de usuario mediante un ataque SQLi.

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

No hay duda de que la inyección SQL es extremadamente peligrosa y sorprendentemente común. Afortunadamente, proteger tu sitio web o aplicación web contra SQLi no es difícil de hacer.

En primer lugar, utiliza una herramienta de sondeo de SQLi como Tyrant-SQL para encontrar cualquier vulnerabilidad que pueda tener tu sitio web o aplicación. Puede ser difícil determinar los riesgos a los que te enfrentas, y ejecutar una aplicación como Tyrant puede facilitar la búsqueda de debilidades. Este paso inicial no es estrictamente necesario, pero puede darte una mejor idea de lo que estás enfrentando.

En cuanto a las medidas de protección, la página de prevención de SQLi de OWASP tiene una excelente descripción de cómo defenderte (así como más detalles y ejemplos).

1. Utiliza declaraciones preparadas en lugar de consultas dinámicas

Las declaraciones preparadas con consultas parametrizadas deben ser la forma en que se escriben todas las consultas de bases de datos. La parametrización significa que todo el código SQL involucrado en la consulta debe definirse de antemano, lo que significa que la base de datos podrá distinguir entre el código y la entrada del usuario.

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

2. Utiliza procedimientos almacenados

El uso de procedimientos almacenados es similar al uso de declaraciones preparadas, al menos desde el punto de vista de que ambas implican definir declaraciones SQL válidas de antemano. La diferencia entre los procedimientos almacenados y las declaraciones preparadas es donde vive el código SQL: en el caso de las declaraciones 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.

Los 4 archivos más importantes para las conexiones SSH en Linux

Existen casos en los que los procedimientos almacenados pueden ser inseguros, especialmente si se utiliza generación de SQL dinámica dentro de los procedimientos almacenados. Evita esto si es posible; si es necesario generar SQL dinámico, asegúrate de que los procedimientos almacenados estén utilizando validación de entrada o métodos adecuados para evitar la inyección de código malicioso.

Los procedimientos almacenados no son tan a prueba de fallas como las declaraciones preparadas. Siempre que sea posible, opta por declaraciones preparadas en lugar de procedimientos almacenados.

3. Utiliza validación de entrada

En casos en los que cierto código SQL sea una parte necesaria de la entrada del usuario, es esencial crear una lista blanca de declaraciones SQL válidas. Crea una lista de las declaraciones más esenciales para evitar que se incluyan declaraciones no validadas en una consulta.

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

4. Escapa toda la entrada suministrada por el usuario

Escapar la entrada SQL tiene el efecto de eliminar la amenaza que representan ciertos caracteres en las declaraciones SQL. Dependiendo del tipo de función de escape utilizada, las declaraciones de entrada SQL se editarán para agregar un carácter "\" u otro carácter delante de ciertos caracteres para evitar que los comandos maliciosos se ejecuten correctamente.

Esto se considera un último recurso para prevenir ataques SQLi. Por sí solo, el escape no es confiable y es propenso a errores, especialmente si una función de escape no está codificada correctamente. Solo utiliza el escape si no es posible utilizar otros métodos de prevención.

Cómo configurar las políticas de contraseñas en Windows 7

Métodos adicionales de defensa

OWASP también recomienda limitar los privilegios de la cuenta de la base de datos, especialmente para las cuentas de aplicación. Otorgar acceso de administrador a estas cuentas puede hacer que una aplicación se ejecute sin problemas, pero también abre la puerta a SQLi al otorgar 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 para limitar a qué tiene acceso 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 al atacante solo con una pequeña parte del contenido de la base de datos que lo vuelve inútil.

Implementar estas medidas de protección puede ayudar a prevenir ataques de inyección SQL y mantener seguros los datos confidenciales de tu organización.

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre Seguridad, allí encontraras muchos artículos similares a Cómo prevenir los ataques de inyección SQL y proteger tu organización , tenemos lo ultimo en tecnología 2023.