• Author / Uploaded
• lfmontalvan

Citation preview

Titulación de Sistemas Informáticos y Computación

Informe Técnico – OWASP TOP 10

Autor: Leonardo Fabián Montalván Celi

Loja - Ecuador Contenido 1.

Problemática................................................................................................. 5

2.

Situación Actual............................................................................................ 7

3.

Estadísticas................................................................................................... 8

4.

Triángulo de la Seguridad............................................................................. 9

5.

OWASP.......................................................................................................... 9

5.1.

Introducción............................................................................................... 9

5.2.

OWASP TOP 10........................................................................................ 10

5.3.

Factores de riesgos de seguridad en aplicaciones...................................11

5.4.

Identificación de Riesgos.........................................................................11

5.5.

Arquitectura de una aplicación web. ¿Cómo funciona?...........................12

5.5.1.

Arquitectura Cliente Servidor...............................................................12

5.5.2.

Arquitectura por capas.........................................................................12

5.6.

OWASP Top 10 de Riesgos de Seguridad en Aplicaciones........................14

5.6.1.

A1 – Inyección...................................................................................... 14

5.6.1.1.

Definición.......................................................................................... 14

5.6.1.2.

Riesgos.............................................................................................. 14

5.6.1.3.

Impacto del ataque........................................................................... 14

5.6.1.4.

Etapas del Ataque............................................................................. 14

5.6.1.5.

Prevención......................................................................................... 15

5.6.2.

A2 – Pérdida de Autenticación y Gestión de Sesiones..........................16

5.6.2.1.

Definición.......................................................................................... 16

5.6.2.2.

Riesgos.............................................................................................. 16

5.6.2.3.

Impacto del ataque........................................................................... 16

5.6.2.4.

Etapas del ataque............................................................................. 16

5.6.2.5.

Prevención......................................................................................... 17

5.6.3.

A3 – Secuencia de comandos en sitios cruzados (XSS)........................17

5.6.3.1.

Definición.......................................................................................... 17

5.6.3.2.

Riesgos.............................................................................................. 17

5.6.3.3.

Impacto del ataque...........................................................................18

5.6.3.4.

Etapas del ataque............................................................................. 18

5.6.3.5.

Prevención......................................................................................... 19

5.6.4.

A4 – Referencia directa insegura a objetos...........................................19

5.6.4.1.

Definición.......................................................................................... 19

5.6.4.2.

Riesgos.............................................................................................. 19 2

5.6.4.3.

Impacto del ataque...........................................................................20

5.6.4.4.

Etapas del ataque............................................................................. 20

5.6.4.5.

Prevención......................................................................................... 20

5.6.5.

A5 – Configuración de Seguridad Incorrecta.........................................21

5.6.5.1.

Definición.......................................................................................... 21

5.6.5.2.

Riesgos.............................................................................................. 21

5.6.5.3.

Impacto del ataque...........................................................................21

5.6.5.4.

Etapas del ataque............................................................................. 22

5.6.5.5.

Prevención......................................................................................... 22

5.6.6.

A6 – Exposición de datos sensibles......................................................22

5.6.6.1.

Definición.......................................................................................... 22

5.6.6.2.

Riesgos.............................................................................................. 23

5.6.6.3.

Impacto del ataque...........................................................................23

5.6.6.4.

Etapas del ataque............................................................................. 23

5.6.6.5.

Prevención......................................................................................... 24

5.6.7.

A7 – Inexistente Control de Acceso a nivel de funcionalidades............24

5.6.7.1.

Definición.......................................................................................... 24

5.6.7.2.

Riesgos.............................................................................................. 24

5.6.7.3.

Impacto del ataque...........................................................................24

5.6.7.4.

Etapas del ataque............................................................................. 25

5.6.7.5.

Prevención......................................................................................... 25

5.6.8.

A8 – Falsificación de Peticiones en Sitios Cruzados (CSFR)...................25

5.6.8.1.

Definición.......................................................................................... 25

5.6.8.2.

Riesgos.............................................................................................. 26

5.6.8.3.

Impacto del ataque...........................................................................26

5.6.8.4.

Etapas del ataque............................................................................. 26

5.6.8.5.

Prevención......................................................................................... 27

5.6.9.

A9 – Uso de Componentes con Vulnerabilidades Conocidas.................27

5.6.9.1.

Definición.......................................................................................... 27

5.6.9.2.

Riesgos.............................................................................................. 27

5.6.9.3.

Impacto del ataque...........................................................................27

