Seguir el dato de la fuente al sumidero

La revisión de un flujo de datos tiene tres piezas. La fuente es por donde entra un valor que controla alguien de fuera: un parámetro de la consulta, un campo del cuerpo, una cabecera, una cookie, un archivo subido. El sumidero es el punto donde ese valor se usa de una forma que puede cambiar lo que hace el programa: el texto de una consulta a la base de datos, una orden al sistema operativo, una ruta de archivo, una dirección de redirección, una plantilla. Entre las dos está el camino: las asignaciones, las llamadas y los cambios de nombre por los que pasa el valor.

Un camino deja de ser un hallazgo cuando, antes del sumidero, el valor pasa por un saneamiento adecuado a ese sumidero: convertirlo en número, compararlo con una lista cerrada de valores permitidos, pasarlo como parámetro ligado. Lo que cuenta es que la defensa corresponda al sumidero; escapar comillas no protege una ruta de archivo, y validar el formato de un correo no protege una consulta.

Hay dos formas de recorrer un flujo. Desde la fuente hacia el sumidero: se toma cada valor que entra por una ruta y se sigue. O al revés: se buscan los sumideros (por ejemplo, cada consulta que se arma sumando textos) y se sube hasta ver de dónde sale lo que se suma. En la práctica se combinan; la segunda es la que más rinde cuando el código es grande, porque hay muchos menos sumideros que entradas.

En este servicio la base de datos se usa a través de api/db.js. Léelo primero: dice qué parte de una consulta viaja como parámetro ligado y qué parte se envía tal cual. Después abre el servicio de pedidos y busca la consulta que se arma sumando textos.

Un valor rara vez conserva su nombre de la ruta al sumidero: se asigna a una variable, se pasa como argumento a otra función y dentro de ella se llama de otra forma. Perder el rastro en ese cambio de nombre es el error más común al seguir un flujo a mano. La regla práctica es anotar cada salto: en qué función entra, con qué nombre, y a qué función sale.

En el informe, el hallazgo se ubica en el sumidero, porque es ahí donde se corrige, y se describe el camino completo desde la fuente para que el equipo del cliente lo reproduzca.

El nombre de una columna o el sentido de un orden no se pueden pasar como parámetro ligado: el motor solo liga valores, no partes de la sintaxis. Para esos casos la defensa habitual es una lista cerrada de valores permitidos, comprobada antes de construir la consulta. Muchas veces esa defensa ya está escrita en el repositorio y se usa en un sitio y no en otro. Encontrarla tiene doble valor: confirma que el equipo conoce el problema y da la corrección casi hecha.

Busca en el repositorio cómo ordena la lista de pedidos del panel de administración y compara con el servicio de pedidos del cliente.

Que una consulta use parámetros ligados cierra la inyección, y nada más. El mismo valor puede ser peligroso por otra razón: si el identificador que llega en la dirección decide qué registro se devuelve, la pregunta ya no es si el motor lo interpreta como SQL, sino si el código comprueba que ese registro es del usuario que lo pide. Comparar dos funciones del mismo archivo que leen el mismo tipo de registro suele delatarlo.