• Categories
• Seguridad y privacidad en línea
• Seguridad informática
• Cortafuegos (Informática)
• Servidor HTTP Apache
• Red mundial

Citation preview

Seguridad de las aplicaciones online [2.1] ¿Cómo estudiar este tema? [2.2] Política de seguridad. Principios de seguridad [2.3] Estándares de seguridad de aplicaciones [2.4] Vulnerabilidades en seguridad. OWASP TOP TEN, SANS TOP 25 [2.5] Vulnerabilidades de seguridad en aplicaciones web. Análisis y características [2.6] Evaluación de la seguridad de las aplicaciones web

TEMA

2

[2.7] Seguridad online

TEMA 2 – Esquema

2 ataques

Amenazas y

aplicaciones web

Vulnerabilidades en

Seguridad online: Protección Monitorización Auditoría Backups

Análisis y test de seguridad de las aplicaciones web: Análisis estático Análisis dinámico Análisis híbrido

Estándares de seguridad

Principios de seguridad

POLÍTICA de SEGURIDAD:

Seguridad de las aplicaciones online

Seguridad en Aplicaciones en Línea

Esquema

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

Ideas clave 2.1. ¿Cómo estudiar este tema? Para el estudio del apartado 2.2. «Política de seguridad, principios de seguridad» debes leer las páginas 144-164 del libro Seguridad en las comunicaciones y la información, de Gabriel Díaz Orueta. Para los apartados 2.3., 2.5. y 2.7. se ha de seguir el documento elaborado por el profesor para este tema 2: «Seguridad de las aplicaciones online» Para el estudio del punto 2.4, leer el apartado 2.5 de la guía: The WASC Threat Classification

v2.0.

Recuperado

el

24

de

abril

de

2013

de:

http://projects.webappsec.org/w/page/13246978/Threat%20Classification Para los apartados 2.7.se ha de seguir el documento elaborado por el profesor para este tema 2: «Seguridad de las aplicaciones online» y además: OWASP Development Guide 2.0.1, licencia libre, páginas 171 a 184. Recuperado el 24 de abril de 2013 de: https://www.owasp.org/images/b/b2/OWASP_Development_Guide_2.0.1_Spanish.pdf En este tema se abordan las actividades a realizar para obtener una seguridad lo más óptima posible de una aplicación desplegada en online. Las aplicaciones web desplegadas en las intranets de las organizaciones y en Internet suponen un amplio porcentaje del total de las aplicaciones. Debido a este hecho, este tema se centra en las medidas a adoptar para proteger estas aplicaciones ya que los problemas de seguridad de las aplicaciones no-web son un subconjunto de los problemas de las aplicaciones web. El tercer tipo de aplicaciones, en auge, son las aplicaciones móviles donde el cliente es un Smartphone, teléfono móvil, tableta, portátil, etc. Los ataques a dispositivos móviles están creciendo en la medida que aumenta el uso de las aplicaciones móviles (mcommerce) para banking, compras, etc. que se pueden utilizar desde ellos. La arquitectura de estas aplicaciones móviles es similar a la de las aplicaciones web. La

TEMA 2 – Ideas clave

3

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

mayor diferencia está en el canal de comunicación y la forma de proveer comunicación segura.

2.2. Política de seguridad. Principios de seguridad La política de seguridad de una organización es un conjunto de normas que rigen y determinan lo que se puede hacer y lo que no dentro de ella. Según el IETF se define como: «Una serie de sentencias formales (normas) que deben cumplir todas las personas que tengan acceso a cualquier información y tecnología de una organización» Entre las características más importantes de toda política de seguridad se pueden destacar [1]: Define el comportamiento apropiado para cada caso. Establece qué herramientas son necesarias y qué procedimientos. Sirve para comunicar un consenso del uso de datos y aplicaciones dentro de la organización. Proporciona una base para la demostración del uso inapropiado de recursos, por parte de empleados o de externos. La política de seguridad de una organización es algo en constante movimiento, que permite que el mantenimiento de la seguridad sea un proceso vivo y administrable de forma estructurada y organizada. Por tanto la seguridad es un proceso que se tiene que alcanzar mediante el desarrollo de la política de seguridad que ha de entenderse como algo dinámico que se tiene que actualizar observando una serie de principios de seguridad como:

TEMA 2 – Ideas clave

4

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

Principios de seguridad: Principio de mínimos privilegios. Principio de profundidad en la defensa. Principio de diversidad de la defensa. Identificación de puntos débiles. Centralización de la gestión de la seguridad. Principio de simplicidad.

Este apartado explica los tipos de normativas necesarias en una política de seguridad y también las fases y actividades a llevar a cabo dentro del proceso de seguridad de acuerdo con los principios de seguridad que deben regir toda política de seguridad. Además explica cómo es la puesta en marcha del proceso de seguridad que se puede escenificar como una rueda con las siguientes fases y actividades:

Implementación: medidas básicas, cortafuegos, redes privadas virtuales, etc.

Política de seguridad Análisis de vulnerabilidades: analizadores y pruebas

Monitorización: auditorías, sistemas de detección de intrusiones

Figura 1. Fases de la política de seguridad

TEMA 2 – Ideas clave

5

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