5.6.9.4.

Etapas del ataque............................................................................. 28

5.6.9.5.

Prevención......................................................................................... 28 3

5.6.10. A10 – Redirecciones y reenvíos no válidos...........................................28 5.6.10.1. Definición.......................................................................................... 28 5.6.10.2. Riesgos.............................................................................................. 28 5.6.10.3. Impacto del ataque...........................................................................29 5.6.10.4. Etapas del ataque............................................................................. 29 5.6.10.5. Prevención......................................................................................... 29 5.7.

Controles del Top 10 de OWASP...............................................................29

5.8.

Conclusiones........................................................................................... 30

5.9.

Recomendaciones.................................................................................... 30

5.10.

Bibliografía........................................................................................... 31

1. Problemática En la actualidad (Milano, 2007) la seguridad no es tomada en cuenta durante el proceso de desarrollo de aplicaciones web, por lo general la seguridad es tomada en cuenta en la

4

última etapa del ciclo de vida del desarrollo de un sistema (SDLC 1). En la Figura 1, se pude observar el ciclo de vida del desarrollo de sistema, mientras que en la Figura 2, se indica la curva del costo de implementar seguridad en las últimas fases del SDLC, es decir mientras más nos demoremos en implementar la seguridad más costoso será.

Figura 1. Etapas del SDLC Fuente: Tomada de (Tutorialspoint.com, n.d.)

Figura 2. Curva de Costos de la Implementación de Seguridad Fuente: Tomada de (Milano, 2007)

Pero cuales son los principales motivos por lo que no se toma en cuenta la implementación de la seguridad, para (Milano, 2007), los principales mitos son: 1 SDLC (System Development Life Cycle).- (Tutorialspoint.com, n.d.) ciclo de vida del desarrollo de sistemas o software, es un framework, donde se especifican las tareas o actividades que se deben realizar en cada etapa del proceso del desarrollo de software. 5

       

La seguridad de la aplicación es responsabilidad del programador. Nadie sabe cómo funciona, por ende, no la van a atacar. Si no se encontraron vulnerabilidades hasta ahora… A nadie le interesaría atacar nuestra aplicación. La aplicación es segura porque corre detrás de un firewall. La aplicación es segura porque usa encriptación. Si no corre como Administrator / root, no funciona. Si, ese feature (que es inseguro) viene habilitado por default, pero el administrador

lo puede deshabilitar.  No hay manera de explotarla.  No hay tiempo para incluir seguridad. Recolectando en puntos principales, la problemática de la no implementación de la seguridad se debe a:  Muchos de los desarrolladores y/o líderes de proyectos no consideran importante incluir la seguridad, y creen que no aporta ningún valor.  Resolver las vulnerabilidades antes de la ejecución de un proyecto se toma como un proceso costoso e innecesario.  El objetivo principal es la funcionalidad sin tomar en cuenta aspectos de seguridad.  Tiempos cortos para desarrollos y/o proyectos.  La seguridad en aplicaciones no se ve como una inversión sino como un costo impuesto por la necesidad de cumplir las normas y reglamentos.  Mala comunicación entre el equipo o departamentos involucrados, en un ambiente de desarrollo de aplicaciones, se pueden encontrar problemas graficados en la Figura 3.

Figura 3. Mala comunicación entre equipos Fuente: Tomada de (Infoinnova, n.d.)

6

2. Situación Actual En la sociedad tecnológica actual, los riesgos de que nuestros sistemas o aplicaciones web sean atacados por hackers, por no tener una implementación de seguridad robusta se vuelve cada vez más común, pero que hacen los hackers con nuestros sistemas: 1. Principalmente los hacker / researchers, encuentra vulnerabilidades o debilidades en el software. 2. Cuando encuentra una vulnerabilidad, no importa en qué plataforma (Windows, Linux, Unix, Oracle, SqlServer), esta vulnerabilidad es publicada. 3. Se crean websites, con el detalle de la vulnerabilidad y como explotarla. 4. Se libera el fix, parche, SP o se publica el workaround. 5. Estos parches son instalados y testeados por el administrador. Las principales causas para que los hacker encuentren vulnerabilidades en nuestros sistemas son: 1. 2. 3. 4. 5. 6.

Ausencia de procesos formales para el SDLC y que incluyan Seguridad. Diseño orientado a la funcionalidad. Falta de uso de metodologías, estándares o buenas prácticas. No existen procedimientos para el análisis y evaluación de riesgos. Falta de conocimiento de las amenazas, riesgos, vulnerabilidades. Tiempo y Presupuesto.

