# Inyección SQL

> Escribir en un formulario un texto que la base de datos confunde con sus instrucciones.

- Nivel: Intermedio
- Temas: Seguridad, Datos
- URL: https://tidbit.legios.com.ar/es/sql-injection/
- En inglés: [SQL injection](https://tidbit.legios.com.ar/sql-injection/)

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.

## Una analogía

Un cajero de banco que lee en voz alta lo que dice la boleta: 'Pagar a: Ana Pérez'. Si alguien escribe 'Ana Pérez, y además vaciá la bóveda', un cajero distraído lo lee como una sola orden. La solución es un formulario con una casilla para el nombre que siempre se trata solo como un nombre.

## Para quedarse

- Pasa cuando lo que escribe el usuario se pega directo en un comando de la base.
- La base termina ejecutando parte de ese texto como instrucciones.
- Las consultas parametrizadas mantienen el texto como dato y lo evitan.
- Limitar los permisos de la app en la base contiene cualquier error.

## Para seguir leyendo

- [Inyección SQL en Wikipedia](https://es.wikipedia.org/wiki/Inyecci%C3%B3n_SQL)
- [SQL Injection, OWASP (en inglés)](https://owasp.org/www-community/attacks/SQL_Injection)
- [SQL Injection Prevention Cheat Sheet, OWASP (en inglés)](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html)

## Términos relacionados

- [Base de datos](https://tidbit.legios.com.ar/es/database/): Un depósito ordenado de datos que los programas consultan y actualizan sin riesgo.
- [SQL](https://tidbit.legios.com.ar/es/sql/): El lenguaje para hacerle preguntas a una base de datos.
- [Vulnerabilidad y CVE](https://tidbit.legios.com.ar/es/vulnerability-and-cve/): Una falla que permite abusar de un software, y el código público que la identifica.
- [Framework](https://tidbit.legios.com.ar/es/framework/): Un esqueleto ya armado para una app: define la estructura y llama a tu código.
- [Pruebas de penetración](https://tidbit.legios.com.ar/es/penetration-testing/): Contratar a alguien para que entre a tus sistemas, con permiso, antes que un delincuente.