CWE-20

El producto recibe entradas o datos, pero no valida o valida incorrectamente que la entrada tenga las propiedades necesarias para procesar los datos de forma segura y correcta.

La validación de entradas es una técnica de uso frecuente para verificar entradas potencialmente peligrosas con el fin de garantizar que sean seguras para su procesamiento dentro del código, o al comunicarse con otros componentes. Las entradas pueden consistir en: - datos en bruto - cadenas, números, parámetros, contenido de archivos, etc. - metadatos - información sobre los datos en bruto, como encabezados o tamaño. Los datos pueden ser simples o estructurados. Los datos estructurados pueden estar compuestos por muchas capas anidadas, formadas por combinaciones de metadatos y datos en bruto, con otros datos simples o estructurados. Es posible que sea necesario validar muchas propiedades de los datos en bruto o los metadatos al ingresar al código, tales como: - cantidades especificadas como tamaño, longitud, frecuencia, precio, tasa, número de operaciones, tiempo, etc. - cantidades implícitas o derivadas, como el tamaño real de un archivo en lugar de un tamaño especificado - índices, desplazamientos o posiciones dentro de estructuras de datos más complejas - claves simbólicas u otros elementos dentro de tablas hash, arreglos asociativos, etc. - corrección en la formación, es decir, corrección sintáctica - conformidad con la sintaxis esperada - corrección de tokens léxicos - conformidad con las reglas sobre qué se trata como un token - tipo especificado o derivado - el tipo real de la entrada (o lo que la entrada parece ser) - coherencia - entre elementos de datos individuales, entre datos en bruto y metadatos, entre referencias, etc. - conformidad con reglas específicas del dominio, por ejemplo, la lógica de negocio - equivalencia - asegurar que las entradas equivalentes se traten de la misma manera - autenticidad, propiedad u otras atestaciones sobre la entrada, por ejemplo, una firma criptográfica para probar el origen de los datos. Las propiedades implícitas o derivadas de los datos a menudo deben ser calculadas o inferidas por el propio código. Los errores al derivar propiedades pueden considerarse un factor contribuyente a una validación incorrecta de entradas.

Consecuencias comunes

• Disponibilidad → DoS: bloqueo, salida o reinicio, DoS: consumo de recursos (CPU), DoS: consumo de recursos (memoria)
• Confidencialidad → Lectura de memoria, Lectura de archivos o directorios
• Integridad, Confidencialidad, Disponibilidad → Modificación de memoria, Ejecución de código o comandos no autorizados

Mitigaciones

• Arquitectura y diseño: Considere el uso de técnicas de seguridad basadas en la teoría de lenguajes (LangSec) que caracterizan las entradas mediante un lenguaje formal y construyen "reconocedores" para ese lenguaje. Esto requiere efectivamente que el análisis sintáctico sea una capa distinta que imponga un límite entre la entrada en bruto y las representaciones internas de datos, en lugar de permit
• Arquitectura y diseño: Utilice un marco de validación de entradas como Struts o la API de validación de OWASP ESAPI. Tenga en cuenta que el uso de un marco no aborda automáticamente todos los problemas de validación de entradas; esté atento a las debilidades que podrían surgir del uso indebido del propio marco (CWE-1173).
• Arquitectura y diseño, Implementación: Comprenda todas las áreas potenciales donde pueden ingresar entradas no confiables en el producto, incluidas, entre otras: parámetros o argumentos, cookies, cualquier cosa leída de la red, variables de entorno, búsquedas de DNS inverso, resultados de consultas, encabezados de solicitud, componentes de URL, correo electrónico, archivos, nombres de archivo, bas
• Implementación: Suponga que toda entrada es maliciosa. Utilice una estrategia de validación de entradas de tipo "aceptar lo que se sabe que es válido", es decir, use una lista de entradas aceptables que se ajusten estrictamente a las especificaciones. Rechace cualquier entrada que no se ajuste estrictamente a las especificaciones, o transfórmela en algo que sí lo haga. Al realizar la validación de
• Arquitectura y diseño: Para cualquier verificación de seguridad que se realice en el lado del cliente, asegúrese de que estas verificaciones se dupliquen en el lado del servidor, a fin de evitar CWE-602. Los atacantes pueden eludir las verificaciones del lado del cliente modificando los valores después de que se hayan realizado las verificaciones, o cambiando el cliente para eliminar por completo
• Implementación: Cuando su aplicación combina datos de múltiples fuentes, realice la validación después de que las fuentes se hayan combinado. Los elementos de datos individuales pueden pasar el paso de validación pero violar las restricciones previstas una vez que se han combinado.