Patrones inseguros frecuentes en código asistido

Un asistente de código propone lo que es probable que siga, aprendido de mucho código público. Mucho de ese código público resuelve el problema de la forma más corta, y la forma más corta de que una llamada funcione a menudo es apagar una comprobación: no verificar un certificado, no verificar una firma, pegar una clave en el archivo para la prueba. El resultado compila, pasa las pruebas que escribe el mismo asistente y se ve limpio, que es justo lo que hace que se revise menos.

Hay un patrón propio de los asistentes: proponer dependencias. A veces sugieren un paquete con un nombre plausible que no existe o que existe desde hace pocos días, y un nombre que los asistentes repiten es un buen nombre para que alguien publique un paquete malicioso con él. Por eso una dependencia nueva se mira por su historia y no por su nombre, y entra solo por el mismo proceso que cualquier otra.

Abre el laboratorio. El diff añade una línea a requirements.txt. Cruza ese paquete con dependencias-412.txt (cuándo se publicó, cuántas versiones tiene, quién lo publica, cuántas descargas) y con paquetes-aprobados.txt. En la lista aprobada ya hay una librería conocida para leer libros electrónicos.

Lee en diff-412.txt el archivo nuevo que envía los pedidos al distribuidor. Tiene dos problemas en la misma llamada: la clave del distribuidor escrita en el código (aquí con un marcador ficticio) y la verificación del certificado desactivada, que deja la conexión abierta a quien se interponga en el camino. Son dos de los atajos más repetidos en código generado para «que funcione».

En el mismo diff hay dos funciones que decodifican tokens JWT. Una indica la llave pública, el algoritmo permitido y la audiencia esperada: verifica. La otra lee el contenido del token con la verificación de la firma desactivada y devuelve el identificador del socio tal cual, así que cualquiera que escriba un token a mano puede decir que es el socio que quiera.

pruebas-412.txt da cuatro de cuatro y un 92 % de cobertura. La última línea dice lo que esas cifras no cuentan. Una prueba de seguridad comprueba que lo que debe fallar falla: un token alterado, uno sin firma, uno caducado. Ninguna de las cuatro lo hace, y la que prueba el envío al distribuidor usa un servidor simulado que no puede detectar que se dejó de verificar el certificado.