Introducción a AppSec mediante OWASP

Seguimos viendo grandes filtraciones de datos que afectan a organizaciones de todos los tamaños. A medida que los problemas de seguridad cibernética continúan e incluso aumentan en frecuencia y gravedad, nos preguntamos: "¿Somos los siguientes?" y “¿Qué puedo hacer al respecto?” Ahí es donde OWASP entra en juego.

¿Qué es OWASP Top 10?

Más conocido por el OWASP Top 10, OWASP es el Open Web Application Security Project, una comunidad abierta con información gratuita y capacitación sobre seguridad de aplicaciones. El OWASP Top 10 es una lista de riesgos de seguridad peligrosos comunes para las aplicaciones web, que se actualiza periódicamente para mantenerse al día. Si no ha estado haciendo mucho en cuanto a seguridad de aplicaciones, o si lo que ha estado haciendo es ad-hoc, OWASP Top 10 es un excelente lugar para comenzar.

¿Cuáles son las 10 principales vulnerabilidades de OWASP en la actualidad?

El OWASP Top 10 se actualizó por última vez en 2017 y comprende las siguientes vulnerabilidades A1-A10:

1. Inyección
2. Autenticación rota
3. Exposición de datos sensibles
4. Entidades externas XML (XXE)
5. Control de acceso roto
6. Configuración incorrecta de seguridad
7. Secuencias de comandos entre sitios (XSS)
8. Deserialización insegura
9. Uso de componentes con vulnerabilidades conocidas
10. Registro y monitoreo insuficientes

OWASP proporciona documentación para el Top 10, con una página web dedicada a cada vulnerabilidad. La página describe qué es cada vulnerabilidad y proporciona una puntuación de riesgo, que se utiliza para ayudar a priorizar y clasificar las posibles vulnerabilidades. Vea un ejemplo de la página siguiente:

Las distintas secciones de la página le ayudan a comprender la importancia y el peligro de cada una de las vulnerabilidades.

¿Es la aplicación vulnerable?

La sección llamada ¿Es la aplicación vulnerable? explica qué significa que una aplicación tenga la vulnerabilidad y qué tipo de herramientas (DAST, SAST, etc.) son útiles para encontrar esa vulnerabilidad en particular.

Ejemplos de escenarios de ataque

La Ejemplos de escenarios de ataque La sección muestra cómo un atacante podría aprovechar cada vulnerabilidad. Esta información se puede utilizar para ayudar a crear pruebas y para educar al equipo sobre cómo las vulnerabilidades del software afectan la seguridad de las aplicaciones.

Como prevenir

La Como prevenir La sección es la más interesante en mi humilde opinión. Las pruebas de seguridad son importantes, pero la creación de un código seguro es la única base sólida para una seguridad sólida de las aplicaciones. Esta sección describe varias estrategias que lo ayudarán a cambiar a la izquierda su seguridad no solo probando antes, sino creando un mejor código que es fundamentalmente menos vulnerable a los ataques. Esta es la base para un enfoque de seguridad por diseño (requerido por GDPR, por ejemplo).

Referencias

Por último, cada elemento de los 10 principales tiene una sección con más información sobre cada problema, enfoques para evitarlo y enfoques para probarlo. También contiene enlaces que lo llevarán a problemas relacionados. Esto será muy útil mientras trabaja para mejorar continuamente la seguridad de su software.

Al leer la documentación de OWASP Top 10, puede encontrar que algunos de los elementos son obvios solo por su nombre, mientras que otros requieren profundizar más para comprenderlos. Por ejemplo, A1 - “Inyección” - es en realidad un amplio conjunto de cosas como inyección SQL, inyección de comandos, inyección LDAP y más. Detrás de esta debilidad de seguridad está el hecho de que la entrada del usuario no se comprueba y desinfecta lo suficiente antes de que una aplicación la utilice.

¿Por qué utilizar OWASP Top 10?

