cómo las tablas Little Bobby arruinaron Internet

hechos curiosos:

la inyección SQL ha existido prácticamente desde que los sitios web han almacenado datos en bases de datos.

el proyecto Open Web Application Security clasificó los ataques de inyección como una de las 10 principales amenazas a las que se enfrentaban las aplicaciones web en 2017.,

la inyección SQL sigue siendo responsable de muchas fugas de datos grandes. En 2016, las bases de datos de registro de Votantes de la Junta Electoral del Estado de Illinois y Arizona fueron violadas. Si bien no se robó ninguna información en Arizona, en Illinois los atacantes tuvieron acceso a los datos de los votantes, incluidos el nombre, la dirección, la fecha de nacimiento, el género y los números parciales de Seguro Social, de unas 80.000 personas.<

Eso es aterrador, ¿Qué es?

la inyección SQL es un tipo de ataque que se dirige a la base de datos de una aplicación mediante la inserción de código no deseado en los campos de entrada del usuario., Al aprovechar la sintaxis SQL, el atacante puede usar campos de entrada para capturar información de esas bases de datos, incluidas cosas como contraseñas y números de tarjetas de crédito. Alguien podría incluso tomar el control de su base de datos o eliminar toda la información que contiene.

¿Cómo funciona?

la inyección SQL funciona mediante el uso de información insertada en un campo para manipular la instrucción SQL correspondiente y realizar una acción no deseada.,

Aquí hay un ejemplo básico:

SELECT * FROM customers WHERE name = " + user_name + ";

en este ejemplo, digamos que la variable user_name se crea directamente a partir de la entrada del usuario en un sitio web. Esa cadena se inserta en la instrucción SQL anterior y se devuelven todos los campos relacionados con ese nombre de usuario. No es gran cosa.

Pero ¿qué pasa si alguien escribe Steve» O 1=1; — como su nombre de usuario? entonces el SQL generado sería el siguiente:

SELECT * FROM customers WHERE name = "Steve" OR 1=1;--";

dado que 1=1 siempre es verdadero, esto devolvería todos los datos de la tabla. No Es Bueno!,

Let’s take one more look at that comic.

The son’s name is Robert’); DROP TABLE students; — What would that do exactly?,

bueno, podemos asumir que si se agregaran tablas Little Bobby a la base de datos de estudiantes de la escuela, la instrucción SQL se vería algo así como:

INSERT INTO students (name) VALUES ('<Student Name>');

… y cuando insertemos Bobby Bobby

INSERT INTO students (name) VALUES ('Robert'); DROP TABLE students;--');

ya que el nombre de Bobby contiene el ); el argumento VALUES se cierra en medio de su nombre y el texto que sigue drop table students es una nueva instrucción SQL que elimina toda la tabla. Finalmente, el-al final comenta el SQL restante, esencialmente ignorando el resto del código original y asegurándose de que no se produzca ningún error.,

, por Lo tanto, Lo Que Dices De Mis Datos Nunca Estarán A Salvo De Nuevo?

No! En realidad, hay muchos pasos que puede tomar para protegerse de este tipo de ataque. Veamos algunos:

1. desinfectar datos. El primer paso es controlar lo que el usuario puede introducir. La mejor manera de hacer esto es limitar los tipos de entrada permitidos para un campo determinado., Por ejemplo, en un campo de número de teléfono solo puede permitir la entrada numérica, o en un campo de correo electrónico solo permitir caracteres que se pueden encontrar en una dirección de correo electrónico válida. Obviamente, algunos campos requerirán personajes que podrían usarse en un ataque, por lo que este método no es imbatible.
2. configurar informes de errores. A menudo, el informe de errores predeterminado en los sistemas de administración de bases de datos tiene información de depuración del desarrollador. Esto puede devolver información útil al atacante, como nombres de tabla o nombres de columna., Asegúrate de no mostrar este tipo de información a usuarios externos, ya que podría facilitar la vida de un potencial atacante.
3. Usar parámetros enlazados. Los parámetros enlazados le permiten almacenar datos de usuario en una variable y luego insertarlos en una instrucción SQL que se ha creado con marcadores de posición. Dado que la instrucción SQL y la variable se envían al servidor por separado, los parámetros enlazados son buenos para proteger contra la inyección. ¡Toma a ese pequeño Bobby T!, Un ejemplo de los parámetros vinculados en un método de actualización en Ruby tendría este aspecto:

def update sql = <<-SQL UPDATE students SET name = ?, grade = ? WHERE id = ? SQL DB.execute(sql, )end

Es una locura pensar que algo tan sencillo y se entiende bien todavía es el responsable de muchas de las grandes brechas de datos., Incluso en casos de alto perfil como los hacks de registro de votantes mencionados anteriormente y la reciente violación de Equifax (que no se debió a la inyección SQL, sino a una vulnerabilidad similar que la compañía no pudo abordar), la raíz de la vulnerabilidad se reduce a un error humano y la falta de atención al detalle. Tomarse el tiempo para pensar detenidamente en el problema puede ayudarnos significativamente a proteger los datos de los usuarios de las infracciones comunes, especialmente las inyecciones SQL.