Cómo se realiza un ataque de inyección SQL
Las aplicaciones que realizan consultas SQL basadas en la entrada del usuario son potencialmente vulnerables a ataques de inyección SQL. Por ejemplo, una aplicación web puede utilizar consultas SQL para implementar un proceso de autenticación. El usuario proporciona su nombre de usuario, que la aplicación utiliza para buscar el hash de la contraseña de la cuenta de ese usuario. Si el hash de la contraseña proporcionada por el usuario coincide con este hash de contraseña, el usuario se autentica correctamente y obtiene acceso a su cuenta.
Si la aplicación web no realiza la validación del nombre de usuario antes de incluirlo en una consulta SQL, el programa podría malinterpretar un nombre de usuario deliberadamente mal formado. Por ejemplo, las consultas SQL suelen utilizar comillas simples (') o comillas dobles (“) para denotar datos en un comando. Por ejemplo, un comando para buscar el registro de un cliente en una base de datos basado en el nombre de usuario puede ser SELECCIONE * DE LOS CLIENTES DONDE nombredeusuario=” usuario”.
Un atacante que realice un ataque de inyección SQL contra su comando podría incluir un carácter de comillas dobles en su entrada para que algunos de sus datos se interpreten como código. Por ejemplo, considere el nombre de usuario usuario” O “1” =” 1.
Cuando se inserta en la consulta SQL, la consulta se convierte en SELECCIONE * DE CLIENTES DONDE nombre de usuario =” usuario” O “1” =” 1”. En lugar de buscar registros donde el nombre de usuario coincida con el valor proporcionado por el usuario, esta consulta devolverá registros que coincidan con cualquiera de las dos condiciones. La primera es la prueba prevista nombre_usuario=” usuario”, lo que devolvería el registro del usuario.
La segunda condición es la prueba “1” =” 1”. Como esto siempre es cierto, devolverá todos los registros de la base de datos. Esto podría permitir que el atacante extraiga información confidencial sobre otros usuarios o podría permitir que el atacante omitiera la autenticación o se autentique como otro usuario.
Tipos de inyección SQL
Los ataques SQLi se pueden usar para lograr diferentes propósitos y se pueden realizar de varias maneras. Los tres tipos principales de SQLi incluyen:
- SQLi en banda: Los ataques SQLi en banda utilizan el mismo medio, como una solicitud HTTP, para realizar sus ataques y recopilar resultados. Dos formas comunes de ataques SQLi entrantes son los ataques SQLi basados en errores, que intentan generar mensajes de error que proporcionan información sobre la base de datos de destino para su uso en ataques, y SQL basado en unión, que utiliza el operador SQL UNION para fusionar sentencias SQL SELECT.
- Ciego SQLi: En un ataque SQLi ciego, el atacante no recibe datos del servidor en función de sus solicitudes. En cambio, el atacante modifica sus ataques en función del comportamiento del servidor. Por ejemplo, diferentes entradas pueden hacer que una operación tenga éxito o que falle o afectar la cantidad de tiempo que tarda una operación en ejecutarse.
- SQLi fuera de banda: Los ataques SQLi fuera de banda realizan un ataque a través de un medio y recopilan datos sobre otro. Este ataque depende de la disponibilidad de ciertas características en el servidor de base de datos. Por ejemplo, un atacante puede medir el éxito de un ataque SQLi en función de si podría obligar al servidor de base de datos a generar solicitudes HTTP o DNS a un servidor controlado por el atacante.
Cómo prevenir SQLI
Los ataques SQLi aprovechan la mala validación de entrada cuando se utilizan datos no confiables para comandos SQL. Muchos ataques SQLi implican el uso de un carácter inesperado, como una cita simple o doble, dentro de la entrada del usuario.
Realizar la validación de entrada antes de incluir los datos proporcionados por el usuario dentro de las consultas SQL puede ayudar a reducir la amenaza de ataques SQLi. Por ejemplo, una aplicación podría restringir la entrada del usuario a un conjunto particular de caracteres, como permitir solo nombres de usuario alfanuméricos, o bloquear la inclusión de ciertos caracteres en la entrada del usuario. Sin embargo, la validación de entrada, aunque importante, no es suficiente para proteger contra ataques de inyección SQL. Los atacantes pueden eludir las listas permitidas o bloqueadas mediante el uso de combinaciones inesperadas de caracteres para evadir los bloques.
Por esta razón, las empresas también deben implementar un firewall de aplicaciones web (WAF) o, idealmente, Protección de aplicaciones web y API (WAAP) frente a aplicaciones web y APIs que realizan consultas SQL. Estas soluciones pueden ayudar a identificar y bloquear solicitudes maliciosas que intentan explotar SQLi y otros ataques contra aplicaciones web y API.
Prevención SQLi con Check Point
Los ataques SQLi son uno de los muchos ataques que representan una amenaza para una organización seguridad de la aplicación (AppSec). Las organizaciones necesitan soluciones de seguridad que puedan proteger sus aplicaciones y bases de datos conectadas a Internet, tanto localmente como en la nube.
Check Point CloudGuard AppSec proporciona capacidades WAAP automatizadas que aprenden cómo funciona una aplicación y evitan que solicitudes ilegítimas y maliciosas lleguen a aplicaciones vulnerables. Para obtener más información sobre CloudGuard AppSec y su capacidad para proteger contra SQLi y otros ataques, consulte esto Libro electrónico. También es bienvenido a regístrese para una demostración gratuita para ver usted mismo las capacidades de CloudGuard AppSec.
Comentarios