Hay información, capacitación y consejos en OWASP Top 10. Puede aprender sobre problemas de seguridad comunes, así como estrategias para detectar e incluso evitar algunos problemas por completo. Toda esta información está disponible sin costo y se actualiza y mejora constantemente.

El cumplimiento también significa que necesitamos saber exactamente qué elemento específico de nuestro kit de herramientas respalda qué parte específica del estándar. En el caso del análisis estático, esto significa saber qué verificadores apoyan qué elementos en el estándar y si hay elementos en el estándar que requieren más que un análisis estático (es decir, revisión de código de pares o análisis de composición de software).

Comenzando al final

Es fácil (y peligrosamente común) para las organizaciones de desarrollo de software comenzar con la seguridad comenzando por el final, utilizando pruebas externas, de ciclo tardío y de todo el sistema, como las pruebas de penetración (podría llamar a esto algo así como DevTestOpsSec). Esta prueba es excelente para demostrar que la aplicación / sistema no contiene ninguna de las vulnerabilidades enumeradas en OWASP, seguro. Pero esta prueba de caja negra no es la forma más eficiente de producir código que sea más seguro. No queremos depender de las pruebas de caja negra como una forma de proteger nuestro software o encontrar errores, tanto como queremos usarlo para demostrar que el software is asegurar.

Entonces, si las pruebas de penetración encuentran una vulnerabilidad, debemos preguntarnos el porqué e intente abordar la causa raíz del problema. Aquí es cuando pasamos de una mentalidad de "probar la seguridad en" a una mentalidad de "seguridad por diseño". Para ello, encontrará herramientas de pruebas de seguridad de aplicaciones estáticas (SAST), como el análisis de código estático, con soporte para OWASP.

Más que DAST y SAST

Una pequeña cosa a tener en cuenta es que el artículo A9 en el Top 10 de OWASP es completamente diferente al resto, y no se presta a El domingo or DAST porque se trata de buscar vulnerabilidades conocidas en el código abierto, no de encontrar nuevas vulnerabilidades.

Afortunadamente, OWASP tiene una herramienta gratuita para esto llamada Verificación de dependencia de OWASP. Esta herramienta identifica las dependencias del proyecto y comprueba si existen vulnerabilidades conocidas, divulgadas públicamente, y se puede utilizar para escanear aplicaciones y sus bibliotecas dependientes para identificar componentes vulnerables conocidos.

(Si está usando parasoft, en realidad integramos la verificación de dependencia de OWASP en nuestro sistema de informes y lo hicimos parte del panel de los 10 principales de OWASP. Esto facilita el manejo de problemas en sus componentes de código abierto al escanear como una parte regular de su CI junto con SAST y colocar los resultados en un tablero unificado con el resto de la información de OWASP. Con este enfoque, en lugar de ser un proceso ortogonal separado, A9 se integra con el Top 10 como debería ser).

Herramientas y consejos de análisis de código estático

La belleza del análisis estático es que no es necesario que finalice toda la aplicación o el sistema, por lo que puede comenzar a buscar problemas de seguridad mucho antes en el ciclo (para desplazamiento a la izquierda pruebas de seguridad). Si está haciendo seguridad tarde o cerca del final de su desarrollo (DevOpsSec), puede usar el análisis estático para impulsar la seguridad antes, incluso antes de que comience la prueba, mientras el código se está escribiendo (DevSecOps).

El lado feo del análisis estático es que tiene la reputación de ser muy ruidoso, por ejemplo, produce cientos o incluso miles de violaciones justo cuando pensaba que estaba listo para publicar. Afortunadamente, existen muy buenas estrategias para lidiar con esto. A continuación, se incluyen algunas cosas a tener en cuenta:

