Cómo razona un analizador estático

Hay dos maneras de razonar dentro de un analizador. La más sencilla busca una forma en el texto del programa: una llamada a una función concreta, un argumento armado de cierta manera. Encuentra rápido lo que se parece al patrón y se equivoca en las dos direcciones: marca lo que se parece pero no es peligroso, y deja pasar lo peligroso escrito de otra forma.

La segunda sigue el recorrido de un dato. La regla declara de dónde vienen los datos que no son de fiar (las fuentes, por ejemplo lo que llega en una petición), dónde serían peligrosos (los sumideros, por ejemplo la función que ejecuta una consulta) y qué funciones los dejan limpios por el camino (los saneadores). El motor solo avisa cuando un dato va de una fuente a un sumidero sin pasar por un saneador. Es más preciso, y tiene una debilidad que conviene no olvidar: confía a ciegas en la lista de saneadores que alguien escribió.

Abre el laboratorio y lee regla-sql.yml: tiene sus fuentes, su sumidero y dos saneadores. Después lee utilidades.py para ver qué hace de verdad cada uno. Uno de los dos deja el dato en un tipo que ya no puede llevar texto libre; el otro solo cambia mayúsculas y espacios, que no tienen nada que ver con la forma de una consulta SQL. Busca en polizas.py la función que arma una consulta con un dato pasado por ese segundo saneador.

El informe dice en su cabecera cómo está configurado el flujo de datos. La documentación del motor de flujo de datos de Semgrep lo describe como intraprocedimental: sigue el dato dentro de una función, no de una función a otra. Cuando un dato de la petición entra en una función y se le pasa como argumento a otra, la segunda lo recibe como un parámetro cualquiera, y para la regla un parámetro no es una fuente.

No es un fallo del motor, es su alcance. El auditor que no lo sabe lee «cero resultados» como «cero problemas». Busca en polizas.py la función que arma una consulta con un valor que le llegó desde otra función, la que sí lo leyó de la petición.

Una regla solo encuentra lo que describe. La de Caobo habla de consultas SQL; nadie escribió una que pregunte si una ruta comprueba que el recurso pedido es de quien lo pide. Ese tipo de fallo —control de acceso por un identificador que elige el usuario, CWE-639— casi nunca tiene una forma reconocible en el texto: depende de una comprobación que falta, y para que un analizador lo vea alguien tiene que contarle cuál es la comprobación que debería estar.

Lee utilidades.py para ver qué comprueba de verdad el decorador de sesión, y busca en polizas.py la ruta que entrega un documento de cualquier número que se le pida.

Con lo que has leído, el informe de una regla y un motor que no cruza funciones no puede sostener la frase «el portal no tiene inyección SQL», y mucho menos «no tiene fallos de código». Lo que sí puede sostener es más modesto y más útil: qué reglas corrieron, qué cubren, qué encontraron y qué puntos ciegos se conocen, con los que ya se encontraron a mano.