¿Cómo puedo explicar la inyección de SQL sin la jerga técnica?

Una de las maneras más fáciles de ilustrar el problema detrás de la inyección SQL es usar una imagen como esta. El problema es la capacidad de los extremos receptores para separar los datos del comando.

Aquí hay una analogía no técnica del mundo real.

Está a punto de ir al banco para realizar una transacción en nombre de su jefe. Su jefe le entregó un sobre con instrucciones para el cajero.

Las instrucciones leen:

Write the balance for account with number 8772344 on this paper.

Signed,
Boss

Usted deja el sobre fuera de su vista por unos minutos mientras va al baño. Un ladrón abre el sobre y agrega sobre la firma: "También transfiera $ 500 de la cuenta 8772344 a otra cuenta con el número 12747583.".

Ahora el mensaje completo dice:

Write the balance for account with number 8772344 on this paper.
Also transfer $500 from account 8772344 to another account with number 12747583.
Signed,
Boss

El cajero verifica su identificación y verifica que usted es una persona autorizada para la cuenta en cuestión y sigue las instrucciones de la carta.

Tu jefe es el código de programa legítimo. Usted es el código del programa y el controlador de la base de datos que entrega el código SQL a la base de datos. La letra es el código SQL que se pasa a la base de datos. El ladrón es el atacante. El cajero es la base de datos. La identificación suele ser un nombre de usuario y una contraseña para la base de datos.

Si realmente le estás explicando a tu abuela, usa un cheque en papel como ejemplo. (En los EE. UU.) En el pasado, escribiría el monto en dólares numéricamente en un campo y luego escribiría lo mismo en palabras. Por ejemplo, en un campo, escribirías "100.00" y en el segundo campo más largo, escribirías "Cien dólares y cero centavos". Si no usó todo el segundo campo largo, dibujaría una línea para evitar que alguien sin escrúpulos aumente su monto escrito.

Si cometió el error de dejar algo de espacio en el segundo campo más largo, alguien podría modificar el campo numérico y luego usar el espacio adicional en el campo más largo para reflejarlo. El modificador podría obtener más dinero del que esperaba cuando escribió el cheque.

La inyección SQL es lo mismo: un error que permite que personas sin escrúpulos modifiquen un campo de entrada para que reciba más información de la que pretendía el programador original.

La idea que primero me vino a la mente fue explicarlo en términos de Mad Lib. Las historias donde las palabras se omiten, y para completar los espacios en blanco, pida al grupo palabras del tipo indicado y escríbalas, luego lea la historia resultante.

Esa es la forma normal de completar un Mad Lib. Pero, ¿qué pasaría si alguien más supiera la historia y qué espacios en blanco estaba llenando (o podría adivinar)? Entonces, en lugar de una sola palabra, ¿qué pasaría si esa persona te diera algunas palabras? ¿Qué pasa si las palabras que te dieron incluyen un punto que termina la oración? Si lo completó, puede encontrar que lo que se proporcionó aún "encaja", pero cambia drásticamente la historia más de lo que cualquier palabra que normalmente completaría podría hacer. Si tuviera espacio, podría agregar párrafos completos a Mad Lib y convertirlo en algo muy diferente.

Eso, en términos no técnicos, es una inyección de SQL en pocas palabras. Usted proporciona algunos "espacios en blanco" para los datos que se insertarán en un comando SQL, al igual que las palabras en un Mad Lib. Un atacante luego ingresa un valor que no es lo que esperas; en lugar de un simple valor para buscar, ingresa una parte de una declaración SQL que termina la que usted escribió, y luego agrega su propio comando SQL como una "oración" nueva. La declaración adicional puede ser muy perjudicial, como un comando para eliminar la base de datos, o para crear un nuevo usuario con muchos permisos en el sistema. La computadora, sin saber la diferencia, simplemente realizará todas las tareas para las que se le ordena.

Lo explicaría como decirle a un cajero que el cliente siempre tiene la razón y que debe hacer todo lo posible para satisfacer las necesidades del cliente. Entonces, como no hay comprobaciones sobre la razonabilidad de la solicitud, cuando un cliente entra y dice que quiere que toda la tienda sea gratuita, el cajero carga todo el inventario en su camión para ellos.

No es una explicación perfecta, pero tiene la idea de que se le dice al código que haga lo que sea que el usuario ingrese y luego el malo usa esa instrucción para deshacerse de los bienes.

Supongo que realmente depende del tipo de punto que intentas transmitir.

Otra gran manera de explicar a alguien sobre cualquier cosa (incluida la inyección SQL) es con la ayuda de personajes de dibujos animados y enmarcando una historia a su alrededor.

En mi opinión, esta es la mejor imagen disponible en Internet, explicándola de una manera bastante agradable.

Fuente: enlace

Todo depende del grado de no técnico al que estés hablando aquí, pero normalmente describiría la inyección de SQL a la gente de negocios de la siguiente manera: -