• No guarde las pruebas de seguridad hasta el final. Comience a ejecutar un análisis estático tan pronto como comience a codificar. Si espera y solo lo ejecuta como parte de su canal de CI / CD, los hallazgos se acumularán y abrumarán a su equipo de desarrollo. Ejecútelo en el escritorio para encontrar problemas y ejecútelo en CI / CD para simplemente verificar que el código se haya creado correctamente
• Ajuste su configuración. Es posible que algunos verificadores de análisis estáticos no sean necesarios en el contexto de su código. Verifique su aplicación y determine qué riesgos de seguridad son importantes para usted y solo trabaje en ellos. Nunca busque problemas que no planee solucionar.
• La antigüedad del código importa. "Si no está roto, no lo arregle" debería aplicarse al código heredado. Solo ejecute los escáneres de seguridad más críticos con código más antiguo. Los problemas menores le harán perder el tiempo y estos cambios conllevan un nuevo riesgo. Nunca verifique el código que no planea arreglar.
• Se trata de riesgo. Las herramientas SAST encuentran tanto vulnerabilidades reales como potenciales. No todos los hallazgos tienen el mismo riesgo potencial. OWASP ha ayudado a definir el riesgo para cada elemento en el Top 10 en función de lo fácil que es explotar una debilidad, lo fácil que es para alguien encontrar la debilidad y cuál puede ser el impacto real del exploit. Utilice esta información útil para priorizar y clasificar sus hallazgos de SAST:

El poder de la prevención

Me gustaría enfatizar algo que es importante si realmente desea fortalecer su aplicación. Es muy fácil probar la seguridad, pero es más difícil construirla. Afortunadamente, los comprobadores de análisis estático vienen en diferentes sabores. Algunos verificadores buscan problemas típicos, como datos contaminados, y tratan de averiguar si hay un flujo en la aplicación donde podría suceder. Estos son los comprobadores más comunes en muchas herramientas SAST.

Pero el mayor valor en el análisis de código estático radica en las verificaciones que hacen cumplir dos cosas especiales:

1. Un patrón que se asocia frecuentemente con problemas en el pasado. Si bien esto puede no ser tan interesante como un seguimiento de pila específico de un exploit, puede ser mucho más completo simplemente arreglar todo lo que es más débil de lo que debería ser que solo solucionar problemas que tienen un vector de ataque probado.
2. Requisitos de tipos específicos de codificación para garantizar su correcto funcionamiento. Los estándares automotrices y aeronáuticos como MISRA y JSF se basan en esta técnica para garantizar la seguridad funcional. La misma técnica de requerir un buen código además de marcar el código incorrecto le ayudará a crear aplicaciones que sean más seguras.

Irónicamente, este es el enfoque que las industrias críticas para la seguridad han utilizado durante décadas con hardware y software, pero de alguna manera en ciberseguridad creemos que podemos probar la seguridad en una aplicación y no necesitamos enfocarnos en crear código seguro. Aproveche todas las capacidades del análisis estático proactivo, además de los verificadores de detección temprana, para obtener el máximo valor.

Resumen

Obtener OWASP Top 10 no será fácil si nunca se ha centrado en la seguridad, pero es alcanzable y es un gran lugar para comenzar. DAST es una forma sencilla de comenzar con el Top 10, y luego usar SAST lo ayudará cambie su prueba de seguridad a la izquierda. Implementado correctamente, SAST puede incluso prevenir problemas, no solo detectarlos, así que busque herramientas que cubran completamente el estándar, con comprobadores de detección y preventivos.

Aprenda a utilizar la puntuación de riesgo de OWASP para ayudar a priorizar los hallazgos y asegurarse de que sus herramientas generen esta información de riesgo con sus hallazgos. Esto le ayudará a concentrarse en lo que es más importante y es clave para una implementación exitosa de OWASP.

Con estos consejos, debería estar listo para comenzar a eliminar los riesgos de seguridad de aplicaciones web más comunes y peligrosos en la actualidad.

“MISRA”, “MISRA C” y el logotipo del triángulo son marcas comerciales registradas de The MISRA Consortium Limited. © The MISRA Consortium Limited, 2021. Todos los derechos reservados.