Los codificadores conquistan la seguridad: comparta y aprenda - Inyección SQL

En términos sencillos, SQL (o lenguaje de consulta estructurado) es el lenguaje que se utiliza para comunicarse con las bases de datos relacionales; es el lenguaje de consulta que utilizan los desarrolladores, los administradores de bases de datos y las aplicaciones para gestionar la se generan enormes cantidades de datos todos los días.

Nuestros datos se están convirtiendo rápidamente en uno de los productos más valiosos del mundo... y cuando algo es valioso, los malos querrán hacerse con él para su beneficio.

Los atacantes utilizan la inyección SQL, una de las más antiguas (desde 1998!) y las vulnerabilidades de datos más molestas que existen: robar y cambiar la información confidencial disponible en millones de bases de datos de todo el mundo. Es insidioso, y los desarrolladores necesitan entender la inyección de SQL (y saber cómo defenderse de ella) si queremos mantener nuestros datos seguros.

Con ese fin, analizaremos tres aspectos clave de la inyección de SQL:

• How work
• Por qué es tan peligroso
• Cómo defenderse de ello

Comprenda la inyección de SQL

La inyección SQL se puede entender usando una palabra: contexto.

Dentro de una aplicación, existen dos contextos: uno para los datos y otro para el código. El contexto del código indica al ordenador lo que debe ejecutar y lo separa de los datos que se van a procesar.

La inyección de SQL se produce cuando un atacante introduce datos que el intérprete de SQL trata erróneamente como código.

Un ejemplo es un campo de entrada en un sitio web, en el que un atacante escribe '» OR 1=1" y se añade al final de una consulta SQL. Cuando se ejecuta esta consulta, devuelve «true» para cada fila de la base de datos. Esto significa que se devolverán todos los registros de la tabla consultada.

Las implicaciones de la inyección de SQL pueden ser catastróficas. Si esto ocurre en una página de inicio de sesión, podría mostrar todos los registros de usuario, incluidos posiblemente los nombres de usuario y las contraseñas. Si una consulta simple para extraer datos tiene éxito, las consultas para cambiar los datos también lo harían.

Echemos un vistazo a algunos códigos vulnerables para que puedas ver cómo es una vulnerabilidad de inyección de SQL en persona.

Consulta este código:

Case query = «SELECT THE SALDO OF USER_DATA WHERE user_name =»
+ Request.getParameter («Nombre del cliente»);
test {
Declaration of statement = connection.createStatement ( ... );
ResultSet results = Statement.executeQuery (consulta);
}

El código aquí simplemente agrega la información de los parámetros del cliente al final de la consulta SQL sin ninguna validación. Cuando esto ocurre, un atacante puede introducir el código en un campo de entrada o en los parámetros de la URL y se ejecutará.

La clave no es que los ataques solo puedan añadir '» O 1=1" a cada consulta SELECT, sino que un atacante puede manipular cualquier tipo de consulta SQL (INSERT, UPDATE, DELETE, DROP, etc.) y ampliarla con cualquier cosa que admita la base de datos. Las hay estupendas recursos and tools available in the public domain that muestran lo que es posible.

Pronto descubriremos cómo corregir este problema. Primero, comprendamos cuánto daño se puede causar.

¿Por qué la inyección de SQL es tan peligrosa?

Estos son solo tres ejemplos de infracciones causadas por la inyección de SQL:

• Sitio web de la Junta Electoral de Illinois fue violado debido a las vulnerabilidades de inyección de SQL. Los atacantes robaron los datos personales de 200.000 ciudadanos estadounidenses. La naturaleza de la vulnerabilidad encontrada significaba que los atacantes también podrían haber cambiado los datos, aunque no lo hicieron.
• Hetzner, una empresa sudafricana de alojamiento de sitios web, fue violado con un total de 40 000 registros de clientes. Una vulnerabilidad de inyección de SQL provocó el posible robo de todos los registros de clientes de su base de datos.
• Un proveedor católico de servicios financieros en Minnesota, Estados Unidos, fue violado usando la inyección SQL. Se robaron los detalles de las cuentas, incluidos los números de cuenta, de casi 130.000 clientes.

Los datos confidenciales se pueden usar para apoderarse de cuentas, restablecer contraseñas, robar dinero o cometer fraudes.

Incluso la información que no se considera confidencial o de identificación personal puede usarse para otros ataques. La información de dirección o los últimos cuatro dígitos de su número de identificación gubernamental se pueden usar para hacerse pasar por usted ante las empresas o para restablecer su contraseña.

