¿qué es la lista de las 10 vulnerabilidades principales de OWASP?
publicada por primera vez en 2004 por el Open Web Application Security Project, La ahora famosa lista de las 10 vulnerabilidades principales de OWASP (incluida en la parte inferior del artículo) es probablemente la más cercana que la comunidad de desarrollo ha llegado a un conjunto de mandamientos sobre cómo mantener seguros sus productos.,
esta lista representa las amenazas más relevantes para la seguridad del software hoy en día según OWASP, para el golpe en la frente de muchos que se preguntan cómo las inyecciones SQL siguen siendo una preocupación después de todos estos años. Juzgan los tipos de vulnerabilidad según cuatro criterios:
- facilidad de explotabilidad
- prevalencias
- detectabilidad
- Impacto en el negocio
curiosamente, OWASP afirma que en realidad no tienen en cuenta en su ecuación la probabilidad de que los atacantes intenten explotar una cierta vulnerabilidad.,
cuando comenzó, los escritores decidieron que la mejor manera de cubrir la mayor parte del terreno era poner vulnerabilidades similares que creían que eran las más preocupantes en agrupaciones. Reconocieron que al carecer de las estadísticas adecuadas, siempre podía haber una pregunta sobre qué vulnerabilidades eran necesariamente las principales preocupaciones, especialmente porque esto puede ser una pregunta subjetiva según el modelo de amenaza de cada organización.
Sin embargo, después de mucho debate, ofrecieron su lista de lo que creían que se dirigía al conjunto más amplio de organizaciones, aunque no en un orden particular.,
con el tiempo, la lista de las 10 vulnerabilidades principales de OWASP fue adoptada como un estándar para las mejores prácticas y requisitos por numerosas organizaciones, estableciendo un estándar en cierto sentido para el desarrollo. Un adoptante bien conocido de la lista son los estándares de procesamiento de pagos de PCI-DSS.
desafortunadamente, como la lista de las 10 principales vulnerabilidades de OWASP ha llegado a un público más amplio, sus intenciones reales como guía se han malinterpretado, perjudicando a los desarrolladores en lugar de ayudar. Entonces, ¿cómo debemos entender el propósito de esta lista y realmente alentar a los desarrolladores a codificar de manera más segura?,
comprender las actualizaciones de la lista de 2017
en los años transcurridos desde entonces, han actualizado y reordenado las entradas, agregando algunos nuevos tipos de vulnerabilidad a medida que se vuelven relevantes, incluso cuando otros se eliminaron de la lista. Se han publicado nuevas versiones en 2010, 2013 y 2017. La nueva lista se creó después de un largo y arduo estudio que analizó más de 50.000 aplicaciones y analizó unos 2,3 millones de vulnerabilidades.,
los seguidores habituales de la lista habrán notado que, junto con algunos cambios en el orden, a pesar de que los ataques de inyección permanecen en la parte superior, hay algunos recién llegados a la versión actualizada de 2017 de la familia de vulnerabilidades Top 10 de OWASP.
vencer a la competencia para abrirse paso en el campo lanzando redirecciones y reenvíos no validados es el problema de las API desprotegidas., Su inclusión en la lista en el número A10 es probablemente el resultado del hecho de que los desarrolladores son simplemente mucho más dependientes de las API de lo que solían, interactuando con muchos más Componentes y productos externos que antes. Entrar en el punto A7 es insuficiente protección contra ataques, lo que sorprende a los desarrolladores por no ser lo suficientemente completos para agregar protecciones para detectar, registrar y, por supuesto, responder a los intentos de dañar sus productos.,
el otro cambio importante aquí en la versión de 2017 es la combinación de las referencias de objetos directos inseguros de A4 y el control de acceso de nivel de función faltante de A7, creando una vulnerabilidad de control de acceso roto unificado y destacando la necesidad de establecer controles adecuados para quién puede y no puede acceder a las cuentas y los datos.,
malinterpretando la lista de vulnerabilidades Top 10 de OWASP
una fuerza para el bien, esta lista desafortunadamente se ha convertido en una herramienta para avergonzar a los desarrolladores que no siguen Sus enseñanzas, utilizada como un club para reprenderlos por no ser perfectos cuando se trata de seguridad. Este enfoque es contraproducente y no cumple la misión de OWASP de alentar y equipar a los desarrolladores para que codifiquen de forma más segura. Por otra parte, no reconoce los logros de las puntuaciones de los desarrolladores que están empujando hacia fuera cantidades masivas de nuevo software a un ritmo nunca antes visto.,
en una entrevista reciente, El Presidente de OWASP, Martin Knobloch, expresó su decepción por el hecho de que la lista se usara como una especie de Lista de verificación para una última revisión antes de un lanzamiento, sirviendo más como un mecanismo de validación que como una guía.
como alguien que cree firmemente en un enfoque de cambio a la izquierda para la seguridad, no es de extrañar que esté de acuerdo abrumador con la frustración de Knobloch de cuántos han tomado la lista de los 10 mejores de OWASP como un instrumento de FUD, y no el conjunto de principios rectores que estaba destinado a ser.,
enfoques desafiantes de la industria para la seguridad
Las estrategias de seguridad organizacionales que dependen de esperar el fracaso de los elementos humanos en la forma en que protegen el software en favor de herramientas brillantes están destinadas a fallar.
en los últimos años la mensajería de demasiados proveedores, especialmente en el lado de la red, ha sido que «el perímetro está muerto» y que las empresas necesitan buscar seguridad en profundidad para encontrar a los malos que ya están dentro de su red., Demasiados titulares en conferencias han tratado de convencer a los CISOs de que los equipos de hackers de élite están atacándolos con hazañas rarificadas de 0 días que los dejarán indefensos a menos que compren su producto que de alguna manera los hará inexpugnables a estos ataques imparables.
esta perspectiva sobre el estado de la seguridad es innecesariamente fatalista, llena de publicidad publicitaria y pasa por alto algunos de los conceptos básicos de cómo los profesionales de la seguridad deben pensar en el riesgo.,
un enfoque integral de la seguridad no debe predicar la eliminación de los desarrolladores humanos del proceso, solo para traer las herramientas de seguridad de un proveedor para arreglar después de que hayan terminado su trabajo. Esto supone que no se puede confiar en los desarrolladores, es insultante y no hace nada para hacer que su equipo sea más fuerte cuando se trata de seguridad y gestión de riesgos.
Qué es y no es la lista de las 10 vulnerabilidades de OWASP
un par de veces al año hay una publicación obligatoria en el blog preguntando cómo es posible que en 2017 todavía estemos hablando de ataques a nivel de script kiddie., Probablemente he escrito algunos de esos yo mismo, por lo que me disculpo.
el Top 10 de OWASP no está configurado para resolver todos los ataques en el libro, sino para ayudar a los equipos a evitar los errores comunes que son mucho más propensos a que sus aplicaciones sean violadas. Un atacante determinado puede encontrar muchas vías para romper su objetivo. Sin embargo, los Avisos de gestión inteligente de riesgos no se centran en la minoría de casos, sino que tratan de abordar los problemas a los que se enfrenta el público más amplio.,
para extraer de los conceptos de campo de seguridad física, el gerente de riesgo promedio debería estar mucho más preocupado por que su cliente se meta en un accidente en la carretera que los ninjas entrenados por SEAL Team 6 que vienen a través de las ventanas, guiados por IA (y blockchain).
La seguridad Real consiste en capacitar a las personas sobre cómo trabajar de forma segura y proporcionarles las tecnologías, el conocimiento y los procesos para que les resulte más fácil mantenerse seguros., Si bien siempre es importante ejecutar el control de calidad y las comprobaciones de seguridad finales antes de una versión, la seguridad debe comenzar en las primeras etapas de cómo funciona su equipo, durante todo el proceso de desarrollo del producto. Los errores ocurrirán, pero es mucho más rentable y francamente más inteligente tratar de evitar tantos problemas como sea posible en primer lugar.
para muchos desarrolladores, el objetivo de conducción se centra en conseguir que el producto funcione, centrándose menos en si es Seguro o no. Esto no es su culpa.,
a lo largo de su educación, aprendieron que si producen un producto con una cantidad mínima de errores, entonces obtuvieron una A. La seguridad sería manejada por otro Departamento de todos modos. En su lugar, los gerentes deben aprovechar la oportunidad para mostrarles una mejor manera de trabajar que incluye considerar cómo codifican y los componentes con los que están trabajando afectan la seguridad de su producto.,
GET 451 RESEARCH’s REPORTON SECURING Open SOURCE Software Download Free
pasos prácticos para permitir mejores prácticas de seguridad
Una trampa común que surgió de los días de desarrollo de waterfall fue esperar hasta el final del ciclo de desarrollo para realizar comprobaciones de seguridad, en el que los desarrolladores recibirían una lista de vulnerabilidades para corregir, retrasando la liberación y aumentando la fricción entre ellos y el equipo de seguridad.,
con la esperanza de engrasar los engranajes y mantener el ritmo de la velocidad de DevOps, las organizaciones están buscando nuevas formas de asegurar su código desde el principio y mantener la armonía entre sus departamentos.
un método cada vez más popular para llevar la seguridad a las primeras etapas del desarrollo de productos es en equipos de polinización cruzada con una mezcla de desarrolladores y gente de seguridad, lo que permite a cada lado dar información y aprender unos de otros., Esta puede ser una excelente oportunidad para que los expertos en seguridad planteen muchos de los problemas que el Top 10 de OWASP intenta abordar en un entorno menos conflictivo, en una etapa que realmente podría tener un impacto.
cuando se trata de herramientas que pueden ayudar a promover una mejor implementación de seguridad, necesitamos pensar no solo en cómo la tecnología puede detectar nuestros errores o brechas después de los hechos, sino que también nos ayuda a trabajar de manera más inteligente y segura desde las primeras etapas., Esta perspectiva es parte integrante de la mentalidad de cambio a la izquierda, que busca oportunidades para abordar los problemas antes de que se conviertan en problemas costosos.
integrar tecnologías para aumentar las capacidades de los desarrolladores
un claro ejemplo de cómo las tecnologías para cambiar a la izquierda pueden ayudar a los desarrolladores a utilizar el Top 10 de OWASP viene con la entrada número 9 que advierte contra el uso de componentes con vulnerabilidades conocidas. Uno de los problemas más comunes que surgen en este espacio es en ganar visibilidad sobre lo que hay en los componentes de código abierto que han agregado a su producto.,
Los desarrolladores casi siempre recurren a componentes de código abierto para ayudarlos a construir su producto de manera más rápida y eficiente, agregando características poderosas sin la necesidad de escribir el nuevo código ellos mismos.
en la mayoría de los casos, es poco probable que comprueben si el componente tiene alguna vulnerabilidad conocida antes de agregarlo a su producto. Incluso si realizan una comprobación superficial para ver si tiene algún problema específico, es poco probable que sean conscientes de cualquier problema en las dependencias del componente.,
sin embargo, si están utilizando una herramienta de análisis de composición de Software, en realidad pueden recibir información útil sobre si un componente de código abierto tiene vulnerabilidades conocidas asociadas a él a lo largo del ciclo de vida de desarrollo de software (SDLC), ahorrándoles tiempo que de otra manera podrían pasar rasgando y reemplazando el componente después de una comprobación del equipo de seguridad más adelante antes de la liberación después de que se confirmó a su código.,
sea un habilitador de seguridad dentro de su organización
basado en mi lectura del Top 10 de OWASP y los comentarios de Knobloch, la lista debe tomarse como una herramienta para capacitar a los equipos para incluir la seguridad en su proceso de pensamiento de cómo codifican, configuran y envían sus productos.
los equipos de seguridad que no se involucran con sus desarrolladores, haciendo el esfuerzo de entender cómo pueden empoderarlos para que la seguridad sea un elemento inherente de su flujo de trabajo, se verán rápidamente marginados.,
si quieres seguir siendo relevante, conviértete en un habilitador y usa la lista de los 10 mejores de OWASP como una forma de iniciar conversaciones, no de amenazar. Al final, es posible que encuentres que pescas más (O)avispas con miel que vinagre.
la lista oficial de 10 vulnerabilidades de OWASP
A1. Inyección: los fallos de inyección, como SQL, NoSQL, OS e inyección LDAP, ocurren cuando se envían datos no confiables a un intérprete como parte de un comando o consulta. Los datos hostiles del atacante pueden engañar al intérprete para que ejecute comandos no deseados o acceda a datos sin la autorización adecuada.
A2., Autenticación rota: las funciones de la aplicación relacionadas con la autenticación y la administración de sesiones a menudo se implementan incorrectamente, lo que permite a los atacantes comprometer contraseñas, claves o tokens de sesión, o explotar otros defectos de implementación para asumir las identidades de otros usuarios de forma temporal o permanente.
A3. Exposición de datos confidenciales: muchas aplicaciones web y API no protegen adecuadamente los datos confidenciales, como los financieros, los de atención médica y los de PII. Los atacantes pueden robar o modificar dichos datos débilmente protegidos para cometer fraude con tarjetas de crédito, robo de identidad u otros delitos., Los datos confidenciales pueden verse comprometidos sin protección adicional, como el cifrado en reposo o en tránsito, y requieren precauciones especiales cuando se intercambian con el navegador.
A4. XML External Entities (XXE) – muchos procesadores XML antiguos o mal configurados evalúan referencias de entidades externas dentro de documentos XML. Las entidades externas se pueden utilizar para divulgar archivos internos mediante el controlador URI de archivos, recursos compartidos de archivos internos, análisis de puertos internos, ejecución remota de código y ataques de denegación de servicio.
A5.,Controles de acceso rotos: las restricciones sobre lo que los usuarios autenticados pueden hacer a menudo no se aplican correctamente. Los atacantes pueden explotar estas fallas para acceder a funciones y/o datos no autorizados, acceder a las cuentas de otros usuarios, ver archivos confidenciales, modificar los datos de otros usuarios, cambiar los derechos de acceso, etc.
A6. Error de configuración de seguridad: el problema más común es el error de configuración de seguridad., Esto suele ser el resultado de configuraciones predeterminadas inseguras, configuraciones incompletas o ad hoc, almacenamiento abierto en la nube, encabezados HTTP mal configurados y mensajes de error detallados que contienen información confidencial. No solo deben configurarse de forma segura todos los sistemas operativos, marcos de trabajo, bibliotecas y aplicaciones, sino que también deben ser parcheados/actualizados de manera oportuna.
A7.,Cross Site Scripting (XXS)-las fallas XSS ocurren cuando una aplicación incluye datos no confiables en una nueva página web sin la validación o el escape adecuados, o actualiza una página web existente con datos suministrados por el usuario utilizando una API de navegador que puede crear HTML o JavaScript. XSS permite a los atacantes ejecutar scripts en el navegador de la víctima que pueden secuestrar sesiones de usuario, desfigurar sitios web o redirigir al usuario a sitios maliciosos.
A8. Deserialización insegura-la deserialización insegura a menudo conduce a la ejecución remota de código., Incluso si las fallas de deserialización no dan lugar a la ejecución remota de código, se pueden usar para realizar ataques, incluidos ataques de repetición, ataques de inyección y ataques de escalada de privilegios.
A9. Uso de componentes con vulnerabilidades conocidas: los componentes, como bibliotecas, marcos y otros módulos de software, se ejecutan con los mismos privilegios que la aplicación. Si se explota un componente vulnerable, un ataque de este tipo puede facilitar la pérdida de datos graves o la adquisición del servidor., Las aplicaciones y API que utilizan componentes con vulnerabilidades conocidas pueden socavar las defensas de las aplicaciones y permitir diversos ataques e impactos.
A10. Registro insuficiente & supervisión: el registro y la supervisión insuficientes, junto con la integración inexistente o ineficaz con la respuesta a incidentes, permiten a los atacantes atacar más sistemas, mantener la persistencia, pivotar a más sistemas y manipular, extraer o destruir datos., La mayoría de los estudios muestran que el tiempo para detectar una violación es de más de 200 días, generalmente detectados por partes externas en lugar de procesos o monitoreo internos.