Cómo prevenir la inyección de código SQL

Cómo funcionan los ataques de inyección de código SQL

La inyección de lenguaje de consulta estructurada (SQLi) es un ataque de inyección de código que permite al atacante recuperar, manipular o destruir información confidencial ubicada en bases de datos SQL. Estos ataques funcionan al insertar comandos especializados en campos de consulta SQL. Cuando se ejecutan, los comandos pueden permitir al atacante suplantar la identidad de usuarios legítimos, ver o recuperar datos protegidos e incluso obtener acceso root a servidores.

A menudo, los atacantes llevan a cabo SQLi al aprovechar vulnerabilidades en las interfaces de programación de aplicaciones (API) que no pueden diferenciar adecuadamente entre código legítimo y no fiable. Sin la capacidad de detectar comandos o consultas alterados, estas API pueden utilizarse para ejecutar solicitudes maliciosas, como eludir el firewall de aplicación web (WAF) o las medidas de autenticación.

Normalmente, el SQLi se realiza al usar uno de estos tres métodos:

1. La inyección de código SQL en banda utiliza un único canal de comunicación para iniciar y completar un ataque. Los tipos habituales de SQLi en banda incluyen SQLi basado en errores (cuando los mensajes de error ayudan a los atacantes a identificar información crítica sobre la base de datos subyacente) y SQLi basado en uniones (cuando los atacantes utilizan operadores UNION SQL para descubrir vulnerabilidades en la base de datos). Esta es la forma más sencilla y común de SQLi.
2. En cambio, la inyección de código SQL fuera de banda no permite a los atacantes utilizar el mismo canal de comunicación para iniciar y completar un ataque. En cambio, la aplicación en riesgo debe ser capaz de exfiltrar los datos a un punto final remoto bajo el control del atacante, a menudo mediante DNS o solicitud HTTP. Esta es la forma más difícil y menos común de SQLi.
3. La inyección de código SQL inferencial , también llamada SQLi ciega, requiere que el atacante envíe carga malintencionada al servidor objetivo para aprender a explotarlo. Suelen adoptar una de estas dos formas: SQLi ciego basado en booleanos (cuando los atacantes utilizan consultas de tipo verdadero-falso para forzar a un servidor a producir respuestas diferentes) o SQLi ciego basado en el tiempo (cuando los atacantes pueden deducir la misma información a través de variaciones en los tiempos de respuesta del servidor). Esto suele llevar más tiempo que el SQLi en banda, pero puede ser igual de dañino.

Para ver ejemplos reales de consultas de SQL benignas y maliciosas, lee ¿Qué es la inyección de código SQL?

Cómo prevenir la inyección de código SQL

Aunque la inyección de código SQL es una de las amenazas más frecuentes de API, puede evitarse eficazmente con las estrategias de prevención adecuadas. Algunos métodos útiles para evitar la inyección de código SQL incluyen restringir los procedimientos de la base de datos, sanear las entradas de la base de datos y aplicar el acceso con menos privilegios.

Restringir los procedimientos y código de la base de datos

La inyección de código SQL depende en gran medida de la capacidad de un atacante para manipular las entradas de datos y funciones de la base de datos. Al restringir estas entradas y limitar el tipo de procedimientos de base de datos que se pueden realizar, las organizaciones pueden minimizar el riesgo de consultas no autorizadas o maliciosas. Las formas de hacerlo incluyen:

• Aplicación de declaraciones preparadas y consultas parametrizadas: las declaraciones preparadas definen el código SQL aceptable, y luego establecen parámetros específicos para las consultas entrantes. Las declaraciones de SQL maliciosas se clasifican como entradas de datos no válidas y no como comandos ejecutables.
• Utilizar procedimientos almacenados: al igual que las declaraciones preparadas, los procedimientos almacenados son declaraciones de SQL preparadas y reutilizables que pueden recuperarse de una base de datos y evitan que las partes maliciosas ejecuten código directamente en la base de datos.

Validar y sanear las entradas de base de datos

Las entradas de usuario en cualquier base de datos SQL se deben supervisar, validar y sanear periódicamente para eliminar el código malicioso. La validación de la entrada garantiza que los datos se inspeccionen y formateen correctamente según criterios predeterminados, mientras que el saneamiento de la entrada modifica (o "sanea") la entrada al eliminar los caracteres no válidos o no seguros y al reformatearla según sea necesario. Entre las formas en que pude garantizarse la validación de las entradas están:

• Establecer una lista de permitidos: una lista de permitidos puede ayudar a definir entradas de usuario válidas, con las que la base de datos puede comprobar (y rechazar) las consultas entrantes que parezcan anormales. Por ejemplo, los caracteres especiales y las URL extendidas son dos tipos de entradas de usuario que pueden ser explotadas por los atacantes para recopilar información sobre una base de datos (antes de ejecutar consultas maliciosas). Limitar el uso de estas entradas puede ayudar a minimizar la probabilidad de un ataque.
• Escapar de la entrada proporcionada por el usuario: las organizaciones también pueden optar por escapar (es decir; tratar como entrada, en lugar de comandos o condicionales) de toda entrada proporcionada por el usuario, de modo que no se puedan utilizar caracteres o palabras concretas para formar solicitudes maliciosas.

Implementar el acceso con menos privilegios

El acceso con menos privilegios es el principio de dar a los usuarios únicamente el acceso necesario a los recursos protegidos que requiera su función. Por ejemplo, esto puede significar limitar el número de usuarios a los que se conceden privilegios de nivel administrador a una base de datos o incluso dar a los usuarios un acceso temporal de nivel administrador que pueda revocarse posteriormente.

Restringir el acceso de los usuarios a un nivel basado en funciones también ayuda a minimizar el impacto de una violación, ya que los atacantes que accedan a una base de datos mediante credenciales robadas verán igualmente limitada su capacidad de ver, modificar, robar o destruir datos protegidos. Por el misma motivo, las organizaciones deben limitar el acceso compartido a las bases de datos en varios sitios web y aplicaciones.

Cómo Cloudflare ayuda a prevenir la inyección de código SQL

Cloudflare ayuda a las organizaciones a mejorar su resiliencia frente a los ataques SQLi gracias a una eficaz cartera de soluciones de seguridad de las aplicaciones y las API:

• Cloudflare WAF monitorea los patrones de tráfico en busca de posibles explotaciones de SQL, detecta omisiones y variaciones en los tipos de ataque y utiliza tecnologías avanzadas de aprendizaje automático para adaptar los conjuntos de reglas WAF a los métodos de ataque en evolución
• Cloudflare D1 es una base de datos SQL sin servidor que se integra de forma nativa con Workers para implementar declaraciones preparadas y evitar que los usuarios modifiquen o eliminen bases de datos