2.3. Estándares de seguridad de aplicaciones Para abordar el diseño de la seguridad de un sistema o aplicación es necesario obtener una adecuada visión de la tarea ante la que nos encontramos. La tarea de diseñar, implementar, probar, desplegar y proteger una aplicación en online es complicada y necesita reunir el conocimiento adecuado. Este conocimiento puede reunirse a través de varias fuentes, una de ellas es recurrir a organizaciones y estándares que se vienen ocupando desde hace tiempo de recopilar información sobre metodologías, protocolos, criptografía, paradigmas, proyectos de referencia, estudios sobre aspectos concretos de seguridad, herramientas de test, formas y herramientas de protección en tiempo real, etc. En el tema que nos ocupa, la información y el conocimiento que se puede aprovechar de un estándar de seguridad conocido pueden abarcar aspectos como: Vulnerabilidades de seguridad, naturaleza, características, importancia, estadísticas, etc. Metodologías de desarrollo de aplicaciones, ciclos de vida de desarrollo seguro, SSDLC. Metodologías de pruebas y testing de seguridad de aplicaciones. Herramientas de test de la seguridad, tipos, características, etc. Herramientas de protección online. Listas, características, etc. Metodologías de evaluación de herramientas de test de la seguridad. Benchmarks

para

evaluación

de

herramientas

de

seguridad

y

de

las

vulnerabilidades. Entre los estándares más conocidos que se dedican a la mejora de la seguridad de las aplicaciones se pueden citar los siguientes: OWASP SANS WASC MITRE CWE NIST

TEMA 2 – Ideas clave

6

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

2.4. Vulnerabilidades de seguridad en aplicaciones web Este apartado se ha de estudiar en la página web de WASC, en su proyecto «The WASC Threat Classification v2.0». Las vulnerabilidades de esta clasificación tienen su correspondencia con otras clasificaciones vistas anteriormente como OWASP TOP TEN y SANS TOP 25: http://projects.webappsec.org/w/page/13246978/Threat%20Classification Tiene como objetivo entender cómo se dan las principales vulnerabilidades y amenazas en las aplicaciones web que se pueden consultar en el enlace anterior, la idea es entender la naturaleza de cada vulnerabilidad de la tabla 1, extraer el concepto de cada una: Attacks

Weaknesses

Abuse of Functionality

Application Misconfiguration

Brute Force

Directory Indexing

Cross-Site Scripting

Improper Filesystem Permissions

Cross-Site Request Forgery

Improper Input Handling

Denial of Service

Improper Output Handling

HTTP Response Splitting

Information Leakage

Path Traversal

Insufficient Anti-automation

Remote File Inclusion (RFI)

Insufficient Authentication

Session Fixation

Insufficient Authorization

SQL Injection

Insufficient Session Expiration

URL Redirector Abuse

Insufficient Transport Layer Protection Server Misconfiguration

Tabla 1 .The WASC Threat Classification v2.0. Vulnerabilidades más importantes

2.5. OWASP TOP TEN, SANS TOP 25 Las vulnerabilidades de software son simplemente debilidades en un sistema que los atacantes pueden aprovechar para obtener alguna ventaja. En el contexto de la seguridad del software, las vulnerabilidades son defectos o descuidos específicos en una parte del software que permiten que los atacantes hagan algo malicioso o que

TEMA 2 – Ideas clave

7

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

alteren información sensible o que interrumpan o destruyan un sistema o tomar el control de un sistema informático o de un programa. Son errores, o descuidos en los programas que dan lugar a comportamiento inesperado y típicamente indeseable. Se puede afirmar que para que una vulnerabilidad (debilidad en el diseño, código, configuración, protección online de una aplicación) se materialice en una aplicación y se genere un impacto de negocio para la organización, es necesario que intervengan una serie de factores: Agente o amenaza, es la persona que realiza el ataque. Vectores de ataque, medio del que se sirve para llevar a cabo el ataque. Debilidad, vulnerabilidad de seguridad. Ausencia o fallo en el control. Impacto en algún activo de los sistemas de información de la organización. Impacto en el negocio de la organización. En este apartado se examinan varias clasificaciones de importantes estándares como OWASP TOP TEN ó SANS TOP 25 que son el resultado de estudios detallados de la frecuencia e importancia por el daño que ocasionan de las vulnerabilidades que tienen las aplicaciones desplegadas y los ataques que sufren aprovechando la existencia de las citadas vulnerabilidades. Asimismo se analiza la evolución y tendencia de los ataques y vulnerabilidades a lo largo de un período de tiempo para entender sobre todo qué buscan los atacantes en cada momento y preparar la defensa de las aplicaciones teniendo también ese conocimiento como base.

2.6. Evaluación de la seguridad de las aplicaciones web Una vez desarrollada la primera versión de la aplicación o por partes de la misma, pasar a la detección mediante revisiones de código manuales o con diversos tipos de herramientas automáticas especializadas de revisión de código fuente o ejecutable de tipo estático, de tipo dinámico en tiempo de ejecución y otras que se verán más adelante. También se puede contemplar el análisis manual de Stuttard [21] en un intento de «hackeo ético» de la aplicación desplegada, lo cual, supone personal muy especializado y aún así es muy difícil cubrir toda la superficie de ataque de la aplicación y costoso en tiempo. Para llevar a cabo un análisis de seguridad de una aplicación web, realizado

TEMA 2 – Ideas clave

8

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

con cualquier método, se tiene que cubrir toda la superficie de ataque de la misma cubriendo todas la partes y capas de la aplicación. En consecuencia con lo anterior, es necesario utilizar herramientas que automaticen el análisis de la seguridad para poder cubrir lo más posible la superficie de ataque de una aplicación que puede tener millones de líneas de código. Los tipos de herramientas semiautomáticas

(requieren

auditoría

posterior

de

sus

informes)

más

