Consultas NoSQL construidas con objetos del usuario

En las bases de documentos el filtro de una consulta se escribe como un objeto: claves que son campos y valores que son lo que se busca. Esa forma evita de entrada el problema clásico de pegar texto en una cadena de consulta, y por eso se repite la idea de que «aquí no hay inyección». La idea es falsa a medias: lo que se mezcla ya no es texto con texto, sino estructura con estructura.

El motor acepta que el valor de un campo sea un dato simple o un objeto con operadores de comparación —mayor que, distinto de, existe, coincide con una expresión—. Si el valor del filtro llega tal cual desde el cuerpo de la petición, quien manda la petición decide cuál de los dos envía, y con ello cambia el significado de la consulta sin tocar una sola letra del código. MITRE lo agrupa en CWE-943, de nivel clase, sobre los elementos especiales en la lógica de una consulta de datos; el catálogo nombra expresamente las consultas de documentos.

Hay una segunda variante, más silenciosa: copiar la consulta entera recibida dentro del filtro del servidor. Ahí no se discute el tipo de un valor, se discute quién escribe el filtro.

Abre el laboratorio y lee la carpeta tinajal-nosql. El proyecto ya tiene escrita la defensa: un archivo de utilidades con una función que devuelve el valor solo si de verdad es una cadena de texto. Una de las rutas de pedidos la usa. La ruta de ingreso, no.

El registro de ingresos no guarda valores: guarda el tipo de lo que llegó en cada campo, que es lo que la política de la empresa permite anotar. Eso basta para separar el ruido de lo que importa. Busca la línea donde el resultado es correcto y el tipo de lo recibido no es el que una pantalla de ingreso puede producir.

Para el informe hace falta una cifra, no una impresión. Cuenta las peticiones de ingreso del registro en las que al menos uno de los dos campos llegó con un valor que no era texto, sin importar cómo terminaron.

La ruta de ingreso y el buscador de pedidos fallan por motivos distintos y se corrigen distinto. En el ingreso, el filtro lo arma el servidor y de fuera solo entra un valor con su tipo comprobado. En el buscador, el problema es que el filtro del servidor se completa con lo que mande el cliente: la corrección es leer campo por campo los filtros permitidos y construir el objeto con ellos, con el inquilino puesto por el servidor y sin posibilidad de que nadie lo reemplace.