"una debilidad en la forma en que algunos sitios web manejan los comentarios de los usuarios (por ejemplo, dónde coloca su nombre en un formulario de registro) que puede permitir que un atacante tenga acceso a la base de datos que almacena toda la información del usuario del sitio"

si quieren un poco más de detalles.

"Algunas aplicaciones web no separan correctamente la entrada del usuario de las instrucciones para la base de datos, lo que puede permitir a los atacantes dar instrucciones directamente a la base de datos, a través de la información que completan en el formulario del sitio web. Esto le permite al atacante leer los demás usuarios" información fuera de la base de datos, o cambie parte de la información que se encuentra allí ".

Creo que puedes obtener el mejor efecto solo con demostrar el ataque. Escriba un formulario web de apariencia inofensiva y muestre el resultado de la consulta utilizando la entrada del usuario. Luego, después de ingresar su propia entrada preparada, su audiencia tendrá una "experiencia de aha" después de encontrar las contraseñas en el resultado. Hice una página de demostración , simplemente haga clic en la "flecha siguiente" para completar una entrada preparada.

P.S. Si escribe una página de este tipo por su cuenta, tenga mucho cuidado de no permitir que los evaluadores obtengan privilegios no deseados. Lo mejor es cuando solo ejecutará la demostración en su sistema local con los privilegios de base de datos más bajos posibles (no todos los tipos de ataques deberían ser posibles, es solo una demostración). Haga una lista blanca de expresiones permitidas.

La base de datos es como un genio mágico (u Oracle ) que otorga deseos. Le hemos dicho a nuestro genio que solo otorgue un máximo de tres deseos, pero si no verificamos lo que la gente desea, entonces alguien lo superará fácilmente pidiendo algo inteligente como "cien deseos más" o "los deseos de todos los demás" .

Explícalo tan fácil como:

El sistema puede tomar solicitudes con datos de cualquier usuario para hacer algo con él.

El propio sistema tiene una funcionalidad para operar como eliminar o cambiar datos.

Un atacante intenta ejecutar cualquiera de estas funciones para ganar o destruir algo.

Por lo tanto, el atacante coloca comandos válidos en las solicitudes.

El sistema ejecuta estos comandos, ejecutando lo que el atacante deseaba.

Imagine una gran empresa que mantiene todos sus registros en papel en una gran sala llena de archivadores. Para recuperar o realizar cambios en los archivos, alguien llenará un formulario simple de completar espacios en blanco y luego ese formulario se enviará a un empleado que siga las instrucciones del formulario.

Por ejemplo:

  

Recupere los registros de facturación desde la fecha de inicio _ _ _ hasta la fecha de finalización _ _ _ donde el cliente está _ _ _

Normalmente esto se convertiría en algo como esto:

  

Recupere los registros de facturación desde la fecha de inicio 01/01/2011 hasta la fecha de finalización 12/31/2011 donde el cliente es Billy Joe Bob

Pero en manos de una persona sin escrúpulos, tal vez este formulario podría usarse para otros propósitos, por ejemplo:

  

Recupere los registros de facturación desde la fecha de inicio 01/01/2011 hasta la fecha de finalización 12/31/2011 donde el cliente es Robert Mensas y también recupere el números de tarjetas de crédito para todos los clientes

Al pretender que su nombre también incluye otros comandos, pueden secuestrar el formulario de relleno, y si el empleado no ha sido entrenado para manejar este tipo de cosas, tal vez simplemente ejecutarán las instrucciones sin pensarlo y se las entregarán. Toda la información de la tarjeta de crédito a un usuario.

O, alternativamente:

  

Recupere los registros de facturación desde la fecha de inicio 01/01/2011 hasta la fecha de finalización 12/31/2011 donde el cliente es Robert Mensas y también agregue $ 100,000 al saldo de la cuenta de Robert Mensas

Que tiene un potencial similarmente peligroso.

El truco con las inyecciones de SQL es asegurarse de que su código sea lo suficientemente inteligente como para poder garantizar que los usuarios no puedan cambiar la intención de los comandos que está enviando a la base de datos y no pueden recuperar datos o realizar cambios que no puedan realizar. no se debe permitir.

A veces, los piratas informáticos colocan comandos de computadora / programación en cajas en Internet para engañar al sitio web para que haga algo que no debería. Por lo tanto, verificamos la información ingresada en los sitios web para ver lo que podría ser un "Comando".

... ¿a quién le estás explicando esto?

Si no necesita hacerlo rápido y tener un pedazo de papel disponible, simplemente demuestre todo. SQL es bastante similar al lenguaje natural, así que simplemente realice una consulta simple y demuestre el ataque:

 SELECT * FROM data WHERE key = $id

"$ id se reemplaza por lo que se ve aquí apunta al parámetro de URL . Normalmente, este es un número como 1 . Esto nos da:"

 SELECT * FROM data WHERE id = 1