recomendables para llevar a cabo una evaluación de la seguridad de la aplicación según la fase del SSDLC son: Análisis estático de codigo fuente / ejecutable WhiteBox. SAST (static analysis security tools) Análisis dinámico BlackBox, DAST (dynamic analysis security tools) Análisis dinámico WhiteBox. RAST (real analysis security tools) o también denominadas IAST (Interactive analysis security tools) Herramientas híbridas de las tecnologías anteriores: o SAST-DAST o DAST-RAST o SAT-DAST-RAST En este apartado se profundiza en las características de cada uno de los tipos de herramientas y su arquitectura y sobre todo en las posibilidades de cada una en cuanto a las posibilidades de detección de amenazas y la calidad de sus informes de análisis de vulnerabilidades de seguridad. Lo ideal sería disponer de una herramienta híbrida de los tipos SAST, DASD y RAST que permite correlación de resultados y por tanto una mejor unificación de los mismos y de depuración de resultados. Para cubrir toda la superficie de ataque de una aplicación en un análisis lo más deseable es utilizar varios tipos de herramientas e incluso varias del mismo tipo para obtener mejores resultados de conjunto. Las herramientas SAST, por ejemplo, según el fabricante utilizan distintos métodos y algoritmos de búsqueda de vulnerabilidades por lo que analizando el mismo código los resultados pueden diferir bastante. Por todo esto es necesario combinarlas en un ciclo de vida de desarrollo seguro SSDLC como el de la figura 2.

REQUISITOS

Diseño

TEMA 2 – Ideas clave

IMPL

Ó

9

PRUEBAS

DESPLIEGUE

--------->

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

Figura 2. SSDLC

Se aportan también estadísticas comparativas de resultados de análisis de aplicaciones por parte de empresas que se dedican al análisis de la seguridad de aplicaciones y de consorcios dedicados a la seguridad de aplicaciones web conocidos.

2.7. Seguridad en el diseño de las aplicaciones web En este apartado se aborda el diseño del control de acceso en aplicaciones web, que tiene 3 fases:

Figura 3. Fases del control de acceso.

Un control de acceso a aplicaciones web requiere de un diseño y de una implementación segura de cada una de las fases. Por sus características las aplicaciones web utilizan el protocolo http con una serie de problemáticas (ver apartado 3.1) que hay que superar desde el punto de vista de la seguridad.

TEMA 2 – Ideas clave

10

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

2.8. Seguridad online Como se comentó al comienzo del tema, la seguridad online de las aplicaciones tiene como punto de partida la política de seguridad de la organización, que además de contemplar los procesos de desarrollo de sistemas y aplicaciones estableciendo un SSDLC, ciclo de vida de desarrollo de software seguro, debe establecer adecuados controles de protección, de auditoría y monitorización y de los mecanismos y medios de respuesta ante los incidentes detectados que hagan volver a los entornos a la normalidad. Una aceptable garantía de seguridad para una aplicación desplegada en producción pasa por haber realizado cada una de las prácticas de seguridad de cada una de las fases de seguridad del SSDLC (figura 4): Derivación de requisitos de seguridad y de casos de abuso. Análisis y gestión del riesgo. Análisis de código. Pruebas funcionales de seguridad. Test de penetración. Revisión externa. Operaciones de seguridad.

Figura 4. Modelo de SSDLC de MacGraw.

TEMA 2 – Ideas clave

11

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

En cada fase del SSDLC, se tiene que abordar el diseño de la seguridad inherente a la propia aplicación (la seguridad de la plataforma, sistemas operativos, seguridad perimetral se contempla en otras asignaturas). Los aspectos a abordar para que la seguridad de la aplicación sea lo más óptima posible pasan por un diseño e implementación seguros de: Seguridad física, del personal e instalaciones. Autenticación, autorización y gestión del estado de sesión. Validación de entradas y salidas de la aplicación. Configuración segura: Cliente, Servidor y Conexiones entre capas. Mecanismos de protección externos. Firewalls de aplicaciones web.

SERVIDOR BASE DE DATOS

SERVIDOR APLICACIONES

NAVEGADOR

APLICACION

SEGURIDAD USUARIO LOPD-LSSICE

SEGURIDAD CONEXIÓN

SEGURIDAD CONEXIÓN GESTION DE SESIONES

AUTENTICACION - AUTORIZACION

Figura5. Arquitectura de 3 capas de aplicaciones web.

Las operaciones de seguridad que hay que llevar a cabo la aplicación desplegada incluyen: Auditoría y monitorización. Gestión de incidentes, backups y recuperación, centro de respaldo. Formación continua. Por último, no hay que olvidar que una adecuada formación y concienciación continua en todo lo que se refiere a aspectos de seguridad es imprescindible fomentando en la empresa una cultura por la «seguridad» acorde con los tiempos que corren, donde cada vez parece que surgen más y nuevas amenazas que requieren estar prevenidos y preparados para hacerles frente en la mejor medida posible.

TEMA 2 – Ideas clave

12

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

Cuando se materializa una amenaza, hay que detectarla y en función de su naturaleza actuar en consecuencia de la mejor forma y medida posible, de tal forma, que el daño posible para la empresa se minimice al máximo y el impacto sufrido por sus activos sea el menor posible. El impacto es directamente proporcional al coste económico. En el apartado de la seguridad han de intervenir y estar concienciados todos los elementos de la organización, de nada sirve invertir ingentes cantidades de dinero en equipamiento como firewall, IDS,s, etc. si luego su configuración no se realiza de forma segura de acuerdo con estándares o si alguien suministra información aparentemente no importante a alguien que tampoco lo parecía, o deja información al alcance de terceros por descuido. Todas estas negligencias que pueden suponer fugas en la seguridad y son la causa finalmente en grandes pérdidas económicas y de competitividad para la organización. La formación y concienciación en seguridad es fundamental en todos los estamentos de la organización. Normalmente, cualquier medida que implique concienciar al personal o implantar cualquier medida o procedimiento de seguridad en cualquier parte de un área o departamento causa fastidio o rechazo por parte del personal que ha de observarlas. La mejor forma de tener éxito en este campo es intentar conseguir que cada individuo entienda y comprenda la importancia de la medida, que tiene que ver finalmente con alcanzar los objetivos de la organización y que el fallo o descuido personal tiene incidencia en lo colectivo.

