Tema 2

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
[2.7] Seguridad online
2 TEMA
Esquema
TEMA 2 – Esquema
Seguridad de las aplicaciones online
POLÍTICA de SEGURIDAD:
Principios de seguridad
Estándares de seguridad
2
Análisis y test de seguridad Seguridad online:
Vulnerabilidades en
de las aplicaciones web: Protección
aplicaciones web
Análisis estático Monitorización
Amenazas y
Análisis dinámico Auditoría
ataques
Análisis híbrido Backups
© 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 (m-
commerce) 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)

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:

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 Monitorización:
vulnerabilidades: auditorías, sistemas
analizadores y de detección de
pruebas intrusiones
Figura 1. Fases de la política de seguridad

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

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

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

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 IMPL PRUEBAS DESPLIEGUE --------->

Ó

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.

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.

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 SERVIDOR
APLICACIONES BASE DE
DATOS
NAVEGADOR
APLICACION
SEGURIDAD USUARIO SEGURIDAD CONEXIÓN SEGURIDAD CONEXIÓN

LOPD-LSSICE
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.

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.

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/HackingExposedTMWebApplications-
JoelScambray.pdf
TEMA 2 – Material complementario 14

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.

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.

https://www.owasp.org/index.php/Securing_tomcat#Status
https://tomcat.apache.org/tomcat-7.0-doc/security-howto.html

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/security-
configuration/applications/deploying-and-securing-google-chrome-in-a-windows-
enterprise.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.

http://projects.webappsec.org/w/page/13246989/Web%20Application%20Security%2
0Statistics

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.

http://www8.hp.com/us/en/software-
solutions/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

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.

http://projects.webappsec.org/w/page/13246985/Web%20Application%20Firewall%2
0Evaluation%20Criteria

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.

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/sp800-
34-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/800-
44-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-handbook-
getting-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

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)

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/cgi-
bin/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).

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/apache-

reverse-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.

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) activando-
desactivando el firewall modsecurity.
Instala el firewall de aplicaciones web modsecurity+modevasive en la MV

fwmodsecurity:

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

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/modsecurity-

crs/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/modsecurity-

crs/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:
<ifmodule security2_module>
IncludeOptional /etc/modsecurity/*.conf
IncludeOptional "/usr/share/modsecurity-crs/*.conf"
IncludeOptional "/usr/share/modsecurity-crs/activated_rules/*.conf"
</IfModule>

Configurar módulo mod_evasive:
Sudo nano /etc/apache2/mod-enabled/mod-evasive.conf
<ifmodule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 10
DOSSiteCount 30
DOSPageInterval 1
DOSSiteInterval 3
DOSBlockingPeriod 3600
DOSLogDir /var/log/apache2/mod_evasive.log
</ifmodule>
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)

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-service-
on-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.

» Después de deshabilitar la regla anterior, comprobar el acceso a

http://192.168.2.3/../../../etc/passwd mediante la herramienta 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
» …

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.

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
C. Profundidad en la defensa, mínimos privilegios, diversidad de la defensa,
gestión centralizada, simplicidad, identificación de puntos débiles, cierre
D. A y B son correctas.
2. ¿Qué tipo vulnerabilidad contiene el siguiente fragmento de código?

<%
response.sendRedirect("/by_lang.jsp?lang="+
request.getParameter("lang"));
%>
A. PATH TRAVERSAL.
B. SQLI.
C. XSS.
D. HTTP RESPONSE SPPLITING.
TEMA 2 – Test 31 © Universidad Internacional de La Rioja (UNIR)

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

<HTML>
<TITLE>HOLA!</TITLE>
Hi
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
Bienvenido al sistema
…</HTML>
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.


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.

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.

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

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Tema 2

Загружено:

Авторское право:

Доступные форматы

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

[2.5] Vulnerabilidades de seguridad en aplicaciones web. Análisis y

[2.6] Evaluación de la seguridad de las aplicaciones web

[2.7] Seguridad online

© Universidad Internacional de La Rioja (UNIR)

2.1. ¿Cómo estudiar este tema?

TEMA 2 – Ideas clave 3 © Universidad Internacional de La Rioja (UNIR)

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

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

Define el comportamiento apropiado para cada caso.

La política de seguridad de una organización es algo en constante movimiento,

TEMA 2 – Ideas clave 4 © Universidad Internacional de La Rioja (UNIR)

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.

Figura 1. Fases de la política de seguridad

TEMA 2 – Ideas clave 5 © Universidad Internacional de La Rioja (UNIR)

2.3. Estándares de seguridad de aplicaciones

Para abordar el diseño de la seguridad de un sistema o aplicación es necesario

En el tema que nos ocupa, la información y el conocimiento que se puede aprovechar de

TEMA 2 – Ideas clave 6 © Universidad Internacional de La Rioja (UNIR)

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

Tiene como objetivo entender cómo se dan las principales vulnerabilidades y

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

2.5. OWASP TOP TEN, SANS TOP 25

Las vulnerabilidades de software son simplemente debilidades en un sistema que

TEMA 2 – Ideas clave 7 © Universidad Internacional de La Rioja (UNIR)

alteren información sensible o que interrumpan o destruyan un sistema o tomar el

Agente o amenaza, es la persona que realiza el ataque.

En este apartado se examinan varias clasificaciones de importantes estándares

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,

También se puede contemplar el análisis manual de Stuttard [21] en un intento de

TEMA 2 – Ideas clave 8 © Universidad Internacional de La Rioja (UNIR)

En consecuencia con lo anterior, es necesario utilizar herramientas que automaticen el

Análisis estático de codigo fuente / ejecutable WhiteBox. SAST (static analysis

En este apartado se profundiza en las características de cada uno de los tipos de

REQUISITOS Diseño IMPL PRUEBAS DESPLIEGUE --------->

TEMA 2 – Ideas clave 9 © Universidad Internacional de La Rioja (UNIR)

Se aportan también estadísticas comparativas de resultados de análisis de aplicaciones

2.7. Seguridad en el diseño de las aplicaciones web

Figura 3. Fases del control de acceso.

Un control de acceso a aplicaciones web requiere de un diseño y de una

TEMA 2 – Ideas clave 10 © Universidad Internacional de La Rioja (UNIR)

2.8. Seguridad online

Una aceptable garantía de seguridad para una aplicación desplegada en producción