"Ahora, si alguien pone más que solo un número allí, también se incluye. Por ejemplo, si alguien ingresa 1 OR 1 = 1 , obtenemos esto"

 SELECT * FROM data WHERE id = 1 OR 1 = 1

"¿Puedes ver a dónde va esto? Ahora, en este sistema, también es posible emitir varios comandos, llamados consultas, si los separas con un punto y coma. ¿Puedes adivinar qué sucede si alguien coloca 1; DELETE EVERYTHING; ? "

 SELECT * FROM data WHERE id = 1; DELETE EVERYTHING;

"El comando real es DROP DATABASE o DROP TABLE , pero entiendes la idea".

Creo que el ejemplo más simple, claro y divertido es el de "The Simpsons": las bromas de Bart:

enlace

Ejemplo :

  

Moe: [contestando el teléfono] Moe's Tavern.

     

Bart: Hola, ¿está Al?

     

Moe: Al?

     

Bart: Sí, Al. Apellido: Coholic.

     

Moe: Déjame revisar ... [llamadas] Llamada telefónica para Al. Al Coholic. ¿Hay un Al Coholic aquí? [los clientes del bar se ríen]

     

Moe: Espera un minuto. [al teléfono] Escucha, pequeño idiota de ratas de vientre amarillo. ¡Si alguna vez descubro quién eres, te mato! [cuelga]

     

Bart y Lisa: [risas]

     

Homer: espero que encuentres ese punk algún día, Moe.

¿Cómo es esta una buena analogía? Un "nombre" que se repite descuidadamente sin verificar causa un comportamiento involuntario.

enlace de YouTube a una compilación de esas bromas telefónicas para ayudar a elegir el ejemplo más adecuado.

La inyección SQL es cuando un usuario malintencionado está tratando de obtener información de un sitio web al que no tiene acceso autorizado.

Es como interrogar a otra persona, donde el interrogador es el usuario malintencionado y la persona que está siendo interrogada es el sitio web.

Las cosas que el interrogador podría hacer son:

• Investiga los antecedentes de la persona para encontrar una debilidad
• Use varias técnicas conocidas que han funcionado en el pasado en otras personas
• Encuentra nuevas técnicas para usar

Algunas debilidades de la persona que está siendo interrogada pueden ser:

• La formación de la persona
• La inteligencia de la persona
• La familia de la persona
• El tipo de persona que son

Las cosas a tener en cuenta son que hay mejores interrogadores que otros y algunas personas hablarán de inmediato, mientras que otras quizás nunca.

Bueno, explicar con una analogía técnica está bien, pero sonaría un poco largo y tonto.

Acabo de explicar que se trata de estrictos trámites o requisitos para limitar los abusos en las administraciones y las finanzas.

Si se hace de una manera suficientemente estricta, tienes menos peces malvados que pueden pasar por la red.

Usaría un dibujo simple con un pseudo código muy simple con cajas y flechas, y explicaría los robots y la analogía de la caja.

Mi enfoque para un no técnico:

  

Suponga que está trabajando en un gran edificio de oficinas. Cada empleado tiene una clave propia para su oficina (= consulta SQL que el programador quería ejecutar). Ahora alguien toma un archivo de aguja y modifica su clave un poco, es decir, elimina un pin (= Inyección de SQL, cambiando la consulta de SQL). Esta llave modificada puede abrir diferentes (o tal vez todas las puertas). Por lo tanto, el secretario tiene acceso a más o todas las oficinas dentro de esta casa y puede leer / cambiar documentos de otras oficinas.

Probablemente todos estén acostumbrados a usar llaves y candados, por lo que debería ser fácil de entender y, desde mi punto de vista, es una buena analogía con una inyección de SQL.

Siempre depende de la persona que te escuche, pero así es como se lo explicaré a él / ella.

Imagínese cuando está enviando un telegrama con un mensaje como:

  

"¡Feliz año nuevo! Tenga cuidado. - Fred "

y alguien que no tenga buenas intenciones que pueda acceder a tu telegrama interceptará y reemplazará las palabras resaltadas con -

  

"¡Feliz año nuevo! Envíanos dinero. - Fred "

Espero que ayude! :)

Aquí está mi intento:

Reemplaza "sitio" con "casa" y "atacante | hacker" con "ladrón".

La inyección SQL es el resultado de dejar las ventanas abiertas (* con una luz de neón enorme que dice "ABRIR") de una casa mientras tiene puertas delanteras y traseras de acero inoxidable de 10 "de espesor.

El ladrón quiere forzar y robar su equipo de sonido, pero primero, necesita descubrir cómo romper, ve que las puertas son prácticamente imposibles de romper, sin embargo, si se investiga más a fondo, verá que las ventanas están abrió. No puede robar sus muebles (al menos no en una sola pieza), pero puede robar su equipo de sonido, computadora portátil, PC, etc.

*) un poco dramático, lo sé (: