Por diseño, el OWASP Top 10 se limita de forma innata a los diez riesgos más importantes. Cada OWASP Top 10 tiene riesgos “en la cúspide” considerados extensamente para su inclusión, pero al final, no lo lograron.
Independientemente de cómo intentáramos interpretar o torcer los datos, los otros riesgos eran más frecuentes e impactantes.
Las organizaciones que trabajan para lograr un programa Appsec maduro o las consultorías de seguridad o los proveedores de herramientas que desean ampliar la cobertura de sus ofertas, vale la pena identificar y remediar los siguientes cuatro problemas.
Problemas de calidad del código
- Descripción: Los problemas de calidad del código incluyen defectos o patrones de seguridad conocidos, reutilización de variables para múltiples propósitos, exposición de información confidencial en la salida de depuración, errores de uno en uno, condiciones de carrera de tiempo de verificación/tiempo de uso (TOCTOU), errores de conversión firmados o sin firmar, usar después de gratis, y más. El sello distintivo de esta sección es que, por lo general, se pueden identificar con banderas de compilación estrictas, herramientas de análisis de código estático y complementos IDE de linter. Los lenguajes modernos por diseño eliminaron muchos de estos problemas, como el concepto de propiedad y préstamo de memoria de Rust, el diseño de subprocesos de Rust y la estricta verificación de límites y escritura de Go.
- Como prevenir: Habilite y use las opciones de análisis de código estático de su editor y lenguaje. Considere usar una herramienta de análisis de código estático. Considere si es posible usar o migrar a un lenguaje o marco que elimine las clases de errores, como Rust o Go.
- Ejemplos de escenarios de ataque: Un atacante podría obtener o actualizar información confidencial explotando una condición de carrera utilizando una variable compartida estáticamente en varios subprocesos.
Referencias
Negación de servicio
- Descripción: La denegación de servicio siempre es posible con los recursos suficientes. Sin embargo, las prácticas de diseño y codificación tienen una influencia significativa en la magnitud de la denegación de servicio. Supongamos que cualquier persona con el vínculo puede acceder a un archivo de gran tamaño, o si se produce una transacción computacionalmente costosa en cada página. En ese caso, la denegación de servicio requiere menos esfuerzo para llevar a cabo.
- Como prevenir: Código de prueba de rendimiento para CPU, E/S y uso de memoria, rediseñar, optimizar o almacenar en caché operaciones costosas. Considere los controles de acceso para objetos más grandes para garantizar que solo las personas autorizadas puedan acceder a archivos u objetos grandes o servirlos mediante una red de almacenamiento en caché perimetral.
- Ejemplos de escenarios de ataque: Un atacante podría determinar que una operación tarda entre 5 y 10 segundos en completarse. Cuando se ejecutan cuatro subprocesos simultáneos, el servidor parece dejar de responder. El atacante utiliza 1000 subprocesos y desconecta todo el sistema.
- Referencias
Errores de gestión de memoria
- Descripción: Las aplicaciones web tienden a escribirse en lenguajes de memoria administrada, como Java, .NET o node.js (JavaScript o TypeScript). Sin embargo, estos lenguajes están escritos en lenguajes de sistemas que tienen problemas de administración de memoria, como desbordamientos de búfer o montón, uso después de liberar, desbordamientos de enteros y más. A lo largo de los años, ha habido muchos escapes de sandbox que demuestran que solo porque el lenguaje de la aplicación web es nominalmente “seguro” para la memoria, las bases no lo son.
- Como prevenir: Muchas API modernas ahora están escritas en lenguajes seguros para la memoria, como Rust o Go. En el caso de Rust, la seguridad de la memoria es una característica crucial del lenguaje. Para el código existente, el uso de indicadores de compilador estrictos, tipado fuerte, análisis de código estático y pruebas de fuzz pueden ser beneficiosos para identificar fugas de memoria, desbordamientos de memoria y matrices, y más.
- Ejemplos de escenarios de ataque: Los desbordamientos de búfer y montón han sido un pilar de los atacantes a lo largo de los años. El atacante envía datos a un programa, que almacena en un búfer de pila de tamaño insuficiente. El resultado es que se sobrescribe la información de la pila de llamadas, incluido el puntero de retorno de la función. Los datos establecen el valor del puntero de retorno para que cuando la función regrese, transfiera el control al código malicioso contenido en los datos del atacante.
Referencias
- Vulnerabilidades de OWASP: desbordamiento de búfer
- Ataques OWASP: Desbordamiento de búfer
- Science Direct: Desbordamiento de enteros
Más información