Rompe la consulta con una comilla

En la sala anterior escribiste esto a mano:

SELECT * FROM citas WHERE documento = '····5209'

Pero el portal no tiene ese número escrito. Lo recibe de quien usa la aplicación y lo pega dentro de la frase. En el código sería algo así:

consulta = "SELECT * FROM citas WHERE documento = '" + loQueEscribio + "'"

Léelo despacio, porque ahí está todo el problema: la frase se construye juntando texto. Y una parte de ese texto viene de fuera.

Si escribo ····5209, la frase queda bien. Pero yo no tengo por qué escribir un documento. Puedo escribir lo que quiera, incluida una comilla — que en SQL no es una letra, es el carácter que cierra un texto.

Y cuando el dato trae el carácter que cierra el texto, deja de estar dentro del texto. Pasa a formar parte de la orden.

Vas a escribir lo que escribiría un atacante en la casilla del documento. En vez de un número:

' OR '1'='1

Pégalo mentalmente en la frase de antes y mira qué queda:

SELECT * FROM citas WHERE documento = '' OR '1'='1'

Escribe esa consulta completa en la consola y ejecútala.

Cuatro filas. Donde debería haber una.

Lo que pasó, en palabras: la condición original —«el documento es igual a nada»— es falsa para todas las filas. Pero se le añadió OR '1'='1', que es verdadera siempre. Y una condición falsa o una verdadera es verdadera. Así que el filtro dejó de filtrar.

No hubo contraseñas rotas ni ningún fallo del motor de base de datos. La base de datos hizo exactamente lo que le pidieron. El problema es que quien lo pidió no era quien creía la aplicación.

En la nota está el código del hallazgo.

Lo que acabas de hacer devolvió cuatro filas de una agenda. En un sistema real, la misma técnica llega mucho más lejos, y conviene saber hasta dónde para graduar bien un hallazgo:

Leer lo que no te toca. Es lo que hiciste. Escalado: la tabla de usuarios, la de historias clínicas, la base entera.

Saltarse el inicio de sesión. Si la comprobación de la contraseña es una consulta que pregunta «¿existe un usuario con este nombre y esta clave?», una condición siempre verdadera la hace decir que sí.

Escribir, no solo leer. Según cómo esté montado, se pueden encadenar órdenes que modifican o borran. Ahí ya no es confidencialidad: es integridad y disponibilidad, las otras dos patas.

Y ahora la conexión que cierra el módulo con el 3. Recuerda el archivo de configuración de la sala integradora, el que tenía la contraseña en texto plano: era la de root, el usuario que puede todo en la base.

Si la aplicación se conecta como root, una inyección puede hacer cualquier cosa. Si se conecta con un usuario que solo puede leer tres tablas, la misma inyección solo llega hasta ahí.

Eso es el permiso mínimo otra vez, y explica por qué se repite tanto en esta ruta: no evita el fallo, decide cuánto duele.

La reacción intuitiva es «prohibir las comillas». Ya viste en el módulo 5 por qué no sirve: rompe a los O'Brien y sigue sin resolver nada, porque hay muchas formas de escribir lo mismo.

El arreglo de verdad es dejar de pegar.

Se le manda a la base de datos la frase con un hueco, y el dato por separado:

SELECT * FROM citas WHERE documento = ?

…y aparte, el valor. La base de datos recibe dos cosas distintas y sabe cuál es cuál: la frase es la orden, el valor es un dato y nunca se va a leer como orden, tenga las comillas que tenga.

Se llaman consultas parametrizadas, y son la única solución completa. No es una capa de filtrado que puede fallar: es que el dato ya no está en el canal de las órdenes.

Fíjate en que es el mismo principio que has visto en toda la ruta, en otro traje:

• El cliente manda sugerencias; el servidor decide → separar quién decide
• Los datos van por un canal, las órdenes por otro → separar qué es cada cosa

Y la frase que resume el módulo entero:

Todo intérprete que reciba datos y órdenes por el mismo canal se puede confundir. La solución nunca es filtrar mejor: es separar los canales.