TEMA 2 – Ideas clave

13

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

Material complementario Lecciones magistrales Análisis de seguridad de las aplicaciones web Cómo se puede llevar a cabo el Análisis de la seguridad de las aplicaciones web mediante herramientas semi-automáticas de distinto tipo de forma que se puedan combinar y complementar para cubrir toda la superficie de ataque de una aplicación en un tiempo razonable. El vídeo está disponible en el aula virtual.

No dejes de leer… Attacking Web Application Management Scambray, J., Liu, V., and Sima, C. (2011). Hacking exposed web applications (3ªEd.) McGraw Hill El libro trata los ataques a la administración y gestión de servidores de aplicaciones web, es especialmente recomendable la lectura del Capítulo 8 sobre Attacking Web Application Management. Accede al libro desde el aula virtual o a través de la siguiente dirección web: http://old.shahed.ac.ir/references/HackingExposedTMWebApplicationsJoelScambray.pdf

TEMA 2 – Material complementario

14

Seguridad en Aplicaciones en Línea

Seguridad en servidores de aplicaciones Web Ampliación sobre seguridad en servidores de aplicaciones Web. En ellos se instalan las aplicaciones web y en estas guías se abordan todos los aspectos que tienen que ver con la seguridad de un servidor de aplicaciones genérico que puede servir como base para implementar todos los aspectos de seguridad de cualquier servidor de aplicaciones. Accede al documento desde el aula virtual o a través de la siguiente dirección web: http://csrc.nist.gov/publications/nistpubs/800-44-ver2/SP800-44v2.pdf

Seguridad en BEA WEBLOGIC Seguridad en servidores de aplicaciones BEA WEBLOGIC. Es un guía específica de uno de los servidores de aplicaciones comerciales más utilizados hoy en día. Accede al documento desde el aula virtual o a través de la siguiente dirección web: http://www.nsa.gov/ia/_files/webs/I33-004R-2005.pdf

Seguridad en APACHE TOMCAT Seguridad en servidores de aplicaciones APACHE TOMCAT. Es una guía específica de uno de los servidores de aplicaciones open source más utilizados hoy en día. Accede al documento desde el aula virtual o a través de la siguiente dirección web: https://www.owasp.org/index.php/Securing_tomcat#Status https://tomcat.apache.org/tomcat-7.0-doc/security-howto.html

TEMA 2 – Material complementario

15

Seguridad en Aplicaciones en Línea

Seguridad en navegadores web Documentos con información sobre seguridad en distintos navegadores web. La capa cliente constituye el objetivo más frecuente de ataques de las aplicaciones web. Es necesario hacer hincapié en la configuración segura del equipo del cliente y del navegador web instalado. Accede a los documentos desde el aula virtual o a través de las siguientes direcciones web: Deploying and Securing Google Chrome in a Windows Enterprise https://www.iad.gov/iad/library/ia-guidance/securityconfiguration/applications/deploying-and-securing-google-chrome-in-a-windowsenterprise.cfm Guide to Securing Netscape 7.02: http://isp.netscape.com/ Browser Security Handbook, part 2: http://code.google.com/p/browsersec/wiki/Part2#Protocol-level_encryption_facilities

SAST vs DASD El proyecto abierto de WASC

Web Application Security Statistics, presenta

estadísticas comparativas, muy interesantes sobre análisis de seguridad de aplicaciones web realizado tanto con herramientas de análisis estático de caja blanca como dinámicas de caja negra. Accede al documento desde el aula virtual o a través de la siguiente dirección web: http://projects.webappsec.org/w/page/13246989/Web%20Application%20Security%2 0Statistics

TEMA 2 – Material complementario

16

Seguridad en Aplicaciones en Línea

Hp Fortify Security Center, Whitehat Sentinel Soluciones comerciales de seguridad integradas que ofrecen soluciones y herramientas de seguridad de caja blanca y de caja negra: SAST- DASD –RAST (IAST), necesarias para realizar un análisis de seguridad eficaz en un tiempo razonable permitiendo incrementar, a la vez, el conocimiento que se tiene de la aplicación con vistas a abordar la solución de los problemas de seguridad encontrados. Accede al documento desde el aula virtual o a través de la siguiente dirección web: http://www8.hp.com/us/en/softwaresolutions/software.html?compURI=1337262#tab=TAB2

No dejes de ver… OWASP Webgoat project: Movie Demonstration Solutions Tutorial (información y vídeos) del proyecto abierto OWASP, sobre las vulnerabilidades más frecuentes e importantes que sufren de las aplicaciones web. Cada vídeo muestra como se materializa una amenaza concreta sobre una vulnerabilidad existente en la aplicación web.

Accede al vídeo desde el aula virtual o a través de la siguiente dirección web: https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

TEMA 2 – Material complementario

17

Seguridad en Aplicaciones en Línea

