Inyección SQL SQLi

Qué es la inyección SQL

Tienes una tienda en línea. Un visitante escribe algo extraño en el buscador, pulsa Enter y la página le muestra el nombre, el teléfono y el historial de pedidos de todos tus clientes. Nadie robó una contraseña. Escribió las palabras justas en el lugar equivocado, y tu sitio hizo el resto. Eso es una inyección SQL.

La mayoría de los sitios guardan su información en una base de datos: un almacén ordenado de tablas, parecido a un conjunto de hojas de cálculo. Para leer o cambiar esa información, el sitio usa un lenguaje llamado SQL (Structured Query Language). Cada petición que envía es una consulta, por ejemplo "busca al cliente que tiene este correo".

La inyección SQL ocurre cuando un sitio toma lo que escribe un visitante y lo pega tal cual dentro de una de esas consultas. Si el visitante escribe SQL en lugar de texto normal, la base de datos no nota la diferencia y sigue la orden del atacante como si el sitio la hubiera escrito. Mucha gente acorta el nombre a SQLi.

Cómo funciona un ataque de inyección SQL

Piensa en un empleado de banco que pasa a los encargados de la bóveda, palabra por palabra, cualquier nota que le entregue un cliente. Una nota normal dice "muéstrenme mi saldo". Una nota tramposa dice "muéstrenme mi saldo y, de paso, abran todas las cajas fuertes". Si el empleado nunca lee la nota antes, los encargados obedecen.

En un sitio web, los pasos suelen ser estos:

1. El atacante busca un lugar que envíe texto a la base de datos: un formulario de inicio de sesión, un buscador, un formulario de contacto o la propia dirección web, como la página de un producto que termina en "?id=25".
2. Escribe un pequeño trozo de SQL en lugar de texto normal. Un ejemplo muy conocido es escribir ' OR '1'='1 en el campo de contraseña de un formulario de acceso.
3. El sitio une ese texto a su propia consulta sin revisarlo. Ahora la consulta pide algo como "deja entrar a esta persona si la contraseña es correcta, o si 1 es igual a 1".
4. Como 1 siempre es igual a 1, la base de datos responde que sí, y el atacante entra sin saber ninguna contraseña.

Hay ataques más silenciosos. En una inyección SQL ciega, la página no muestra ningún dato, así que el atacante le hace a la base de datos preguntas de sí o no y mira cómo reacciona la página, o cuánto tarda en cargar. Hacerlo a mano es lento, y por eso los atacantes usan herramientas automáticas gratuitas que lo hacen por ellos.

Qué puede hacer un atacante

Cuando la base de datos ya sigue sus órdenes, el daño depende de lo que tenga permitido hacer la cuenta de base de datos del sitio. Muchas veces es mucho más de lo que el sitio necesita. Un atacante podría:

• leer datos privados, como nombres, direcciones, correos e historial de pedidos de los clientes, historias clínicas o contraseñas guardadas
• entrar como otro usuario, incluso como administrador
• cambiar datos, como precios, saldos o el estado de los pedidos
• borrar tablas enteras, o la base de datos completa
• en algunos casos, llegar al propio servidor y dejar en él archivos dañinos

Por qué le importa a tu negocio

La inyección SQL es uno de los ataques web más antiguos, y sigue presente. OWASP, una comunidad abierta que publica la conocida lista OWASP Top 10 de riesgos de las aplicaciones web, lleva años incluyendo la inyección en esa lista. Es fácil de intentar, y muchos sitios todavía tienen algún formulario olvidado que la deja pasar.

Para quien dirige un negocio, el costo real casi nunca es técnico. Es una lista de clientes filtrada, una tienda que vende a un precio equivocado, un sistema de reservas que pierde una semana de citas o un mensaje que tienes que enviar a tus clientes para decirles que sus datos quedaron expuestos. En muchos países, leyes de protección de datos como el RGPD (GDPR) también te exigen proteger los datos personales e informar de las filtraciones.

¿Cada formulario de tu sitio se hizo pensando en esto? Los sitios armados deprisa con plugins viejos, o modificados por muchas manos a lo largo de los años, tienen más probabilidades de esconder un punto débil.

Cómo proteger un sitio web de la inyección SQL

La solución principal es bien conocida y funciona. Casi toda la protección está en cómo se construye el sitio, así que son buenas preguntas para tus desarrolladores o tu proveedor.

• Sentencias preparadas. También se llaman consultas parametrizadas. El sitio envía la consulta y el texto del visitante por separado, de modo que la base de datos siempre trata ese texto como un dato y nunca como una orden. Es la defensa principal. Los frameworks modernos como Laravel lo hacen por defecto cuando los desarrolladores usan sus herramientas de base de datos integradas.
• Revisión de entradas. Un campo de teléfono debería aceptar solo números, y un campo de fecha, solo fechas. Rechazar pronto las entradas extrañas cierra muchas puertas.
• Mínimo privilegio. La cuenta que usa el sitio para llegar a la base de datos solo debería tener los permisos que necesita. Una página de búsqueda pública no tiene ningún motivo para borrar tablas.
• Mensajes de error discretos. Un error detallado de la base de datos en pantalla le da un mapa al atacante. Muestra a los visitantes un mensaje corto y sencillo, y guarda los detalles en registros privados.
• Actualizaciones. Mantén al día la plataforma, los plugins y las librerías, porque las versiones viejas suelen tener fallos conocidos.
• Un firewall de aplicaciones web. Es un filtro delante del sitio que bloquea muchos patrones de ataque conocidos antes de que lleguen a tu código. Ayuda, pero no repara el código inseguro.
• Pruebas periódicas. La prueba de penetración (un ataque seguro y planificado por expertos) y el escaneo de vulnerabilidades encuentran los puntos débiles antes que un atacante.

Así se comparan algunos hábitos del día a día:

Errores frecuentes

• Confiar en las revisiones del navegador. Las revisiones que corren en el propio dispositivo del visitante son fáciles de saltar, así que el servidor debe revisarlo todo otra vez.
• Creer que un sitio pequeño está a salvo. Las herramientas automáticas revisan una enorme cantidad de sitios sin fijarse en su tamaño.
• Arreglar un formulario y olvidar los demás. El buscador, los filtros, la dirección web y la API detrás de una aplicación móvil necesitan el mismo cuidado.
• Guardar las contraseñas como texto plano. Si hay una filtración, las contraseñas guardadas con un hash fuerte (convertidas en un código revuelto que no se puede volver a leer) son mucho más difíciles de usar.
• Confiar solo en un firewall. Un filtro te da tiempo. La consulta insegura que hay detrás igual hay que corregirla.

Cómo podemos ayudarte

En Linkysoft, buscar inyecciones SQL es parte de nuestros servicios de ciberseguridad. Hacemos ataques simulados y seguros sobre tu sitio, tu aplicación y tu API, revisamos el código y te entregamos una lista en lenguaje claro con lo que encontramos y cómo arreglarlo. Después de los arreglos, volvemos a probar. Esto sirve también para sitios creados por otros equipos, y la revisión de seguridad gratuita es un primer paso sencillo.

¿Planeas un sistema nuevo? Nuestras aplicaciones web y sistemas de gestión son seguros desde el diseño, con refuerzo según el OWASP Top 10 y pruebas de penetración antes del lanzamiento.