3. Estadísticas Para (Brumfield, 2014), en un estudio realizado en el 2013, que cubría más de 63.000 incidentes de seguridad, de 50 organizaciones participantes a nivel global, se determinó que el 92%

de los incidentes de seguridad en los últimos 10 años, se encuentran

categorizados en: instrucciones POS, Ataque de la aplicación web, Uso indebido de información privilegiada, Robo / pérdida, Diversos errores, Crimeware, Skimmer de la tarjeta de pago, Denegación de servicio, Ciber espionaje. Entre otros datos estadísticos tenemos: 1. 2. 3. 4. 5. 6. 7.

Los ataques a aplicaciones web van en aumento (35%). El 66% de los ataques a aplicaciones web son ‘sin fines de lucro’. El sector financiero es el más afectado. Los atacantes utilizan ‘viejas vulnerabilidades conocidas’. Inyecciones SQL fueron usadas en el 80% de ataques a aplicaciones web. El 74% de ataques a aplicaciones web fueron reportados por clientes. Los atacantes siguen explotando fallas en los sistemas CMS populares, especialmente mediante el uso de vulnerabilidades en plugins populares.

7

Figura 4. Resultados Ataques a la Seguridad Fuente: Tomado de (Brumfield, 2014)

4. Triángulo de la Seguridad ¿Por qué se representa como un triángulo? (Batshoun, n.d.), en la Figura 5, si se comienza en el centro y se mueve el punto hacia la seguridad, se está moviendo más lejos de la funcionalidad y la usabilidad. Si se mueve el punto hacia la Usabilidad, se está alejando de la Seguridad y de la Funcionalidad. En pocas palabras, a medida que aumenta la seguridad, la funcionalidad del sistema y la facilidad de uso disminución.

Figura 5. Triángulo de la Seguridad Fuente: Tomado de (Batshoun, n.d.)

8

Con todas las amenazas a la seguridad que existen en nuestro mundo digital, es un desafío, proporcionar una seguridad adecuada a los datos y la red interna. La pregunta que a menudo los clientes formulan es "¿Estamos haciendo lo suficiente?" Siempre hay algo más que puede hacer. No hay mecanismo suficiente para proteger sus datos y red. La seguridad se logra mejor a través de un enfoque por capas. El número de capas y exhaustividad de cada capa son una cuestión de grados y se debe discutir de manera recurrente.

5. OWASP 5.1.

Introducción

Después de analizar las estadísticas en el punto 3, determinamos que el software inseguro está afectando a los sectores de: finanzas, salud, defensa, energía. En el mundo actual donde las infraestructuras digitales, se hacen cada vez más complejas y suman sus nodos de conexiones, la implementación de la seguridad en las aplicaciones aumenta exponencialmente. Con el objetivo de crear una conciencia a nivel mundial de la importancia de la implementación de la seguridad en las aplicaciones de las organizaciones, se ha creado el proyecto Top 10 de OWASP, que es una colección abierta de herramientas, estándares, librerías e investigaciones referente a la seguridad. OWASP (Open Web Application Security Project) o Proyecto Abierto de Seguridad para Aplicaciones Web, es un proyecto de código abierto que nació en el año 2003, que permite a las organizaciones desarrollar, adquirir y mantener aplicaciones confiables.

5.2.

OWASP TOP 10

De los años de estudios sobre los ataques y vulnerabilidades de las aplicaciones web de nuestras organizaciones, se ha desarrollado un proyecto denominado TOP 10 de OWASP el mismo que realiza 10 categorizaciones de los ataques más comunes que pueden atacar las aplicaciones web de las organizaciones, con el objetivo de crear una mejor conciencia sobre la seguridad de las aplicaciones. OWASP 2010 y 2013 En la Figura 6, se muestra la categorización de los 10 ataques que pueden ser víctimas las aplicaciones web de cualquier organización, además se hace referencia al listado del

9

2010 con el 2013, con la diferencia que los escenarios de amenazas para la seguridad de aplicaciones cambian constantemente.

Figura 6. Top 10 de OWASP 2010 y 2013 Fuente: Tomado de (Owasp, 2013)

5.3.

Factores de riesgos de seguridad en aplicaciones.