A fondo Evaluación de DAST y SAST El consorcio abierto WASC pone a nuestra disposición su proyecto sobre los criterios para evaluación de herramientas DAST y SAST para análisis de la seguridad DAST y SAST de las aplicaciones web. Accede a los documentos desde el aula virtual o a través de las siguientes direcciones web:

WASC: Web Application Security Scanner Evaluation Criteria: http://projects.webappsec.org/w/page/13246986/Web%20Application%20Security%2 0Scanner%20Evaluation%20Criteria WASC: Static Analysis Tool Evaluation Criteria: http://json.org/json-es.html

WASC: Web Application Firewall Evaluation Criteria El consorcio abierto WASC pone a nuestra disposición su proyecto sobre los criterios para evaluación de CORTAFUEGOS que se pueden utilizar en la protección online de las aplicaciones web mediante la creación de reglas de protección que actúan sobre los puertos más utilizados por estas aplicaciones. Accede al documento desde el aula virtual o a través de la siguiente dirección web: http://projects.webappsec.org/w/page/13246985/Web%20Application%20Firewall%2 0Evaluation%20Criteria

TEMA 2 – Material complementario

18

Seguridad en Aplicaciones en Línea

Webgrafía WASC Página web del Web Application Security Consortium, una Organización sin ánimo de lucro, formada por un grupo internacional de expertos, profesionales de la industria y representantes de organizaciones que producen software libre y ampliamente acordados estándares de seguridad de mejores prácticas para la World Wide Web.

http://www.webappsec.org/

NIST Sitio web del National Institute of Standars and Technology: information Technology Laboratory. Reúne amplio conocimiento, guías, recursos y proyectos sobre la implementación de la seguridad del software de aplicaciones, sistemas operativos, bases de datos y redes de comunicaciones entre otros.

http://csrc.nist.gov/

Bibliografía Bibliografía básica Díaz Orueta, G. Seguridad en las comunicaciones y la información. Universidad Nacional de Educación a Distancia.

TEMA 2 – Material complementario

19

Seguridad en Aplicaciones en Línea

OWASP. (2005). Una Guía para Construir Aplicaciones y Servicios Web Seguros. (pp. 146

a

154

y

171

a

184).

Recuperado

el

25

de

abril

de

2013

de:

https://www.owasp.org/images/b/b2/OWASP_Development_Guide_2.0.1_Spanish.p df Swanson, M., Bowen, P., Wohl Phillips, A., Gallup, D., y Lynes, D. Contingency Planning Guide for Federal Information Systems (pp. 5 a 10). NIST. Recuperado el 25 de abril de 2013 de: http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp80034-rev1_errata-Nov11-2010.pdf Tracy, M., Jansen, W., Scarfone, K., y Winograd, T. (2007). Guidelines on Securing Public Web Servers. (pp. 5-1 a 5-9, 7-1 a 7-2, 9-1 a 9-5, 9-5 a 9-9 y 9-14). NIST. Recuperado el 25 de abril de 2013 de: http://csrc.nist.gov/publications/nistpubs/80044-ver2/SP800-44v2.pdf WASC. (2010). The WASC Threat Classification v2.0. Recuperado el 25 de abril de 2013 de: http://projects.webappsec.org/w/page/13246978/Threat%20Classification

Bibliografía complementaria Cannings, R., Dwivedi, H., & Lackey, Z. (2008). Hacking exposed web applications. Web 2.0. Mcgraw Hill. OWASP. OWASP top ten proyect. Recuperado el 25 de abril de 2013 de: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project Ristic, I. (2012). Modsecurity. Feisty Duck. Recuperado el 25 de abril de 2013 de: https://www.feistyduck.com/books/modsecurity-handbook/modsecurity-handbookgetting-started-may-2012.pdf Scambray, J., Liu, V., & Sima, C. (2010). Hacking Exposed Web Applications 3. McGraw-Hill/Osborne. Veracode. State of Software Security Report. Volume 4. Recuperado el 25 de abril de 2013 de: http://www.veracode.com/reports/index.html

TEMA 2 – Material complementario

20

Seguridad en Aplicaciones en Línea

Actividades Trabajo: Test de penetración a la aplicación BADSTORE utilizando un Scanner de vulnerabilidades de aplicaciones web Pautas de elaboración Descarga: ORACLE virtualbox desde https://www.virtualbox.org/ e instala ZAP desde: https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project Descarga la máquina virtual con la aplicación BADSTORE, desde: https://www.dropbox.com/sh/7ewzuosszqslkok/AADL6CSiXkoFPWdmfnwjHDLYa ?dl=0 Importa el servicio virtualizado badstore.ova desde ORACLE virtualbox. En configuración - almacenamiento, asocia la imagen BadStore-212.iso en el controlador IDE (cdrom) y configura la máquina virtual para que arranque primero desde el cdrom. Crear una red virtualbox HOST ONLY – virtualbox- file- preferencias- red- redes solo anfitrión- añadir una red- habilitar DCHP y configurar de la siguiente forma:

Configura el adaptador der red solo-anfitrión con las siguientes direcciones:

TEMA 2 – Actividades

21

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

Importa el servicio virtualizado badstore.ova desde ORACLE virtualbox. En configuración - almacenamiento, asocia la imagen BadStore-212.iso en el controlador IDE (cdrom) y configura la máquina virtual para que arranque primero desde el cdrom. Arranca la máquina virtual y ejecuta ifconfig para comprobar la dirección IP asociada al dispositivo eth0. Realiza el test de penetración de la aplicación BADSTORE con el Scanner de vulnerabilidades ZAP atacando a la dirección asociada al dispositivo eth0 obtenida en el paso anterior cambiando dir_ip por la dirección: ej.: http://dir_ip/cgibin/badstore.cgi Audita manualmente al menos tres vulnerabilidades para comprobar la veracidad de las alertas por parte de ZAP. Debes confeccionar una memoria explicando el proceso y los resultados obtenidos adjuntando el informe de la herramienta ZAP. Extensión máxima: 15 páginas (Georgia 11 e interlineado 1,5).

