Todo lo que manda el usuario es sospechoso

Cuando alguien piensa «datos que manda el usuario» piensa en un formulario. Son cuatro sitios, y los tres que no son el formulario son los que se olvidan:

El formulario. Lo evidente: nombre, contraseña, un comentario.

La dirección. Todo lo que va en la URL. ?id=5209 es un dato que mandó quien pidió la página — y cambiarlo a ?id=5210 es tan fácil como escribirlo.

Las cabeceras. Datos que el navegador envía sin que se vean: qué navegador es, de qué página viene, las cookies. Todos se pueden falsificar, porque salen de la máquina del usuario.

Los archivos que sube. Nombre, tamaño, tipo y contenido. El «tipo» que dice el navegador es una declaración, no una comprobación.

Y de ahí sale la regla que da título a la sala, que en el oficio se dice más corta: nunca confíes en la entrada del usuario. No porque los usuarios sean malos — porque cualquiera puede mandar lo que quiera por esos cuatro caminos, y el servidor no tiene forma de saber si vino de tu página o de un programa.

Vuelve al portal de la clínica. Recuerda que mostraba «Historia: 5209», la de Amparo.

Ahora imagina que la dirección de esa página fuera:

/mi-historia?id=5209

¿Qué hace cualquiera que vea eso? Cambiar el número. Poner 5210 y darle a entrar.

Si el servidor coge ese número y devuelve la historia correspondiente sin comprobar nada, acabas de leer la historia clínica de otra persona. Y otra. Y otra. Un programa sencillo recorre diez mil en un rato.

Eso tiene nombre —referencia directa insegura a objetos— y es primo hermano del fallo que ya conoces. Compáralos:

• /agenda-interna → no comprobaba si podías ver ESA PÁGINA
• /mi-historia?id=5210 → no comprobaría si puedes ver ESE DATO

La misma pregunta sin hacer, un nivel más fino. Y la segunda es peor por dos motivos: es más difícil de encontrar revisando, y se ve como tráfico completamente normal — alguien pidiendo su historia, solo que con otro número.

El arreglo tampoco es esconder el número ni cifrarlo. Es preguntar: ¿esta historia es de quien la está pidiendo?

Dos palabras que se confunden todo el tiempo y hacen cosas distintas:

Validar es decidir si un dato es aceptable. ¿La fecha existe? ¿El número está en rango? ¿El correo tiene forma de correo? Si no lo es, se rechaza.

Sanear es tratar un dato para que no cause daño allí donde se va a usar. Y esa última parte es la clave: el mismo texto es inofensivo en un sitio y peligroso en otro.

Un nombre con una comilla —O'Brien— es perfectamente válido. Es un apellido real y hay que aceptarlo. Y es peligroso si se pega dentro de una consulta a la base de datos, porque la comilla ahí es sintaxis.

Por eso la solución no es «prohibir las comillas»: eso rompe a los O'Brien del mundo y sigue sin resolver el problema. La solución es no pegar — mandar la orden por un lado y los datos por otro, para que la base de datos sepa cuál es cuál.

Y la idea general, que vas a reconocer en todas partes:

El peligro no está en el dato. Está en dónde acaba. El mismo texto es inofensivo en un archivo, peligroso en una consulta, y peligroso de otra forma en una página web.

De ahí que se sanee al usar, no al recibir. Guardar un nombre saneado para HTML y luego meterlo en una consulta no te protege de nada — lo saneaste para el sitio equivocado.