Salidas hacia consultas y comandos

Que un asistente traduzca una pregunta en lenguaje natural a una consulta es cómodo, y por eso es habitual. El diseño frágil es dejar que el modelo escriba el texto de la consulta y pegarlo tal cual, o pegar su filtro dentro de una consulta escrita por el equipo: cualquier condición que el modelo añada, porque se equivocó o porque un documento lo empujó, se ejecuta con los permisos de la aplicación. Es la inyección en consultas de siempre (CWE-89 en el catálogo de MITRE), con el modelo como intermediario.

El diseño robusto separa las dos cosas. El modelo no escribe código de consulta: elige entre opciones cerradas (qué campo filtrar, de una lista; qué operación, de una lista) y propone valores. El código de la aplicación construye la consulta con esas piezas y pasa los valores como parámetros, que la base de datos trata siempre como datos y nunca como parte de la instrucción. Si el modelo propone algo fuera de la lista, la consulta no se construye.

Consulta el inventario de consumidores. Cada fila dice qué toma de la salida, para qué lo usa y cómo construye la consulta o la orden. Uno de los consumidores que consultan una base de datos lo hace bien: campo de lista cerrada y valor como parámetro. El otro no.

Localiza el consumidor que lleva el texto del modelo dentro de una consulta a una base de datos.

Cuando una consulta construida así se desvía, el efecto se ve en los números: devuelve muchas más filas de las que pedía el usuario, porque la condición añadida amplía el alcance. El registro de consultas generadas anota, para cada una, cuántas filas se esperaban al rehacer el pedido a mano y cuántas devolvió de verdad. Esa diferencia es la primera medida del daño: cuántos registros vio alguien que no debía.

Fíjate también en la consulta que el sistema rechazó antes de ejecutarla: es la lista cerrada del buscador haciendo su trabajo. Después localiza la consulta desviada y calcula cuántas filas devolvió de más.

El caso más grave es el de un texto del modelo que termina en una orden del sistema operativo. Si la orden se lanza a través de un intérprete de órdenes y el texto se pega dentro, los caracteres que ese intérprete trata como separadores o sustituciones convierten un título en otra orden (la debilidad CWE-78 del catálogo de MITRE). Aquí el daño no se limita a leer de más: puede ejecutarse cualquier cosa con los permisos del proceso.

El inventario muestra dos consumidores que lanzan programas. Uno pasa el valor como argumento de un programa fijo, sin intérprete, y además valida su formato. El otro no. Localiza qué campo de la salida acaba dentro de la orden.

La corrección no es «limpiar» el título quitando caracteres raros: cualquier lista de caracteres prohibidos se queda corta. La corrección es estructural, igual que en las consultas. Primero, no usar un intérprete de órdenes: lanzar un programa fijo y pasarle los valores como una lista de argumentos, de modo que ninguno se interprete. Segundo, validar el valor contra lo que se espera (un formato, una longitud, una lista de permitidos). Tercero, que el proceso corra con el permiso mínimo, para que un fallo restante tenga poco alcance. Mejor aún si el título ni siquiera hace falta en la orden y se escribe dentro del archivo del reporte.