TEMA 2 – Actividades

22

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

Trabajo: Instalación y pruebas del firewall de aplicaciones web open source: MODSECURITY Modsecurity es un WAF instalable embebido en HOST o como reverse proxy:

Figura 5. Modesecurity as reverse proxy http://adolfomaltez.wordpress.com/2011/05/29/apachereverse-proxy-modsecurity/

ModSecurity puede instalarse de forma embebida protegiendo un único servidor Apache o como proxy inverso protegiendo varios servidores web. La instalación de ModSecurity es la misma para estos dos tipos de despliegue, únicamente variará la configuración de Apache que en el caso de querer proteger varios servidores se deberá instalar en una máquina dedicada el servidor. Apache con el módulo ModSecurity, configurando el servidor Apache para que actúe como proxy inverso. ModSecurity realiza un filtrado de los datos de entrada y salida al servidor web bloqueando todo el tráfico que considere malicioso según unas reglas definidas. Cada una de las peticiones realizadas al servidor web son inspeccionadas por ModSecurity para comprobar que no llegue al servidor web ningún contenido no autorizado. En este ejercicio se va a instalar, configurar y probar ModSecurity protegiendo la aplicación web Mutiliidae.

TEMA 2 – Actividades

23

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

1. Instalación del entorno

Descarga e instala Oracle VM VirtualBox desde: http://www.oracle.com/technetwork/es/server-storage/virtualbox/downloads/index.html

Descarga Máquina Virtual lamp que contiene: Linux Ubuntu server + Apache + Mysql + Php (LAMP) y aplicación web php MUTILLIDAE desde: https://drive.google.com/open?id=0Bz7Tp_tMynwpTVJSZWxYS3RXOHc La máquina virtual tiene dos dispositivos de red ya configurados: » Eth0: NAT » Eth1: 192.168.2.3 Configura el adaptador de red virtual de la máquina local anfitriona (adaptador de red ORACLE VM VIRTTUALBOX) con la dirección 192.168.2.4, para tener conectividad con el servidor Ubuntu de la MV. Se recomienda realizar una copia instantánea (snapshot) o clonar la MV lamp a otra que nombraréis fwmodsecurity. De esta última forma se tendrán dos máquinas: una sin modsecurity y otra con modsecurity instalado. Las pruebas se realizarán contra las dos máquinas por separado o en la misma máquina (opción sanpshot) activandodesactivando el firewall modsecurity. Instala el firewall de aplicaciones web modsecurity+modevasive en la MV fwmodsecurity:

TEMA 2 – Actividades

24

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

sudo apt-get update (actualizar repositories de software) sudo

apt-get

install

libapache2-mod-security2

libapache2-modsecurity

libapache2-mod-evasive

Para habilitar las reglas mod_security, copier el fichero de configuración mod_security, editarlo y establecer el parámetro ‘SecRuleEngine’ a On: sudo cp /etc/modsecurity/modsecurity.conf{-recommended,} sudo nano /etc/modsecurity/modsecurity.conf SecRuleEngine On

SecRequestBodyLimit 32768000 SecRequestBodyInMemoryLimit 32768000

SecResponseBodyAccess Off

Las reglas modsecurity están en: /usr/share/modsecurity-crs/base_rules /usr/share/modsecurity-crs/optional_rules /usr/share/modsecurity-crs/experimental_rules

Descargar OWASP modsecurity Core Rule Set: sudo git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git sudo mv /usr/share/modsecurity-crs /usr/share/modsecurity-crs.bak sudo mv owasp-modsecurity-crs /usr/share/modsecurity-crs sudo

mv

/usr/share/modsecurity-crs/modsecurity_crs_10_setup.conf.example

/usr/share/modsecurity-crs/modsecurity_crs_10_setup.conf sudo

ln

-s

