Inyección SQL

Detrás de la mayoría de los formularios de login y los buscadores hay una base de datos que habla SQL. Cuando buscás 'zapatillas rojas' en una tienda, el sitio arma un comando del estilo buscá productos cuyo nombre contenga: zapatillas rojas y se lo manda a la base. La inyección SQL ocurre cuando el sitio arma ese comando pegando tu texto tal cual. Entonces alguien puede escribir algo que no es una búsqueda sino un pedazo de SQL, y la base no puede distinguir dónde terminan las instrucciones del sitio y dónde empiezan las del visitante.

Según lo que escriba el atacante, el comando alterado puede devolver los datos de todos los clientes en vez de unos productos, saltearse el control de contraseña en un login o modificar información. Es una de las vulnerabilidades web más viejas, estuvo detrás de muchas filtraciones grandes de datos, y OWASP sigue poniendo la inyección entre los riesgos más importantes de las aplicaciones web.

La solución es conocida y no es complicada: nunca armar un comando pegando textos. Los desarrolladores usan consultas parametrizadas (también llamadas prepared statements), donde el comando se escribe primero con un hueco fijo y lo que escribe el usuario se pasa aparte, siempre tratado como un valor y nunca como código. Los frameworks y bibliotecas modernos lo hacen por defecto. Además, la cuenta de base de datos que usa el sitio debería poder hacer solo lo que el sitio necesita, para que un error no se convierta en un desastre.

Como usuario no podés hacer mucho, salvo usar contraseñas distintas para que una filtración en un sitio no abra tus otras cuentas. Si contratás o gestionás un equipo que hace software, vale la pena preguntar si las consultas están parametrizadas y si el código pasó por una revisión de seguridad o una prueba de penetración.