Inyeccion SQL
Inyeccion SQL
Tipos de inyección
Según la forma de acceso a los datos de backend y la extensión del posible daño provocado,
las inyecciones de SQL se pueden dividir en las siguientes tres categorías:
SQLi en banda:
Este tipo de ataque SQLi es sencillo para los atacantes, porque usan el mismo canal de
comunicación para lanzar ataques y obtener resultados. Este tipo de ataque SQLi tiene dos
subvariantes:
SQLi basado en errores: la base de datos genera un mensaje de error por las acciones del
atacante. El atacante obtiene información sobre la infraestructura de la base de datos en
función de los datos que generaron estos mensajes de error.
SQLi basado en unión: el atacante usa el operador UNION SQL para obtener los datos
deseados mediante la fusión de varias declaraciones Select en una única respuesta HTTP.
SQLi inferencial (también conocida como inyección de SQL ciega):
En este tipo de SQLi, los atacantes usan patrones de respuesta y comportamiento del servidor
después de enviar cargas útiles de datos para obtener más información sobre su estructura.
Los datos no se transfieren de la base de datos del sitio web al atacante, así que el atacante no
ve la información sobre el ataque en banda (por eso se usa el término “SQLi ciega”). La SQLi
inferencial se puede clasificar en dos subtipos:
SQLi basado en el tiempo: los atacantes envían una consulta de SQL a la base de datos, esto
hace que la base de datos espere unos segundos antes de responder si la consulta es
verdadera o falsa.
SQLi booleana: los atacantes envían una consulta de SQL a la base de datos, así permiten que
la aplicación responda mediante la generación de un resultado verdadero o falso.
SQLi fuera de banda:
Este tipo de ataque de SQL se puede llevar a cabo en las siguientes dos situaciones:
Cuando los atacantes no pueden usar el mismo canal para lanzar el ataque y compartir
información; o
cuando un servidor es demasiado lento o inestable para realizar estas acciones.
Para esta prueba, tomamos en cuenta el sitio web de una empresa llamada TaskUS, una
empresa de sector BPO de origen americano, la cual tiene sede en la ciudad de Cali Colombia.
Para las pruebas utilizamos la web PageSpeed.
PROPUESTAS PARA LA PROTECCIÓN DEL SITIO WEB
Una propuesta para la protección de sitio es hacer revisión del código fuente del sitio, este es el
más fundamental al momento de crear capas de seguridad.
Otra propuesta sería crear un cortafuegos contra ataques de ciberseguridad.
También se pueden utilizar estrategias más enfocadas a la protección de fuga de datos como
por ejemplo:
Uso de sentencias preparadas (con consultas parametrizadas): este método de sanear las
entradas de la base de datos implica obligar a los desarrolladores a definir primero todo el
código SQL y, a continuación, a pasar solo parámetros específicos a la consulta SQL; los datos
introducidos reciben explícitamente un alcance limitado que no pueden sobrepasar. Esto
permite que la base de datos distinga entre los datos que se introducen y el código que se va a
ejecutar, independientemente del tipo de datos introducidos en el campo de entrada. Algunas
bibliotecas de asignación objeto-relacional (ORM) se suelen utilizar para este propósito, ya que
algunas versiones sanean las entradas de la base de datos automáticamente.
Eludir toda la entrada suministrada por el usuario: cuando se escribe SQL, algunos caracteres o
palabras específicas tienen un significado particular. Por ejemplo, el carácter '*' significa
"cualquiera" y la palabra "O" es un condicional. Para evitar que los usuarios introduzcan estos
caracteres de forma accidental o malintencionada en una solicitud de la API a la base de datos,
se puede eludir la entrada suministrada por el usuario. Eludir un carácter es la forma de decirle
a la base de datos que no lo analice como un comando o condicional, sino que lo trate como
una entrada literal.
Uso de procedimientos almacenados: aunque no es una estrategia de seguridad robusta por sí
misma, los procedimientos almacenados pueden ayudar a limitar el riesgo asociado a la
inyección de código SQL. Al limitar adecuadamente los permisos de la cuenta de la base de
datos que ejecuta las consultas SQL, incluso el código de aplicación no robusto que es
vulnerable a la inyección SQL carecerá de los permisos necesarios para manipular tablas de la
base de datos no relacionadas. Los procedimientos almacenados también pueden comprobar el
tipo de los parámetros de entrada, impidiendo que se introduzcan datos que incumplan el tipo
que el campo está diseñado para recibir. En los casos en que las consultas estáticas sean
insuficientes, los procedimientos almacenados suelen evitarse.
Aplicar el mínimo privilegio: como regla general, en todos los casos en los que un sitio web
necesite utilizar SQL dinámico, es importante reducir la exposición a la inyección de código SQL
limitando los permisos al ámbito más estrecho necesario para ejecutar la consulta pertinente.
En su forma más obvia, esto significa que una cuenta administrativa no debería, en ningún
caso, ejecutar comandos SQL como resultado de una llamada a la API de una solicitud no
autorizada. Aunque los procedimientos almacenados se utilizan mejor para las consultas
estáticas, la aplicación de los privilegios mínimos puede ayudar a reducir los riesgos de las
consultas SQL dinámicas.
BIBLIOGRAFÍA