Los atacantes pueden utilizar diversas rutas en nuestra aplicación para encontrar vulnerabilidades. Cada una de esta ruta es un riesgo que debemos prestar atención. En la Figura 7, se muestra las posibles rutas dentro de nuestra aplicación, en donde se examina la dificultad para encontrar la vulnerabilidad y el impacto que tendrá nuestra aplicación si se llegara a explotar la vulnerabilidad, en la organización se evalúa la probabilidad asociada a cada amenaza de vulnerabilidad, vector de ataque y la debilidad de la seguridad, esto determina el riesgo total.

Figura 7. Factores de riesgos de seguridad

10

Fuente: Tomado de (Owasp, 2013)

5.4.

Identificación de Riesgos

El proyecto OWASP Top 10, se enfoca a la identificación de riesgos y su categorización, cuando se encuentra con un riesgo el Top 10 de OWASP le proporciona información genérica sobre la probabilidad y el impacto técnico a través de un esquema de calificaciones, el mismo que se basa en la metodología de evaluación de riesgos OWASP (Figura 8). Dependiendo de los detalles específicos de su empresa, pueden existir riesgos que tengan un mayor impacto en una organización, que en otras, por lo que se determina que el Top 10 de OWASP, pueden existir riesgos que no han sido tomados en cuenta pero afectan a la organización.

Figura 8. Tabla cualitativa de los riesgos Fuente: Tomada de (Owasp, 2013)

5.5.

Arquitectura de una aplicación web. ¿Cómo funciona?

5.5.1. Arquitectura Cliente Servidor Las aplicaciones web utilizan lo que se conoce como clientes livianos (light clients) los cuales no ejecutan demasiadas labores de procesamiento para la ejecución de la aplicación misma. Desde el punto de vista de la arquitectura se distinguen dos lados; uno es el cliente, donde se encuentra el usuario final utilizando la aplicación por medio de un navegador (como Internet Explorer o Mozilla Firefox). A través de este cliente web, el usuario interactúa con la aplicación localizada al otro lado, en el servidor, que es donde residen realmente los datos, reglas y lógica de la aplicación. En la Figura 9, se pude observar el funcionamiento de una arquitectura cliente – servidor.

11

Figura 9. Arquitectura Cliente – Servidor Fuente: Tomado de (Wiki Informática de la UTFSM, 2012)

5.5.2. Arquitectura por capas También conocida como “Arquitectura de tres capas”, esta arquitectura permite definir un modelo de diseño en capas, que pueden estar físicamente distribuidas, es decir que los componentes de una capa sólo pueden hacer referencia a componentes en capas inmediatamente inferiores. Este patrón es importante porque simplifica la comprensión y la organización del desarrollo de sistemas complejos, reduciendo las dependencias de forma que las capas más bajas no son conscientes de ningún detalle o interfaz de las superiores. Además, permite identificar qué componentes se puede reutilizarse, y proporciona una estructura que nos ayuda a tomar decisiones sobre qué partes comprar y qué partes construir. La aplicación se divide en tres capas lógicas distintas, cada una de ellas con un grupo de interfaces perfectamente definido. La primera capa se denomina capa de presentación y normalmente consiste en una interfaz gráfica de usuario de algún tipo. La capa intermedia, o capa de empresa, consiste en la aplicación o lógica de empresa, La tercera capa, la capa de datos, contiene los datos necesarios para la aplicación. La capa intermedia (lógica de aplicación) es básicamente el código al que recurre la capa de presentación para recuperar los datos deseados. La capa de presentación recibe entonces los datos y los formatea para su presentación. En la Figura 10, se pude observar la arquitectura en capas. 12

Figura 10. Arquitectura en Capas Fuente: Tomado de (EcuRed, n.d.)

5.6.

OWASP Top 10 de Riesgos de Seguridad en Aplicaciones

Los nombres en los riesgos en el Top 10 de OWASP, se deben al tipo de ataque, debilidad o impacto que causan.

5.6.1. A1 – Inyección. 5.6.1.1.

Definició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 enviados por parte del atacante pueden engañar al interprete para que ejecute comandos no intencionados o para acceder datos no autorizados.

5.6.1.2.

Riesgos

En la Figura 11, se identifica los riesgos de las Inyecciones.

13

Figura 11. Riesgos de las Inyecciones Fuente: Tomado de (Owasp, 2013)

5.6.1.3.

Impacto del ataque

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.

5.6.1.4.

Etapas del Ataque

Para ejecutar una inyección se realizan los siguientes pasos, además se ilustra en la Figura 12. 1. 2. 3. 4.