Cuando un ataque tiene éxito, los clientes pueden perder la confianza en la empresa. Recogerse de los daños a los sistemas o de las multas reglamentarias puede costar millones de dólares.

Pero no tiene por qué terminar así para ti.

Derrota la inyección de SQL

La inyección de SQL se puede derrotar etiquetando claramente las partes de la aplicación, de modo que la computadora sepa si una determinada parte son datos o código que se va a ejecutar. Esto se puede hacer mediante consultas parametrizadas.

Cuando las consultas SQL usan parámetros, el intérprete SQL usa el parámetro solo como datos. No lo ejecuta como código.

Por ejemplo, un ataque como '» OR 1=1" no funcionará. La base de datos buscará la cadena «OR 1=1" y no la encontrará en la base de datos. Simplemente se encogerá de hombros y dirá: «Lo siento, no puedo encontrar eso para ti».

Un ejemplo de una consulta parametrizada en Java tiene este aspecto:

La mayoría de los marcos de desarrollo proporcionan defensas integradas contra la inyección de SQL.

Mapeadores relacionales de objetos (ORM), como Entidades framework in the family .NET, parametrizará las consultas de forma predeterminada. Esto se encargará de la inyección de SQL sin ningún esfuerzo por su parte.

Sin embargo, debe saber cómo funciona su ORM específico. Por ejemplo, Hibernar, un ORM popular en el mundo de Java, aún puede ser vulnerable a la inyección de SQL si se usa incorrectamente.

La parametrización de las consultas es la primera y mejor defensa, pero hay otras. Los procedimientos almacenados también admiten parámetros SQL y se pueden usar para evitar la inyección de SQL. Tenga en cuenta que los procedimientos almacenados también debe construirse correctamente para que esto funcione.

//Esto REALMENTE también debería validarse
Cadena customname = request.getParameter («CustomerName»);
//validar entradas para detectar ataques
Consulta de cadena = «SELECCIONA account_balance DESDE user_data DONDE user_name =? «;

PreparedStatement pstmt = Connection.PreparedStatement (consulta);
pstmt.setString (1, nombre personalizado);
ResultSet results = pstmt.executeQuery ();

Valide y desinfecte siempre sus entradas. Dado que algunos caracteres, como «OR 1=1", no los va a introducir un usuario legítimo de la aplicación, no es necesario permitirlos. Puedes mostrar un mensaje de error al usuario o eliminarlo de la entrada antes de procesarlo.

Dicho esto, no depende únicamente de la validación y la desinfección para protegerse. Los seres humanos inteligentes han encontrado formas de evitarlo. Son buenas estrategias de defensa en profundidad (DiD), pero la parametrización es la forma infalible de cubrir todas las bases.

Otra buena estrategia de DiD es utilizar el «mínimo privilegio» en la base de datos y la entrada de la lista blanca. Imponer el mínimo privilegio significa que la aplicación no tiene una potencia ilimitada dentro de la base de datos. Si un atacante tuviera acceso, el daño que puede causar es limitado.

OWASP tiene una gran SQL Trucks How to SQL Inyection disponible para mostrar cómo gestionar esta vulnerabilidad en varios idiomas y plataformas... pero si quieres hacerlo mejor, puedes jugar a un desafío de inyección de SQL en tu idioma preferido en nuestra plataforma ahora mismo; estos son algunos de los más populares para empezar:

SQL Inyection in C#

SQL Inyection in Node.js

SQL Inyection in Python Django

SQL Inyection in Java Spring

Bake the trip

Ha logrado un gran progreso en la comprensión de la inyección de SQL y los pasos necesarios para solucionarlo. ¡Impresionante!

Hemos analizado cómo se produce la inyección de SQL; por lo general, cuando un atacante utiliza la entrada para controlar las consultas de la base de datos con sus propios fines nefastos.

También hemos visto el daño causado por la explotación de las vulnerabilidades de inyección de SQL: las cuentas pueden verse comprometidas y perder millones de dólares... una pesadilla y, además, cara.

Hemos visto cómo prevenir la inyección de SQL:

• Parametrización de consultas
• Uso de mapeadores relacionales de objetos y procedimientos almacenados
• Validar e incluir en la lista blanca las entradas de los usuarios

Ahora, depende de ti. La práctica es la mejor manera de seguir aprendiendo y desarrollando el dominio, así que ¿por qué no echas un vistazo a nuestro Learning Resources in SQL injection, luego pruebe nuestro demo gratuita de la plataforma? Estarás bien encaminado para convertirte en un guerrero del código seguro.