Por qué existe una inyección: dato y código mezclados

Un intérprete es cualquier componente que recibe texto y lo entiende como instrucciones: un motor de base de datos, un motor de plantillas, el intérprete de órdenes del sistema operativo, un analizador de documentos, un servidor de directorio. Lo que le llega tiene siempre dos partes: la estructura, que dice qué se hace, y los datos, que dicen sobre qué.

Cuando el programa arma una sola cadena uniendo la estructura con un valor que vino de fuera, el intérprete ya no puede distinguirlas: lo que recibe es un texto, y lo lee entero como instrucción. Si ese valor contiene algo con significado para ese intérprete, deja de ser un dato y pasa a formar parte de la instrucción. Eso es una inyección, y es la misma causa en todas sus formas. En el catálogo público de debilidades de MITRE la familia entera cuelga de CWE-74, y cada variante tiene su número debajo.

La consecuencia práctica para el evaluador: el hallazgo no se busca por el nombre de la tecnología, se busca por la forma de armar la instrucción.

El inventario de la editorial marca, para cada punto en el que la plataforma le entrega algo a un intérprete, si la estructura y el dato van en la misma cadena o separados. Esa columna es el mapa del módulo: cada punto marcado es un candidato que las salas siguientes revisan en su propio terreno.

Abre el laboratorio y revísala entera antes de contar.

Dos puntos con la misma forma de armar la instrucción no valen lo mismo. Lo que decide es el origen del dato: un valor que escribe cualquiera en un formulario público está al alcance de todo el mundo; uno que solo puede poner alguien del equipo exige antes una cuenta; y uno que produce y firma la propia aplicación, y cuya firma se comprueba al volver, no lo controla quien lo transporta.

Ese último caso es el que más confunde en los informes, porque el dato viaja por el navegador y parece de fuera. Ordena el inventario por el origen y busca el único que cumple esa condición.

Si la causa es que estructura y dato viajan juntos, la corrección es separarlos: entregar al intérprete la estructura por un lado y los valores por otro, con la interfaz que ese intérprete ofrezca para ello. Casi todos tienen una, y es lo primero que hay que preguntar al revisar.

Hay un caso en el que no se puede, y conviene reconocerlo: cuando lo que la persona elige es parte de la estructura, como el nombre de una plantilla o el de un programa que se va a ejecutar. Ahí no hay valor que separar, y lo que corresponde es una lista cerrada de opciones permitidas en el servidor, donde lo que llega se usa para elegir una entrada de la lista y nunca para construir nada.

Filtrar caracteres sospechosos no entra en ninguno de los dos casos: siempre queda una variante fuera de la lista, y la causa sigue viva.

Con el inventario delante, lo honesto es decir qué se sabe y qué no. Un punto donde la estructura y el dato viajan juntos es una condición necesaria, no una demostración: puede que el intérprete reciba el valor ya tratado un poco más arriba, o que el componente solo lo alcance alguien con una cuenta de administración. Afirmar un impacto sin evidencia que lo sostenga es lo que hace que un informe pierda credibilidad entera por un párrafo.