La aplicación presenta un formulario web al atacante. El atacante envía un ataque en los datos del formulario. La aplicación dirige el ataque a la base de datos en una consulta SQL. La base de datos ejecuta el ataque y envía los resultados cifrados nuevamente a

la aplicación. 5. La aplicación descifra los datos normalmente y envía los resultados al atacante.

14

Figura 12. Demostración ataque por Inyección Fuente: Tomado de (Martínez & Espinoza, n.d.)

5.6.1.5.

Prevención

 Usar API seguras, la cual evite el uso de intérpretes por completo.  Evitar el uso del intérprete utilizando procedimientos almacenados o consultas parame trizadas.  Escapar de caracteres especiales utilizando APIs como OWASP ESAPI.  Realizar validación positiva o whitelisting ("Lista Blanca”), con adecuada canonicalización2.

5.6.2. A2 – Pérdida de Autenticación y Gestión de Sesiones. 5.6.2.1.

Definición.

Las funciones de la aplicación relacionadas a autenticación y gestión de sesiones son frecuentemente implementadas de forma incorrecta, permitiendo a los atacantes comprometer contraseñas, claves, tokens

3

de sesiones, o explotar otras fallas de

implementación para asumir la identidad de otros usuarios. 2 Canonicalización.- según (Web SEO, 2007) es una peculiar palabra, que en términos SEO significa escoger la mejor URL para mostrar nuestro sitio Web. 3 Token (Wikipedia, n.d.) o también llamado componente léxico es una cadena de caracteres que tiene un significado coherente en cierto lenguaje de programación. 15

5.6.2.2.

Riesgos.

En la Figura 13, se identifica los riesgos por Pérdida de Autenticación.

Figura 13. Riesgos de la Pérdida de Autenticación y Gestión de Sesiones Fuente: Tomado de (Owasp, 2013)

5.6.2.3.

Impacto del ataque

Estas vulnerabilidades pueden permitir que algunas o todas las cuentas sean atacadas. Una vez que el ataque resulte exitoso, el atacante podría realizar cualquier acción que la víctima pudiese. Las cuentas privilegiadas son objetivos prioritarios.

5.6.2.4.

Etapas del ataque

Las etapas del ataque por pérdida de autenticación y gestión de sesiones, se demuestran en la Figura 14.

16

Figura 14. Demostración ataque por Pérdida de Autenticación y Gestión de Sesiones Fuente: Tomado de (Martínez & Espinoza, n.d.)

5.6.2.5.

Prevención

 Proveer a los desarrolladores un conjunto de controles de autentificación y gestión de sesiones fuertes definidos en el Application Security Verification Standard (ASVS) de OWASP.

5.6.3. A3 – Secuencia de comandos en sitios cruzados (XSS) 5.6.3.1.

Definición.

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. Las fallas de XSS permiten a los atacantes ejecutar secuencia de comandos en el navegador de la víctima, los cuales pueden secuestrar las sesiones de usuario, destruir sitios web, o dirigir al usuario hacia un sitio malicioso.

5.6.3.2.

Riesgos.

En la Figura 15, se identifica los riesgos por XSS.

17

Figura 15. Riesgos XSS Fuente: Tomado de (Owasp, 2013)

5.6.3.3.

Impacto del ataque.

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.

5.6.3.4.

Etapas del ataque.

Figura 16. Demostración ataque XSS Fuente: Tomado de (Martínez & Espinoza, n.d.)

18

5.6.3.5.

Prevención.

 Utilizar técnicas de codificación (codificar datos no confiables basados en HTML)  Validación de la "Lista Blanca" (Validar la longitud, formato, caracteres de los datos)  Utilizar bibliotecas de auto sanitización4 (AntuSamy de OWASP)  Aplicar políticas de seguridad de contenido.

5.6.4. A4 – Referencia directa insegura a objetos. 5.6.4.1.

Definición.

Una referencia directa a objetos ocurre cuando un desarrollador expone una referencia a un objeto de implementación interno, tal como un fichero, directorio, o base de datos. Sin un chequeo de control de acceso u otra protección, los atacantes pueden manipular estas referencias para acceder datos no autorizados.

5.6.4.2.

Riesgos.

En la Figura 17, se identifica los riesgos por referencia directa insegura a objetos.

Figura 17. Riesgos por referencia directa insegura a objetos. Fuente: Tomado de (Owasp, 2013)

4 Sanitización: (Wikipedia, n.d.) en el manejo de información confidencial o sensible es el proceso lógico y/o físico mediante el cual se remueve información considerada sensible o confidencial de un medio ya sea físico o magnético, ya sea con el objeto de desclasificarlo, reutilizar el medio o destruir el medio en el cual se encuentra. 19

5.6.4.3.

Impacto del ataque.

Dichas vulnerabilidades pueden comprometer toda la información que pueda ser referida por parámetros. A menos que el espacio de nombres resulte escaso, para un atacante resulta sencillo acceder a todos los datos disponibles de este tipo.

5.6.4.4.

Etapas del ataque.

Para ejecutar un ataque por referencia directa insegura a objetos, los hacker hacen lo siguiente, como se ilustra en la Figura 18.

Figura 18. Demostración ataque por referencia directa insegura a objetos. Fuente: Tomado de (Martínez & Espinoza, n.d.)

1. El atacante identifica su número de cuenta. En la Figura 18, se pude observar que el número de cuenta es el 6065. 2. El atacante modifica a un número parecido. ?acct=6066. 3. El atacante visualiza los datos de la cuenta de la víctima.

5.6.4.5.

Prevención.

 Utilizar referencias indirectas por usuario o sesión.(Evita que los atacantes accedan directamente a recursos no autorizados)  Comprobar el acceso. (Comprueba que el usuario está autorizado a acceder al objeto solicitado)

20

5.6.5. A5 – Configuración de Seguridad Incorrecta. 5.6.5.1.

Definición.

Una buena seguridad requiere tener una configuración segura, definida e implementada para la aplicación, servidor de aplicaciones, servidor web, base de datos, plataforma, etc. Todas estas configuraciones deben ser definidas, implementadas, 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 utilizadas por la aplicación.

5.6.5.2.

Riesgos.

En la Figura 19, se identifica los riesgos por configuración de seguridad incorrecta.

Figura 19. Riesgos por configuración de seguridad incorrecta Fuente: Tomado de (Owasp, 2013)

5.6.5.3.

Impacto del ataque.

Estas vulnerabilidades frecuentemente dan a los atacantes acceso no autorizado a algunas funcionalidades o datos del sistema. Ocasionalmente provoca que el sistema se comprometa totalmente.

21

5.6.5.4.

Etapas del ataque.

Figura 20. Demostración ataque por configuración de seguridad incorrecta Fuente: Tomado de (Martínez & Espinoza, n.d.)

5.6.5.5.

Prevención.

 Un proceso rápido, fácil y repetible de fortalecimiento para obtener un entorno apropiadamente asegurado.  Procesos para mantener y desplegar las nuevas actualizaciones y parches de software.  Arquitectura robusta de aplicaciones.  Escanear y realizar auditorías periódicamente para detectar fallos de configuración o parches obsoletos.

5.6.6. A6 – Exposición de datos sensibles. 5.6.6.1.

Definición.

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, así como también de precauciones especiales en un intercambio de datos con el navegador.

22

5.6.6.2.

Riesgos.

En la Figura 21, se identifica los riesgos por exposición de datos sensibles.

Figura 21. Riesgos por exposición de datos sensibles. Fuente: Tomado de (Owasp, 2013)

5.6.6.3.

Impacto del ataque.

Los fallos frecuentemente comprometen 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, etc.

5.6.6.4.

Etapas del ataque.

Figura 22. Demostración ataque por exposición de datos sensibles Fuente: Tomado de (Martínez & Espinoza, n.d.)

23

5.6.6.5.     

Prevención.

Cifrar los datos sensibles almacenados o en tráfico. No almacenar datos sensibles innecesarios. Aplicar algoritmos de cifrados robustos y estandarizados. Diseñar algoritmos para proteger las claves. Deshabilitar el autocompletar en los formularios que recogen datos sensibles.

5.6.7. A7 – Inexistente Control de Acceso a nivel de funcionalidades. 5.6.7.1.

Definición.

La mayoría de aplicaciones web verifican los derechos (permisos) de acceso a nivel de función antes de hacerlos visibles en la misma interfaz de usuario. A pesar de esto, las aplicaciones necesitan verificar el control de acceso en el servidor cuando se accede a cada función. Si las solicitudes de acceso no se verifican, los atacantes podrían realizar peticiones sin la autorización apropiada.

5.6.7.2.

Riesgos.

En la Figura 23, se identifica los riesgos por el inexistente control de acceso a nivel de funcionalidades.

Figura 23. Riesgos por el inexistente control de acceso a nivel de funcionalidades. Fuente: Tomado de (Owasp, 2013)

24

5.6.7.3.

Impacto del ataque.

Estas vulnerabilidades permiten el acceso no autorizado de los atacantes a funciones del sistema. Las funciones administrativas son un objetivo clave de este tipo de ataques.

5.6.7.4.

Etapas del ataque.

Figura 24. Demostración ataque por inexistente control de acceso a nivel de funcionalidades Fuente: Tomado de (Martínez & Espinoza, n.d.)

1. Los atacantes identifican que la URL indica su perfil /user/getAccounts. 2. Los atacantes modifican la URL apuntando a otro perfil /admin/getAccounts o manager/getAccounts. 3. Los atacantes visualizan otros perfiles.

5.6.7.5.

Prevención.

 El proceso para la gestión de accesos y permisos deberían ser actualizable y auditable fácilmente.  La implementación del mecanismo debería negar todo acceso por defecto.  Si la funcionalidad forma parte de un workflow, verificar y asegurarse que las condiciones del flujo se encuentren en el estado apropiado para permitir acceso.

5.6.8. A8 – Falsificación de Peticiones en Sitios Cruzados (CSFR) 5.6.8.1.

Definición.

Un ataque CSRF obliga al navegador de una víctima autenticada, enviar una petición HTTP falsificada, incluyendo la sesión del usuario y cualquier otra información de 25

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 piense que son peticiones legítimas provenientes de la víctima.

5.6.8.2.

Riesgos.

En la Figura 25, se identifica los riesgos por CSFR.

Figura 25. Riesgos por CSFR. Fuente: Tomado de (Owasp, 2013)

5.6.8.3.

Impacto del ataque.

Los atacantes pueden cambiar cualquier dato que la víctima esté autorizada a cambiar, o a acceder a cualquier funcionalidad donde esté autorizada, incluyendo registro, cambio de estado o cierre de sesión.

26

5.6.8.4.

Etapas del ataque.

Figura 26. Demostración ataque CSFR. Fuente: Tomado de (Martínez & Espinoza, n.d.)

5.6.8.5.

Prevención.

 Incluir un token único en el campo oculto, para que el valor del campo se envíe en el cuerpo de la solicitud HTTP.  El token único también puede ir incluido en la URL, o un parámetro de la misma.  Volverse a autenticar para comprobar que se trata de un usuario legítimo.

5.6.9. A9 – Uso de Componentes con Vulnerabilidades Conocidas. 5.6.9.1.

Definición.

Algunos componentes tales como las librerías, frameworks y otros módulos de software casi siempre funcionan con todos los privilegios. Si se ataca un componente vulnerable esto podría facilitar la intrusión en el servidor o una perdida seria de datos. Las aplicaciones que utilicen componentes con vulnerabilidades conocidas debilitan las defensas de la aplicación y permiten ampliar el rango de posibles ataques e impactos.

5.6.9.2.

Riesgos.

En la Figura 27, se identifica los riesgos por el uso de componentes con vulnerabilidades conocidas.

27

Figura 27. Riesgos por uso de componentes con vulnerabilidades conocidas. Fuente: Tomado de (Owasp, 2013)

5.6.9.3.

Impacto del ataque.

El rango completo de debilidades incluye inyección, control de acceso roto, XSS, etc. El impacto puede ser desde mínimo hasta apoderamiento completo del equipo y compromiso de datos.

5.6.9.4.

Etapas del ataque.

Este tipo de vulnerabilidades se encuentra dentro de A5 – Configuración de Seguridad Incorrecta. Figura 20.

5.6.9.5.    

Prevención.

Identificar todos los componentes y la versión que están ocupando. Revisar la seguridad del componente y mantenerlos actualizados. Establecer políticas de seguridad sobre el uso de componentes. Agregar capas de seguridad alrededor del componente.

5.6.10.

A10 – Redirecciones y reenvíos no válidos.

5.6.10.1. Definición. Las aplicaciones web frecuentemente redirigen y reenvían a los usuarios hacia otras páginas o sitios web, y utilizan datos no confiables para determinar la página de destino. Sin una validación apropiada, los atacantes pueden redirigir a las víctimas hacia sitios de phishing o malware, o utilizar reenvíos para acceder páginas no autorizadas.

28

5.6.10.2. Riesgos. En la Figura 28, se identifica los riesgos por redirecciones y reenvíos no válidos.

Figura 28. Riesgos por redirecciones y reenvíos no válidos. Fuente: Tomado de (Owasp, 2013)

5.6.10.3. Impacto del ataque. Estas redirecciones pueden instalar código malicioso o engañar a las víctimas para que revelen contraseñas u otra información sensible. El uso de reenvíos inseguros puede permitir evadir el control de acceso.

29

5.6.10.4. Etapas del ataque.

Figura 29. Demostración ataque por redirecciones y reenvíos no válidos. Fuente: Tomado de (Martínez & Espinoza, n.d.)

5.6.10.5. Prevención.  Evitar el uso de redirecciones y reenvíos.  Si se utiliza, no involucrar parámetros manipulables por el usuario para definir el destino.  Si los parámetros de destino no pueden ser evitados, asegúrese que el valor suministrado sea válido y autorizado para el usuario.

5.7.

Controles del Top 10 de OWASP

Los controles del Top 10 de OWASP, son una lista de técnicas de seguridad que deben ser incluidas en cada proyecto de desarrollo de software. Estos controles permiten ayudar a los desarrolladores asegurar el desarrollo de aplicaciones. Los principales controles para las vulnerabilidades son: 1. 2. 3. 4. 5. 6. 7. 8. 9.

Consultas parametizadas. Datos codificados. Validar todas las entradas. Implementar los controles de acceso apropiados. Establecer controles para la identidad y autenticación. Protección y privacidad de datos. Implementar logging, manejo de errores y detección de intrusiones. Implementar características de seguridad y librerías de seguridad. Incluir requerimientos específicos del usuario. 30

10. Incluir seguridad en el diseño y la arquitectura.

5.8.

Conclusiones.

Ningún modelo o metodología será perfecta. La Gestión de Riesgos es clave para racionalizar el esfuerzo. No es conveniente remediar las amenazas cuando ya se han materializado (técnicas detectivas, o a través de herramientas automatizadas de seguridad) lo que incurre en elevados costos, en cambio que identificarlas tempranamente a través de técnicas preventivas es más costo-efectivo.

5.9.

Recomendaciones.

No esperar seguridad por parte de los usuarios, desconfiar siempre en los datos ingresados por parte de ellos. Adoptar una metodología para el ciclo de vida de desarrollo de software seguro, incorporándola la seguridad en cada fase del desarrollo. Las organizaciones deben adoptar buenas prácticas o estándares para la codificación segura, de manera que se prevengan las fallas que son introducidas con las aplicaciones. Educación, capacitación, entrenamiento y concientización a las partes involucradas en el desarrollo como técnica preventiva para proporcionar los conocimientos para escribir código seguro. Actualización continua de conocimientos de desarrolladores sobre técnicas nuevas y emergentes.

5.10. Bibliografía Batshoun, W. (n.d.). The Security, Functionality and Usability triangle. — Linkology. Retrieved June 11, 2015, from http://www.linkologyusa.com/blog/2014/8/28/the-security-functionality-andusability-triangle Brumfield, C. (2014). Verizon Data Breach Report: Nine Patterns Cover 92% of Cybersecurity Incidents. Retrieved June 11, 2015, from http://www.digitalcrazytown.com/2014/04/verizon-data-breach-reportnine.html

31

EcuRed. (n.d.). Arquitectura de tres niveles. Retrieved June 11, 2015, from http://www.ecured.cu/index.php/Arquitectura_de_tres_niveles Infoinnova. (n.d.). Programadores Vs. Diseñadores Vs. Administradores de Proyecto « Espacio Digital. Retrieved June 11, 2015, from http://infoinnova.net/2011/08/programadores-vs-diseadores-vsadministradores-de-proyecto/ Martínez, L., & Espinoza, H. (n.d.). Owasp Top 10. Retrieved June 11, 2015, from http://slideplayer.es/slide/1048631/ Milano, L. P. (2007). Seguridad en el ciclo de vida del desarrollo de software. Owasp. (2013). Owasp Top Ten 10-2013, 22. Retrieved from www.owasp.org Tutorialspoint.com. (n.d.). Software Development Life Cycle (SDLC). Web

SEO. (2007). Canonicalización. Retrieved http://www.webseo.es/canonicalizacion/

June

11,

2015,

from

Wiki Informática de la UTFSM. (2012). Web and HTTP - Departamento de Informatica. Retrieved June 11, 2015, from http://wiki.inf.utfsm.cl/index.php?title=Web_and_HTTP Wikipedia. (n.d.). Términos informáticos. Retrieved June 12, 2015, from http://es.wikipedia.org/wiki/Token_(inform%C3%A1tica)

32