/usr/share/modsecurity-crs/base_rules/*.conf

/usr/share/modsecurity-crs/activated_rules/

Comentar líneas (carácter # al comienzo de línea) 20, 27, 29 del fichero modsecurity_crs_35_bad_robots.conf (esto ocurre porque la versión de reglas es posterior a la de modsecurity y este no está preparado para unas pocas acciones, se podría instalar una versión de reglas más antigua o mejor comentar las directivas siguientes. Si en el momento de la instalación de modsecurity, su versión ha

TEMA 2 – Actividades

25

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

cambiado con respecto a esta, es posible que sean otras reglas las que haya que comentar, la información de reglas a comentar aparece en pantalla al reiniciar el servicio apache2): #SecRule

REQUEST_HEADERS:User-Agent

"@pmFromFile

modsecurity_35_scanners.data" \ #SecRule

REQUEST_HEADERS:User-Agent

"@pmFromFile

modsecurity_35_bad_robots.data" \ #SecRule REQUEST_HEADERS:User-Agent “(?i:?:c …

\

Comentar línea: buscar la cadena dentro del fichero: “modsecurity_40_generic_attacks.conf” y comentar esa línea: sudo nano /usr/share/modsecuritycrs/activated_rules/modsecurity_crs_40_generic_attacks.conf #SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|!REQUEST_COOKIES:/_pk_ref/|REQUEST_C OOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "@pmFromFile modsecurity_40_generic_attacks.data" \

Comentar línea: buscar la cadena dentro del fichero: “modsecurity_50_outbound.conf” y comentar esa línea:

sudo nano /usr/share/modsecuritycrs/activated_rules/modsecurity_crs_50_outbound.conf #SecRule RESPONSE_BODY "!@pmFromFile modsecurity_50_outbound.data" \

Editar /etc/apache2/mods-enabled/security2.conf: sudo nano /etc/apache2/mods-enabled/security2.conf

Añadir al final de security2.conf:

IncludeOptional /etc/modsecurity/*.conf IncludeOptional "/usr/share/modsecurity-crs/*.conf" IncludeOptional "/usr/share/modsecurity-crs/activated_rules/*.conf"

TEMA 2 – Actividades

26

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

Configurar módulo mod_evasive: Sudo nano /etc/apache2/mod-enabled/mod-evasive.conf

DOSHashTableSize 3097 DOSPageCount

10

DOSSiteCount

30

DOSPageInterval 1 DOSSiteInterval

3

DOSBlockingPeriod DOSLogDir

3600

/var/log/apache2/mod_evasive.log

Crear fichero de log para mod_evasive: touch /var/log/apache2/mod_evasive.log sudo chown www-data:www-data /var/log/apache2/mod_evasive.log

Cargar módulos en Apache: sudo a2enmod headers sudo a2enmod evasive sudo a2enmod security2

Reinicio de Apache2 web server: sudo service apache2 restart

Comprobar si están actives: sudo apachectl -M | grep security2 security2_module (shared) sudo apachectl -M | grep evasive evasive20_module (shared)

TEMA 2 – Actividades

27

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

Instalar las herramientas HOIC, LOIC en la máquina anfitriona para realizar ataques de denegación de servicio distribuidos DDOS contra la aplicación web MUTILLIDAE situada en la MV:

HOIC: http://sourceforge.net/projects/highorbitioncannon/?source=typ_redirect LOIC: http://sourceforge.net/projects/loic/ PD: los antivirus dan alerta cuando se descargan, no pasa nada, se obvia la alerta. Más información sobre ataques y herramientas DDOS en:

Ataques DDOS:

http://resources.infosecinstitute.com/dangerous-ddos-distributed-denial-of-serviceon-the-rise/

Herramientas DDOS:

http://resources.infosecinstitute.com/dos-attacks-free-dos-attaking-tools 2. Pruebas de funcionamiento de modsecurity: Con el objetivo de comparar los efectos conseguidos mediante ataques a la aplicación mutillidae, hay que llevar a cabo las siguientes pruebas en cada una de las dos máquinas por separado (lamp, fwmodsecurity). Debido a que tienen la misma dirección IP, hay que realizar las pruebas con una sola máquina virtual arrancada. Se arranca una máquina, se pasan todas las pruebas, se monitorizan y se recogen resultados; y, posteriormente, se realiza la misma operación con la otra máquina. También se puede utilizar solo la máquina fwmodsecurity habilitando y deshabilitando el firewall mediante el parámetro SecRuleEngine On/Off en /etc/modsecurity/modsecurity.conf Comprobar: » Accede al servidor Apache desde el navegador de la máquina local mediante la dirección IP de la máquina Ubuntu server donde está instalado el servidor Apache. Si está correctamente instalado MODSECURITY prohibirá el acceso, ya que existe una regla que impide acceder mediante dirección IP. Solo se permite por defecto acceso mediante nombres de dominio con DNS configurado. Para permitir el acceso mediante dirección IP el alumno deberá deshabilitar la regla que impide tal acceso y comprobar posteriormente que ya se permite acceder mediante dirección IP.

TEMA 2 – Actividades

28

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

» Después

de

deshabilitar

la

regla

anterior, mediante

http://192.168.2.3/../../../etc/passwd

comprobar la

el

acceso

herramienta

a

ncat

(https://nmap.org/ncat/, o también disponible en Kali linux) para evitar que el navegador pueda suprimir los caracteres../. Se debería prohibir el acceso. Localizar el mensaje de LOG donde se especifica la regla que impide el acceso y mostrarlo en la memoria. Ataques » Explota al menos 5 vulnerabilidades OWASP 2013-2010-2007 manualmente o con ayuda de una herramienta como ZAP o similar (DAST): SQLI, XSS, OPEN REDIRECT, LFI… » Mediante las herramientas HOIC y LOIC realiza ataques de denegación de servicio distribuidos DDOS desde la máquina anfitriona a la aplicación mutillidae instalada en las máquinas virtuales. Para realizar los ataques de DDOS y que tengan éxito, es conveniente dirigirlos a aquellas partes de la aplicación que sean más vulnerables a ataques DDOS por consumir más recursos al ser requeridas por el usuario. Por ello, se debe investigar un poco la aplicación para configurar las URLs más vulnerables y dirigir los ataques hacia ellas. Además, hay que estudiar como parametrizar los ataques con cada herramienta. Mediante distintos métodos como aplicados en todas las capas de la aplicación: » Comando TOP de Linux. » Log de la aplicación de mutillidae:  http://192.168.2.3/mutillidae/index.php?page=show-log.php » Log de S.O. Linux  /var/log/… » Log de apache/modsecurity/modevasive  /var/log/apache2… » Phpmyadmin: http://192.168.2.3/mutillidae/phpmyadmin/  mysql estado actual. » Aplicación wireshark instalada en la máquina anfitrión para grabar estadísticas de tráfico

durante

los

ataques.

Para

uso

de

wireshark

consultar:



https://www.incibe.es/CERT/guias_estudios/guias/guia_wireshark » …

TEMA 2 – Actividades

29

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

Entregable Se debe confeccionar una memoria explicando lo realizado, resaltando el análisis comparativo de los ataques realizados contra cada una de las máquinas. Se referenciarán pantallas, logs, capturas, etc. que irán en un anexo al final. Por tanto, se debe aportar en un anexo aparte copias de pantallas con resultado de comandos, logs, capturas de wireshark, navegador, herramientas DDOS, etc. que demuestren la realización correcta del ejercicio. Extensión máxima: (sin contar anexos) 15 páginas (fuente Georgia 11 e interlineado 1,5). Debe contener: índice, apartados con contenido principal, conclusiones y referencias. Entrega un fichero en formato Zip o Rar, con la memoria + anexo.

TEMA 2 – Actividades

30

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

Test 1. ¿Cuáles son los principios de seguridad en los que debe basarse toda política de seguridad? A. Profundidad en la defensa, mínimos privilegios, diversidad de la defensa, gestión centralizada, sofisticación, identificación de puntos débiles, cierre completo de accesos ante incidentes. B. Profundidad en la defensa, mínimos privilegios, diversidad de la defensa, gestión delegada en niveles, simplicidad, identificación de puntos débiles, cierre completo de accesos ante incidentes. C. Profundidad en la defensa, mínimos privilegios, diversidad de la defensa, gestión centralizada, simplicidad, identificación de puntos débiles, cierre completo de accesos ante incidentes. D. A y B son correctas. 2. ¿Qué tipo vulnerabilidad contiene el siguiente fragmento de código?

A. PATH TRAVERSAL. B. SQLI. C. XSS. D. HTTP RESPONSE SPPLITING.

TEMA 2 – Test

31

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

3. ¿Qué tipo vulnerabilidad contiene el siguiente fragmento de código?

HOLA! Hi

Bienvenido al sistema …

A. PATH TRAVERSAL. B. SQLI. C. XSS. D. HTTP RESPONSE SPPLITING. 4. Señala las afirmaciones correctas en cuanto a herramientas de análisis de la seguridad SAST. A. Las herramientas SAST no cubren todo en código de la aplicación. B. Las herramientas SAST tienen falsos negativos y falsos positivos. C. Las herramientas SAST pueden analizar tanto código fuente y también las hay disponibles para código ejecutable. D. Todas las anteriores son falsas. 5. Señala la afirmación falsa. A. Las herramientas DAST encuentran menos vulnerabilidades que las de tipo SAST. B. Las herramientas de tipo DAST no pueden encontrar ciertos tipos de vulnerabilidades ya que realizan un análisis sintáctico de la aplicación. C. El análisis DAST solo puede testear las partes de la aplicación accesibles externamente. D. Todas las anteriores son falsas.

TEMA 2 – Test

32

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

6. Señala la afirmación falsa. A. Las herramientas de análisis de tipo RAST no suelen tener falsos positivos. B. Las herramientas RAST se pueden utilizar como firewalls de aplicaciones web de tipo software. C. Las herramientas de tipo RAST normalmente no tienen impacto en el rendimiento. D. Las herramientas RAST pueden detectar únicamente, bloquear o sanear la petición. 7. Señala la afirmación falsa. A. Los métodos de autenticación más seguros son aquellos basados en: hardware tokens, one-time passwords, biometric authentication, and SSL/TLS client certificates B. Los métodos de autenticación basados en passwords y digest son débiles. C. AES 256 es menos seguro que T-DES. D. SSL-TLS posibilita autenticación de servidor y de cliente. 8. HTTP y procedencia de las peticiones, señala la afirmación falsa: A. Una aplicación web que usa cookies de sesión debe tomar precauciones especiales para asegurar que un atacante no pueda engañar a usuarios enviando falsas peticiones. B. Las aplicaciones que pasan el identificador de sesión en la URL y no un cookie, no tienen este problema. C. Todas las demás son falsas. D. Para las aplicaciones que usan cookies de sesión, el formulario debe incluir alguna información para que formulario de back-end pueda validar la procedencia de la petición.

TEMA 2 – Test

33

© Universidad Internacional de La Rioja (UNIR)

Seguridad en Aplicaciones en Línea

9. La validación de entradas y salidas de la aplicación es un requisito. Señala las afirmaciones correctas: A. Los datos enviados por medio del URL, lo cual se desaconseja enérgicamente, pueden ser codificados y descodificados. Esto reduce la posibilidad de ataques del tipo «cross-site-scripting». B. Es más aconsejable utilizar técnicas de validación de whitelisting (buenos conocidos) que de blacklisting (malos conocidos). C. El solo rechazo de los actuales «malos conocidos» es suficiente si la entrada es una cadena de caracteres. D. Siempre que codifique para una tecnología en particular, se debería determinar qué caracteres son «especiales» y prevenir que aparezcan en las entradas de datos o tratarlos adecuadamente. 10. Respecto a las variantes de instalación de los firewalls de aplicaciones web, señala las afirmaciones correctas: A. La configuración en modo proxy inverso es la menos deseable. B. Se debe proporcionar redundancia en la configuración con DOS WAF. C. Pueden efectuar validaciones de tipo whitelist, blacklist o una combinación de ambos tipos. D. Blacklist, consiste en mantener una base de datos de firmas de ataques mientras que whitelist consiste en tener un modelo de tráfico aceptado entre la aplicación y el cliente.

TEMA 2 – Test

34

© Universidad Internacional de La Rioja (UNIR)