AUDITORIA DE SEGURIDAD DEL ... -...
199
UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS CARRERA DE INGENIERIA EN NETWORKING Y TELECOMUNICACIONES AUDITORIA DE SEGURIDAD DEL SERVIDOR WEB DE LA EMPRESA PUBLYNEXT S.A. UTILIZANDO MECANISMOS BASADOS EN OWASP PROYECTO DE TITULACIÓN Previa a la obtención del Título de: INGENIERO EN NETWORKING Y TELECOMUNICACIONES AUTOR(ES): BRIONES PINCAY GERSON HAMNER HERNANDEZ PEÑAHERRERA ERIKA BELÉN TUTOR: ING. JORGE ANTONIO MAGALLANES BORBOR GUAYAQUIL – ECUADOR 2018 ´
Transcript of AUDITORIA DE SEGURIDAD DEL ... -...
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS
CARRERA DE INGENIERIA EN NETWORKING Y TELECOMUNICACIONES
AUDITORIA DE SEGURIDAD DEL SERVIDOR WEB DE LA EMPRESA PUBLYNEXT S.A. UTILIZANDO MECANISMOS BASADOS EN OWASP
PROYECTO DE TITULACIÓN
Previa a la obtención del Título de:
INGENIERO EN NETWORKING Y TELECOMUNICACIONES
AUTOR(ES): BRIONES PINCAY GERSON HAMNER
HERNANDEZ PEÑAHERRERA ERIKA BELÉN
TUTOR: ING. JORGE ANTONIO MAGALLANES BORBOR
GUAYAQUIL – ECUADOR 2018
´
REPOSITORIO NACIONAL EN CIENCIA Y TECNOLOGÍA
FICHA DE REGISTRO DE TESIS/TRABAJO DE GRADUACIÓN
TÍTULO Y SUBTÍTULO:
AUDITORIA DE SEGURIDAD DEL SERVIDOR WEB DE LA EMPRESA PUBLYNEXT S.A. UTILIZANDO MECANISMOS
BASADOS EN OWASP
AUTOR(ES): Briones Pincay Gerson Hamner / Hernández Peñaherrera Erika
REVISOR( REVISOR(ES)/TUTOR(ES):
Ing. Jorge Antonio Magallanes Borbor / Ing. Ximena Carolina Ácaro Chacón
INSTITUCIÓN: Universidad de Guayaquil
UNIDAD/FACULTAD: y Físicas
Ciencias Matemáticas y Físicas
MAESTRÍA/ESPECIALIDAD: Ingeniería en Networking y Telecomunicaciones
GRADO OBTENIDO: No. DE PÁGINAS 200
FECHA DE PUBLICACIÓN:
ÁREAS TEMÁTICAS: Redes y Telecomunicaciones
PALABRAS CLAVES: OWASP, administración, vulnerabilidades, salvaguardar análisis.
RESUMEN: El presente documento expone la realización de una auditoría de seguridad en el
servidor de la empresa Publynext S.A. Para dar a conocer el nivel de vulnerabilidad utilizando
mecanismos basados en OWASP (open web application security project) con el objetivo de
minimizar riesgos de amenazas brindando medidas de solución y recomendaciones.
ADJUNTO PDF SI: X NO
CONTACTO CON AUTOR/ES:
Teléfono: 0990329052 0978623840
E-mail: [email protected] [email protected]
CONTACTO CON LA INSTITUCIÓN
Nombre: Carrera de Ingeniería en Networking y Telecomunicaciones Teléfono: 04-2307729
E-mail: www.cisc.ug.edu.ec
II
CARTA DE APROBACIÓN DEL TUTOR
En mi calidad de Tutor del trabajo de titulación, “Auditoría De Seguridad Del
Servidor Web De La Empresa Publynext S.A. Utilizando Mecanismos
Basados En Owasp” elaborado por los Sres. Briones Pincay Gerson
Hamner y Hernández Peñaherrera Erika Belén, Alumnos no titulados de la
Carrera de Ingeniería en Networking y Telecomunicaciones de la Facultad
de Ciencias Matemáticas y Físicas de la Universidad de Guayaquil, previo a
la obtención del Título de Ingeniero en Networking y Telecomunicaciones,
me permito declarar que luego de haber orientado, estudiado y revisado, la
Apruebo en todas sus partes.
Atentamente
Ing. Jorge Antonio Magallanes Borbor
TUTOR
III
DEDICATORIA
A Dios principalmente
por sostenerme y darme
las fuerzas necesarias
para seguir cada día ya
que sin él en mi vida
nada soy.
A mi madre Elena
Peñaherrera, mi guerrera
invencible, mi motor por
el cual lucho cada día de
mi vida.
A mi Padre Edson
Hernández por estar
conmigo en todo mi
proceso, motivándome a
luchar por lo que quiero y
a no dejarme vencer por
nada.
Erika
IV
DEDICATORIA
Mi Dios quien me sostiene y me
levanta, me anima a crecer como
persona, luchar por ser un ejemplo
para mis sucesores y siempre
estar agradecido por los logros
alcanzados.
Dedico este proyecto de titulación
a mis queridos padres: Pincay
Gabriela y Briones Luis por su
apoyo incondicional, la educación
y moralidad que fomentaron en
mí, me ha ayudado a superar las
metas propuestas con respeto y
humildad, valores que resalto en
ellos. A mis hermanos, tíos,
abuelos y a mi novia que siempre
me brindaron su tiempo e interés a
mis preocupaciones, sin ellos no
hubiera podido cumplir este gran
logro.
Gerson
V
AGRADECIMIENTO
A Dios por darme la salud
y por nunca
abandonarme,
A mis padres que a pesar
de la dura prueba por la
que hoy en día pasamos,
estuvieron siempre ahí
alentándome a no
desmayar.
A mi hermano Josué
Hernández por ayudarme
en todo el cuidado de
nuestra madre y así yo
tener el tiempo para
desarrollar este proyecto.
A la empresa en la que
laboro por brindarme las
facilidades necesarias
para desarrollar este
proyecto.
Erika
VI
AGRADECIMIENTO
En primer lugar, a Dios por
darme salud, fuerzas y sabiduría
sin él no
estaría donde estoy, nunca perdí
la Fe, y gracias a ÉL, estoy por
conseguir mi Título Profesional.
A mi Madre Gabriela Esperanza
Pincay Rodríguez, quien siempre
creyó en mí, con su amor y
apoyo incondicional, no lo
hubiera logrado.
A mi Padre Luis Hamner Briones
Zúñiga, aunque la distancia no
nos dé
el tiempo necesario, siempre se
siente tu apoyo incondicional.
A mi Hermanos, mis tíos y mis
abuelos por ser parte de mi vida,
piezas importantes que me
forjaron al
crecer.
A mi Novia Melanie Lisbeth
Yánez Pincay, por estar en los
buenos y malos momentos, por
brindarme su comprensión y
apoyo incondicional.
Gerson
VII
TRIBUNAL DE PROYECTO DE TITULACIÓN
Ing. Eduardo Santos Baquerizo, M. Sc. Ing. Harry Luna Aveiga, M.Sc. DECANO DE LA FACULTAD DE DIRECTOR CINT CIENCIAS MATEMATICAS Y FISICAS
Ximena Acaro Chacón Victoria Haz López PROFESOR REVISOR PROFESOR REVISOR DEL AREA - TRIBUNAL DEL AREA - TRIBUNAL
Ing. Jorge Antonio Magallanes Borbor
PROFESOR DIRECTOR DEL PROYECTO DE TITULACIÓN
Ab. Juan Chávez A. SECRETARIO
VIII
DECLARACIÓN EXPRESA
“La responsabilidad del contenido de
este Proyecto de Titulación, me
corresponde exclusivamente; y el
patrimonio intelectual de la misma a la
UNIVERSIDAD DE GUAYAQUIL”
_____________________________________ BRIONES PINCAY GERSON HAMNER
_____________________________________ HERNANDEZ PEÑAHERRERA ERIKA BELÉN
IX
AUTORÍA
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERIA EN NETWORKING Y TELECOMUNICACIONES
“AUDITORIA DE SEGURIDAD DEL SERVIDOR WEB DE LA EMPRESA PUBLYNEXT S.A. UTILIZANDO MECANISMOS
BASADOS EN OWASP”
Proyecto de Titulación que se presenta como requisito para optar por
el título de INGENIERO EN NETWORKING Y
TELECOMUNICACIONES.
Autor: Briones Pincay Gerson Hamner
C.I.:092580982-4
Autor: Hernández Peñaherrera Erika Belén
C.I.: 093086145-5
Tutor: Ing. Jorge Antonio Magallanes Borbor
viernes, 09 de marzo de 2018
X
CERTIFICADO DE ACEPTACIÓN DEL TUTOR
En mi calidad de Tutor del proyecto de titulación, nombrado por el Consejo
Directivo de la Facultad de Ciencias Matemáticas y Físicas de la Universidad
de Guayaquil.
CERTIFICO:
Que he analizado el Proyecto de Titulación presentado por los estudiantes
BRIONES PINCAY GERSON HAMNER y HERNANDEZ PEÑAHERRERA
ERIKA BELÉN, como requisito previo para optar por el título de Ingeniero en
Networking y Telecomunicaciones cuyo tema es:
AUDITORIA DE SEGURIDAD DEL SERVIDOR WEB DE LA EMPRESA PUBLYNEXT S.A. UTILIZANDO MECANISMOS
BASADOS EN OWASP Considero aprobado el trabajo en su totalidad.
Presentado por:
BRIONES PINCAY GERSON HAMNER C.I.: 092580982-4 HERNANDEZ PEÑAHERRERA ERIKA BELÉN C.I.: 093086145-5
Tutor: Ing. Jorge Antonio Magallanes Borbor
viernes, 09 de marzo de 2018
XI
UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERIA EN NETWORKING Y TELECOMUNICACIONES
AUTORIZACIÓN PARA PUBLICACIÓN Autorización para publicación de Proyecto de Titulación en Formato Digital
1. Identificación del Proyecto de Titulación
Nombre Alumno: Gerson Hamner Briones Pincay Dirección: Cdla. Socio Vivienda Mz 4D Villa 5 Teléfono: 0990329052 E-mail: [email protected] Nombre Alumno: Hernandez Peñaherrera Erika Belén Dirección: Callejón Amazonas entre la Av. Assad Bucaram y la 32 Ava Teléfono: 0978623840 E-mail: [email protected] Facultad: Ciencias Matemáticas y Físicas Carrera: Ingeniería en Networking y Telecomunicaciones Proyecto de titulación al que opta: Ingeniero en Networking y
Telecomunicaciones
Profesor tutor: Jorge Antonio Magallanes Borbor Título del Proyecto de Titulación: Auditoria De Seguridad Del Servidor Web De La Empresa Publynext S.A. Utilizando Mecanismos Basados En Owasp Tema del Proyecto de Titulación: Auditoria De Seguridad Del Servidor Web De La Empresa Publynext S.A. Utilizando Mecanismos Basados En Owasp
XII
2. Autorización de Publicación de Versión Electrónica del Proyecto de Titulación A través de este medio autorizo a la Biblioteca de la Universidad de
Guayaquil y a la Facultad de Ciencias Matemáticas y Físicas a publicar la
versión electrónica de este Proyecto de titulación.
Publicación electrónica: Inmediata X Después de 1 año Firma de Alumnos: BRIONES PINCAY GERSON HAMNER C.I.: 092580982-4 HERNANDEZ PEÑAHERRERA ERIKA BELÉN C.I.: 093086145-5 3. Forma de envío: El texto del proyecto de titulación debe ser enviado en formato Word, como
archivo .Doc. O .RTF y .Puf para PC. Las imágenes que la acompañen
pueden ser: .gif, .jpg o .TIFF.
DVDROM CDROM X
XIII
DICE GENERAL
ÍNDICE GENERAL
CARTA DE APROBACIÓN DEL TUTOR ................................................... II
DEDICATORIA .......................................................................................... III
AGRADECIMIENTO ................................................................................... V
TRIBUNAL DE PROYECTO DE TITULACIÓN ........................................ VII
DECLARACIÓN EXPRESA .................................................................... VIII
AUTORÍA ................................................................................................... IX
CERTIFICADO DE ACEPTACIÓN DEL TUTOR ....................................... X
AUTORIZACIÓN PARA PUBLICACIÓN ................................................... XI
ÍNDICE GENERAL .................................................................................. XIII
ABREVIATURAS ..................................................................................... XVI
ÍNDICE DE CUADROS Y TABLAS ........................................................ XVII
ÍNDICE DE GRÁFICOS ........................................................................... XIX
RESUMEN ............................................................................................... XXI
ABSTRACT ............................................................................................ XXII
INTRODUCCIÓN ........................................................................................ 1
CAPITULO I................................................................................................ 4
EL PROBLEMA .......................................................................................... 4
PLANTEAMIENTO DEL PROBLEMA ........................................................ 4
UBICACIÓN DEL PROBLEMA EN UN CONTEXTO ................................. 4
SITUACIÓN CONFLICTO. NUDOS CRÍTICOS ......................................... 6
CAUSAS Y CONSECUENCIAS DEL PROBLEMA .................................... 7
DELIMITACIÓN DEL PROBLEMA ............................................................. 8
XIV
FORMULACIÓN DEL PROBLEMA ............................................................ 8
EVALUACIÓN DEL PROBLEMA ............................................................... 9
ALCANCE DEL PROBLEMA ................................................................... 12
OBJETIVOS DE LA INVESTIGACIÓN ..................................................... 12
JUSTIFICACIÓN E IMPORTANCIA DE LA INVESTIGACIÓN ................ 13
CAPÍTULO II............................................................................................. 15
MARCO TEÓRICO ................................................................................... 15
ANTECEDENTES DE ESTUDIO ............................................................. 15
FUNDAMENTACIÓN TEÓRICA ............................................................... 19
Auditoria Informática ............................................................................. 19
Objetivos De La Auditoría Informática .................................................. 21
Alcance de la Auditoría Informática ...................................................... 21
Seguridad en las aplicaciones web ...................................................... 22
Test de Penetración .............................................................................. 22
Vulnerabilidad de las aplicaciones web ................................................ 22
Vulnerabilidad en el almacenamiento de información .......................... 25
Vulnerabilidad en los protocolos de comunicación http y https ............ 26
OWASP ................................................................................................. 27
Caja Negra ............................................................................................ 28
Documentación OWASP ...................................................................... 29
Guía de Desarrollo Web Seguro ........................................................... 29
Guía de Pruebas ................................................................................... 30
Tops 10 de OWASP ............................................................................. 30
Riesgos de seguridad en OWASP ........................................................ 31
Factores de Riesgo por OWASP .......................................................... 32
XV
Metodología de Valoración de Riesgo OWASP ................................... 38
FUNDAMENTACIÓN SOCIAL ................................................................. 47
FUNDAMENTACIÓN LEGAL ................................................................... 48
IDEA A DEFENDER ................................................................................. 59
DEFINICIONES CONCEPTUALES .......................................................... 59
CAPÍTULO III............................................................................................ 63
METODOLOGÍA DE LA INVESTIGACIÓN .............................................. 63
CAPÍTULO IV ........................................................................................... 85
PROPUESTA TECNOLÓGICA ................................................................ 85
ANALISIS ................................................................................................. 87
INFORME DE AUDITORIA ...................................................................... 92
ANÁLISIS DE FACTIBILIDAD ................................................................ 122
Factibilidad Operacional ..................................................................... 122
Factibilidad Técnica ............................................................................ 123
Factibilidad Legal ................................................................................ 125
Factibilidad Económica ....................................................................... 126
ETAPAS DE LA METODOLOGÍA DEL PROYECTO ............................. 128
ENTREGABLES DEL PROYECTO ........................................................ 129
CRITERIOS DE VALIDACIÓN DE LA PROPUESTA ............................ 129
CRITERIOS DE ACEPTACIÓN DEL PRODUCTO O SERVICIO .......... 130
CONCLUSIONES Y RECOMENDACIONES ......................................... 131
BIBLIOGRAFÍA ...................................................................................... 136
ANEXOS………………………………………………………………………
XVI
ABREVIATURAS
UG Universidad de Guayaquil
FTP Archivos de Transferencia
HTML Lenguaje de Marca de Salida de Híper Texto
Http Protocolo de Transferencia de Híper Texto
Ing. Ingeniero
URL Localizador de Fuente Uniforme
WWW World Wide Web (red mundial) XIII
OMS Organización Mundial de la Salud
JDK Kit de Desarrollo de Java
XSS Cross-site-scripting
XVII
ÍNDICE DE CUADROS Y TABLAS
Cuadro No. 1 Causas y Consecuencias ........................................................................... 7
Cuadro No. 2
Principales vulnerabilidades en aplicaciones web ................................... 23
Cuadro No. 3 Diez factores de riesgo ............................................................................. 33
Cuadro No. 4 Determinación de severidad del impacto ................................................. 40
Cuadro No. 5 Definiciones conceptuales ........................................................................ 59
Cuadro No. 6 Cuadro Distributivo de la Población ......................................................... 66
Cuadro No. 7 Tamaño de la Muestra ............................................................................. 67
Cuadro No. 8
Resultado Pregunta # 1 ............................................................................ 70
Cuadro No. 9 Resultado Pregunta # 2 ............................................................................ 71
XVIII
Cuadro No. 10 Resultado Pregunta # 3 ............................................................................ 73
Cuadro No. 11
Resultado Pregunta # 4 ............................................................................ 74
Cuadro No. 12 Resultado Pregunta # 5 ............................................................................ 76
Cuadro No. 13
Resultado Pregunta # 6 ............................................................................ 78
Cuadro No. 14
Resultado Pregunta # 7 ............................................................................ 80
Cuadro No. 15
Resultado Pregunta # 8 ............................................................................ 82
Cuadro No. 16 Recursos Humanos ................................................................................ 127
Cuadro No. 17
Criterios de Aceptación del Proyecto ..................................................... 130
XIX
ÍNDICE DE GRÁFICOS
Figura No. 1 Políticas de seguridad establecidas por OWASP .............................. 18 Figura No. 2 Ataque Genérico ................................................................................ 32 Figura No. 3 Representación de firewall en una red de computadoras .................. 44 Figura No. 4 Fragilidad con los hackers .................................................................. 70 Figura No. 5 La información dentro de la empresa es segura ................................ 72 Figura No. 6 Robo de la información ...................................................................... 73 Figura No. 7 Nivel de Amenaza .............................................................................. 75 Figura No. 8 Análisis de vulnerabilidades ............................................................... 77 Figura No. 9 Detección de vulnerabilidades ........................................................... 79 Figura No. 10 Conocimiento de OWASP .................................................................. 81 Figura No. 11 Utilización de OWASP ........................................................................ 82 Figura No. 12 Alertas por la herramienta OWASP ZAP ............................................ 94 Figura No. 13 Configuración Problema 1 .................................................................. 96
XX
Figura No. 14 Solución Input Validation .................................................................... 98 Figura No. 15 Solución Input Transformation ......................................................... 100 Figura No. 16 Configuración Problema 2 ................................................................ 102 Figura No. 17 Configuración Problema 3 ................................................................ 105 Figura No. 18 Configuración Problema 4 ................................................................ 108 Figura No. 19 Niveles de Verificación de Seguridad en Aplicaciones de OWASP . 109 Figura No. 20 Arquitectura actual de Publynext .S.A. ............................................. 111 Figura No. 21 Propuesta de solución arquitectura .................................................. 113 Figura No. 22 Propuesta con un elemento adicional .............................................. 117 Figura No. 23 Arquitectura de Publynext S.A con propuesta de solución .............. 120 Figura No. 24 Especificaciones técnicas Hardware ................................................ 124
XXI
UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS
CARRERA DE INGENIERIA EN NETWORKING Y TELECOMUNICACIONES
“AUDITORIA DE SEGURIDAD DEL SERVIDOR WEB DE LA EMPRESA PUBLYNEXT S.A. UTILIZANDO MECANISMOS BASADOS EN OWASP”
RESUMEN
Este proyecto de tesis tiene por propósito facilitar información acerca
del método y técnica que permita conocer las vulnerabilidades del
servidor web de la empresa Publynext S.A., donde se solicita
salvaguardar información confidencial e impedir que se perpetúen
ataques informáticos por usuarios maliciosos, por lo que se efectuará
un análisis por medio de prueba de penetración para conocer el nivel
de vulnerabilidad empleando mecanismos basados en OWASP (open
web application security project) con el objetivo de minimizar riesgos
de amenazas brindando medidas de solución y recomendaciones.
Palabras claves: OWASP, administración, vulnerabilidades,
salvaguardar análisis.
Autor: Briones Pincay Gerson Hamner
Autor: Hernandez Peñaherrera Erika Belén
Tutor: Ing. Jorge Magallanes
XXII
UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS
CARRERA DE INGENIERIA EN NETWORKING Y TELECOMUNICACIONES
"SECURITY AUDIT IN THE WEB SERVER OF THE COMPANY PUBLYNEXT S.A. USING MECHANISMS BASED ON OWASP”
ABSTRACT
This thesis project is intended to provide information about the method
and technique for knowing the vulnerabilities in the Publynext SA web
server, where it is requested to safeguard confidential information and
prevent the perpetuation of cyber-attacks by malicious users, so it will
be carried out an analysis by means of a penetration test to know the
level of vulnerability using the OWASP (open web application security
project) method with the objective of minimizing threat risks by
providing solution measures and recommendations.
Keywords: OWASP, administration, vulnerabilities, safeguard
analysis.
Author: Briones Pincay Gerson Hamner
Author: Hernandez Peñaherrera Erika Belén
Advisor: Ing. Jorge Magallanes
1
INTRODUCCIÓN
En el presente trabajo de titulación previo a la obtención del título de
Ingeniero en Networking y Telecomunicaciones, se realizará una Auditoria
De Seguridad en el Servidor Web de la empresa Publynext S.A. utilizando
mecanismos basados en Owasp.
En la actualidad los sistemas de información han logrado facilitar de una u
otra forma las actividades de los usuarios, almacenan grandes cantidades
de información y es prioridad de cada organización el brindar a sus
usuarios servicios que estén disponibles así como que la información que
se maneja tenga confidencialidad e integridad.
Por tal motivo un requisito muy importante en las organizaciones es que
los sistemas de información cuenten con una implementación de políticas
y técnicas de seguridad que permita que la información este segura. Los
administradores de redes/sistemas deben hacer uso de un constante
monitoreo de los servicios brindados por la organización y más si se
maneja información confidencial, de esa manera evitar cualquier riesgo de
2
amenazas mediante pruebas de detección de vulnerabilidades y plantear
métodos o planes para la mitigación de las mismas.
El proyecto contiene los capítulos que se indican a continuación:
En el capítulo I se hace mención a la identificación y planteamiento del
problema, las causas y consecuencias, los objetivos y alcance del
proyecto, el mismo que conforman un marco referencial para la
investigación.
En el capítulo II se detalla los conceptos que debemos conocer sobre el
tema para el estudio del caso, este proyecto de tesis va dedicado para
personas con un grado de conocimiento en los conocimientos de
servidores webs, programadores e instalaciones de red.
Se enfoca en presentar la metodología OWASP para el uso de nuestra
auditoria, utilizando las herramientas y documentos que caracterizan a
OWASP para el análisis de aplicaciones web.
3
En el capítulo III, se detalla las encuestas realizadas a la empresa
Publynext con su debido formulario, para el análisis en términos de
población o conocimiento del proyecto de tesis.
En el capítulo IV expondremos la propuesta o solución de la auditoria,
detallaremos las conclusiones y recomendaciones sobre el análisis que
serán expuestas en los anexos detallando el plan de contingencia.
4
CAPITULO I
EL PROBLEMA
PLANTEAMIENTO DEL PROBLEMA
UBICACIÓN DEL PROBLEMA EN UN CONTEXTO
La aparición de los sistemas de información web han logrado que
los usuarios puedan manejar la portabilidad sin la necesidad de que
instalen programas en otras estaciones de trabajo para acceder a los
archivos confidenciales de la organización, estas aplicaciones web
permiten la digitalización de los datos en mayores cantidades de volumen,
5
reduciendo el espacio en disco de los ordenadores y dando un análisis y
procesamiento rápido para el acceso a los mismos de manera eficiente.
Con este método es más fácil el acceso a la información ya que
genera portabilidad es decir que los usuarios con una conexión a la red de
internet ellos podrán obtener el ingreso a los activos lógicos desde el
sistema de aplicación web.
La empresa Publynext S.A. es una compañía dedicada a prestar
servicios a fábricas, organizaciones corporativas y demás corporaciones
referente a promocionar sus productos mediante campañas publicitarias y
cortes comerciales, además de realizar gestiones en línea. Esta empresa
se ha visto envuelta por anomalías de seguridad, en las cuales, atacantes
maliciosos han afectado la productividad de los servicios de Publynext
S.A. llegando a producir un caos en el rendimiento de los sistemas de
aplicación web.
Actualmente la empresa Publynext que presta servicios de
Marketing Y Comercialización Integral (MCI desea conocer las amenazas
informáticas por medio de una auditoria para aplicaciones web, con la
6
finalidad de asegurar la información confidencial almacenada en la base
de datos conectada al servidor web.
SITUACIÓN CONFLICTO. NUDOS CRÍTICOS
Algunas de las organizaciones de nivel público y privado no toman
en consideración la debida importancia de la confidencialidad de la
información representada en cada uno de los activos de gran importancia
para las empresas. Cada vez se presentan más vulnerabilidades y
amenazas en los sistemas de aplicación web, esto hace que la alta
gerencia esté alerta para impedir que se efectúen intrusiones maliciosas
por parte de los piratas informáticos. Sin embargo, en la mayoría de
empresas el pensamiento de los directivos, con respecto al
aseguramiento de la información de la empresa, no es considerado como
importante lo que conlleva a la falta de medidas de seguridad que puedan
impedir la perpetuación de delitos cibernéticos. Una empresa que sufre un
delito informático genera pérdidas de datos y produce daños permanentes
en las compañías.
El proveer servicios web en redes públicas sin las medidas de
seguridad adecuadas compromete la confidencialidad y la integridad de la
7
información y la expone ante cualquier atacante malicioso que pueda
manipularla y modificarla en beneficio propio causando daños en los
activos lógicos de las organizaciones.
CAUSAS Y CONSECUENCIAS DEL PROBLEMA
Cuadro No. 1 Causas y Consecuencias
Causas Consecuencias
• Información confidencial expuesta en el sistema de aplicación web de manera pública.
• Sustracción de información
sensible por parte de usuarios
internos.
• Falta de conocimiento sobre las amenazas informáticas que ocasionan daños en los sistemas de aplicación web.
• Constantes ataques
informáticos por la no toma de
consideraciones a las
amenazas.
• Poca inversión en dispositivos de seguridad informática.
• Sistemas de aplicación web
vulnerables.
Fuente: Trabajo de Investigación
Autores: Erika Hernández-Gerson Pincay
8
DELIMITACIÓN DEL PROBLEMA
Campo: Hacking Ético.
Área: Auditoría de Seguridad Informática.
Aspecto: Servidores Web.
Tema: Auditoria De Seguridad Del Servidor Web De La Empresa
Publynext S.A. Utilizando Mecanismos Basados En Owasp.
FORMULACIÓN DEL PROBLEMA
¿Cuáles son las amenazas informáticas que posee el sistema
de aplicaciones web en la empresa Publynext S.A.?
En los sistemas de aplicaciones web, las amenazas comunes
pueden ser: (1) modificaciones en la configuración de páginas web que
esté administrando la empresa, (2) robo de información, (3) modificación o
ataque por inyección en la base de datos; todas estas amenazas dan
apertura a que los crackers puedan hacer uso de la información
confidencial y dejar vulnerable el sistema de aplicaciones web de la
empresa.
9
EVALUACIÓN DEL PROBLEMA
La manera de controlar los ataques informáticos que pueden
realizar los piratas cibernéticos hacia los sistemas de aplicación web, no
es el correcto y para resolver el problema se propone la realización de
una auditoría de servidores web mediante el uso de la herramienta de
auditoria OWASP.
Los 6 aspectos generales de evaluación son los siguientes:
Delimitado: El problema presente solo se enfoca en las
vulnerabilidades de los sistemas de aplicación WEB tales como:
vulnerabilidades de SQL INJECTION, XSS, DoS (Denegación de
Servicio), la falta de una configuración robusta en los servidores WEB y
puertas traseras para aplicaciones WEB.
Claro: Las herramientas de test de intrusión enfocadas a OWASP
tales como: OWASP ZAP, MALTEGO, WEBACOO y demás que se
utilizarán en el presente proyecto definirán claramente las
vulnerabilidades y amenazas en el sistema web de la empresa Publynext
S.A. y como poder disminuirlas.
10
Conjuntamente se realizarán auditorías de seguridad web
utilizando el sistema operativo Kali Linux, en la cual se aplicarán las fases
del proyecto de OWASP.
Evidente: Se logrará detectar el comportamiento de cada
vulnerabilidad en el sistema de aplicación web al ser explotada por medio
del uso de ataques informáticos orientados a las aplicaciones web.
Además, se identificarán los riesgos que afectan a los sistemas
web de la empresa, y se dará a conocer cuáles son las vulnerabilidades
más peligrosas y que pueden producir daños en los activos de
información confidencial.
Original: El análisis de vulnerabilidades en los sistemas de
aplicación web de Publynext S.A. por medio de OWASP demuestra la
originalidad del proyecto debido a que las organizaciones no poseen
conocimiento de este tipo de auditorías de seguridad en servidores web.
11
Factible: Los mecanismos basados en OWASP a utilizar, está
enfocada en el uso de herramientas no licenciadas, es decir que no
requerirán de gastos monetarios para la implementación; lo que permitirá
el desarrollo de la auditoría en la empresa Publynext S.A. ubicada en la
ciudad de Guayaquil.
Identifica los productos esperados: Los resultados que se
generarán durante el proceso de auditoría de servidores web en la
empresa Publynext S.A. Será de gran ayuda para la misma ya que
tendrán evidencias de todas las vulnerabilidades y riesgos detectados en
el sistema de aplicación web.
Además estos resultados que se obtendrán en el desarrollo del
proyecto servirán como evidencia a la empresa para la toma de los
controles adecuados que ayudarán a proteger la información confidencial
almacenada en los sistemas de aplicación web de la compañía en
mención.
12
ALCANCE DEL PROBLEMA
En el presente proyecto se detallan los alcances que serán
cumplidos con el desarrollo del mismo y que serán indicados de la
siguiente manera: Análisis y detección de vulnerabilidades en el servidor
web de la empresa Publynext S.A. utilizando mecanismos basados en
OWASP, Evaluación de los riesgos por medio de herramientas de test de
intrusión enfocadas en OWASP, Elaboración de informes donde se
detallarán los resultados obtenidos de la auditoría de seguridad en el
servidor web en la empresa Publynext S.A. y definición de
recomendaciones basados en el estándar de seguridad de la información
ISO 27001 para evitar intrusiones maliciosas en los sistemas de
aplicación web.
OBJETIVOS DE LA INVESTIGACIÓN
OBJETIVO GENERAL
• Auditar la seguridad en el servidor web de la empresa PUBLINEXT
S.A. utilizando mecanismos basados en OWASP.
13
OBJETIVOS ESPECÍFICOS
• Evaluar las vulnerabilidades detectadas en el servidor web de la
empresa Publynext S.A. posterior al uso de la herramienta OWASP
ZAP.
• Proponer un plan de contingencia para la mitigación de riesgos y
amenazas presentes en el servidor web de la empresa Publynext
S.A. fundamentados en la Norma ISO 27001.
• Presentar un informe de los resultados generados en la auditoría
de seguridad en el servidor web de la empresa Publynext S.A.
JUSTIFICACIÓN E IMPORTANCIA DE LA INVESTIGACIÓN
Debido a la confidencialidad de la información que maneja el
servidor web es de vital importancia la realización de una auditoría de
seguridad. Con esta auditoría se dará a conocer las amenazas
informáticas presentes en los sistemas de aplicaciones web para poder
tener los riesgos identificados.
Cabe resaltar, que este proceso de auditoría se realizará dentro de
las instalaciones de la empresa y no en un ambiente de pruebas, lo cual
da realce al trabajo de titulación.
14
Para este trabajo se usará la herramienta de auditoría llamada
OWASP, con la finalidad de que la organización pueda tomar los planes
de prevención y de contingencia para el tratamiento de los riesgos
detectados en la auditoría, y así evitar que piratas informáticos accedan
ilícitamente a los sistemas de aplicación web de la empresa con el
objetivo de atentar a la confidencialidad de la información.
15
CAPÍTULO II
MARCO TEÓRICO
ANTECEDENTES DE ESTUDIO
Según el estudio realizado por (Jiménez, 2017) indica que:
El crecimiento y la evolución de la red de internet ha obtenido un
impacto de vital importancia en la forma de establecer canales de
comunicación por los usuarios para comunicarse con personas a través
de redes sociales, sistemas de video conferencia y demás por medio de
una aplicación web y la manera de realizar operaciones en línea,
generando una gran cantidad de información confidencial. La
16
incorporación de un sin número de sitios de comercio electrónico,
servicios web, bancos y redes sociales han ganado popularidad en el
mercado tecnológico donde podemos ver millones de usuarios
conectados a estos sitios web de servicios con el objetivo de efectuar
gestiones y/o procesos en línea, todo esto conlleva a que la información
pueda ser robada y/o alterada sino se utilizan las medidas de seguridad
necesarias para su manejo adecuado. (Jiménez, 2017)
Las computadoras conectadas a la red de internet son susceptibles
a intrusiones maliciosas ejecutadas por piratas informáticos que posee la
capacidad de poner en riesgos los sistemas de información con la
finalidad de tener el acceso ilícito a los datos de mayor validez de
organizaciones de un alto nivel corporativo, o causar daños a una gran
parte de los activos lógicos. Esta situación es fundamental para saber si
estos sistemas y redes de datos están protegidos contra cualquier tipo de
ataque cibernético. (Jiménez, 2017)
Generalmente las vulnerabilidades expuestas en servidores
web son producidas por las malas prácticas de los desarrolladores de
infraestructura de aplicaciones web. Por lo tanto, es de gran importancia
17
comprender que los sistemas de información web no solo deben
diseñarse y desarrollarse para cumplir los objetivos específicos
planteados por las organizaciones para los que se crean, sino que
también deben salvaguardar los datos e información generados en ellos.
Los ataques en las aplicaciones web son ahora el patrón más
frecuente en las infracciones confirmadas, según un informe
publicado por la compañía de investigaciones Verizon en el
año 2016, detalla que algunas de las organizaciones desean
implementar un programa de seguridad enfocado en proteger
las aplicaciones web con el objetivo de establecer políticas
basadas en la disminución de las 10 principales
vulnerabilidades de OWASP, estos fallos de seguridad son
ampliamente aceptadas como las más probables de ser
explotados, y remediarlas disminuirá en gran medida su riesgo
de incumplimiento. (VERACODE, 2017)
18
Figura No. 1 Políticas de seguridad establecidas por OWASP
Fuente: https://www.veracode.com/directory/owasp-top-10
Autor: Veracode
En la figura N°1 se muestra a través de porcentajes como las
aplicaciones al pasar por un escaneo continúan fallando en el Top 10 de
las políticas de OWASP.
19
La investigación realizada por (Security, 2013) manifiesta que:
El escenario de amenazas para la seguridad en aplicaciones web
se ha desarrollado de un modo inquebrantable donde los elementos
críticos de dicho progreso son los avances tecnológicos ejecutados por
los usuarios maliciosos, la liberación de nuevas tecnologías con nuevas
vulnerabilidades y seguridades agregadas, así como la extensión de
sistemas de información web cada vez más complicados. OWASP indica
que los sitios web con más debilidades presentes son los programados en
Joomla y WordPress donde con el uso de herramientas como WPSCAN y
JOOMSCAN se escanean todos las falencias de seguridad en la cual
muestran que tipo de ataque se puede establecer. (Security, 2013)
FUNDAMENTACIÓN TEÓRICA
Auditoria Informática
El estudio realizado por (PINILLA, 2012) manifiesta lo siguiente:
20
Según la auditoria en sistema de la información es un examen
realizado con carácter crítico objetivo y sistemático selectivo, con la
finalidad de evaluar la eficiencia y eficacia de los usos que se
pueden dar en los medios informáticos, con la finalidad de ver si
están brindando el soporte adecuado usado para el negocio y
metas.
La auditoría informática está enfocada en llevar a cabo la
valoración de reglas, inspecciones, metodologías e instrucciones que se
han implantado en una compañía para obtener confidencialidad,
congruencia, seguridad y privacidad de la información. La auditoría de
sistemas es un área concentrada en la auditoría que se origina y emplea
concepciones de auditoría en la rama de sistemas de información.
El objetivo final de un auditor de sistemas es proporcionar
recomendaciones al área de gerencia con el fin de optimizar o alcanzar
una apropiada inspección interna en ambientes de tecnología informática
con el propósito de obtener mayor eficacia estratégica y administrativa.
21
Objetivos De La Auditoría Informática
(PINILLA, 2012) Es importante para un correcto desempeño en los
sistemas de información porque otorga los controles necesarios
para que los sistemas sean confiables y tengan un nivel alto de
seguridad, la evaluación implica a toda informática, tanto software
como hardware.
Alcance de la Auditoría Informática
Según (PINILLA, 2012) Los alcances en la auditoria informática se
definen con la necesidad del entorno a desarrollarse y viendo los
limites, donde se complementa con los objetivos de la misma.
Los alcances figuran al final de los informes, donde se determinan
perfectamente los puntos que se trataron y los que no lograron
desarrollar, el uso de materiales.
22
Seguridad en las aplicaciones web
Con el proceso de pruebas que se realizan en el sistema web lo
que se intenta es investigar en el algún tipo de falencia por los servicios y
aplicativos, para no poner en riesgo la entidad de la empresa.
(MOSQUERA, 2015)
Test de Penetración
Es una prueba para sistemas informáticos, aplicaciones web o
redes que permite descubrir las vulnerabilidades de la entidad que se esté
haciendo la prueba, el test es usado para revelar las vulnerabilidades así
poder evitar cualquier ataque o intento malicioso de parte de usuarios
externos o internos. (OWASP, 2017)
Vulnerabilidad de las aplicaciones web
“Las vulnerabilidades se puntualizan como cualquier debilidad
que pueda complicar la seguridad del sistema informático de
la empresa”. (MOSQUERA, 2015)
23
En el siguiente cuadro se plasman las principales vulnerabilidades
en aplicaciones web:
Cuadro No. 2 Principales vulnerabilidades en aplicaciones web
Vulnerabilidades Descripción
Cross-Site Scripting (XSS)
Ésta es una vulnerabilidad o,
mejor dicho, un conjunto de
vulnerabilidades que permiten,
utilizando los parámetros de
entrada de la aplicación, modificar
y añadir código a la misma. Son
vulnerabilidades que se
encuentran en el servidor, pero
que están destinadas a atacar al
cliente.
Cross site Request/Reference
Forgery(CSRF)
Esta vulnerabilidad es una
evolución de los XSS. En este
caso, se va a explotar la confianza
en el servidor sobre el cliente. Es
decir, nos haremos pasar por un
24
cliente legítimo, utilizando datos
parciales del mismo. Esta
vulnerabilidad está presente en
formularios. Cuando estos se
envían al servidor, es necesario
asegurarse que la petición es
legítima y debemos asegurarnos
que el cliente ha realizado la
petición realizando los pasos
previos necesarios.
SQL INJECTION
Si los ataques XXS son peligrosos,
ya que pueden provocar un robo
de sesión, los SQL son aún más
porque permiten acceder y
manipular la BBDD. La idea es
modificar las consultas que hace la
aplicación a la base de datos,
aprovechando las entradas de
usuario a la aplicación.
25
Fuente: https://hacking-etico.com/2017/04/04/las-principales-
vulnerabilidades-web/
Autores: Erika Hernández-Gerson Pincay
Los sistemas de información web deben obtener los resguardos
idóneos ante envestidas informáticas que se muestran diariamente,
tratando de eludir la seguridad de los sistemas, el propósito primordial es
conservar la privacidad, integridad y reserva de los datos recopilados.
Vulnerabilidad en el almacenamiento de información
(MOSQUERA, 2015) “El activo más significativo para una
compañía son los datos que almacenan en sus sistemas, y
deben continuar con una estrategia de copias de seguridad y
consumar el calendario determinado para efectuar las copias
de seguridad”.
La información es la parte substancial y principal para una
compañía debido a que abarca todos los métodos y programaciones de
26
las actividades ejecutantes que consienten el progreso eficaz de la
compañía.
Vulnerabilidad en los protocolos de comunicación http y https
(MOSQUERA, 2015) “Una vulnerabilidad generalmente
consiente que el atacante pueda adulterar a la aplicación, por
ejemplo, evadiendo las inspecciones de acceso o ejecutando
instrucciones en el sistema donde alberga la aplicación”.
El propósito del intruso o usuario malicioso una vez que ha eludido
la seguridad de los protocolos mediante técnicas de cifrados incluso
llegando a la base de datos, el cual contiene información de los métodos
de una estructura, el usuario malicioso ejecutará procesos de ataques
para examinar la debilidad de los procesos de cifrado de la seguridad de
la base de datos y poder ingresar a través de códigos-secuencias de
instrucciones de Inyección SQL, logrando adquirir la certificación del
acceso a los registros primordiales de la información recopilada.
(MOSQUERA, 2015)
27
Con el fin de evitar las amenazas de los potenciales ataques en los
sistemas de información web, se requiere examinar y reconocer las
estrategias, limitaciones y distribución de los procesos, comprobando que
las seguridades sean las adecuadas. (MOSQUERA, 2015)
OWASP
OWASP (Proyecto de seguridad de aplicaciones web abiertas) Es
un proyecto de seguridad en aplicaciones web open source que se
encarga de identificar y lidiar con las fragilidades presentadas en un
servidor web impidiendo que los usuarios maliciosos accedan a la
información privada recopilada en los sistemas de información web.
OWASP Foundation es una organización sin interés de ganancia que
apoya y maneja proyectos e infraestructura de OWASP. (Jiménez, 2017)
Los informes de estos proyectos contienen un manual de buenas
prácticas de OWASP considerablemente argumentada y autoevaluada
para que las instituciones se fundamenten en dicho manual con el
propósito de resguardar los datos que se acoplan en los sistemas web. El
procedimiento de prueba para aplicaciones web se especifica en dos
28
fases que son las siguientes: pasivo y activo empleando la auditoría de
caja negra. (OWASP, 2017)
Caja Negra
El termino caja negra es usado en la auditoria para identificar el
tipo de test que se empleará.
Caja Negra hace referencia al análisis del sistema de información
web que se ejecutará remotamente sin conocer como está diseñado el
sitio web para hallar puertas vulnerables a un ataque. (OWASP, 2017)
Se comienza con la perspectiva de un usuario que desconoce de la
infraestructura del sistema web y se procede al ataque solo con la
información pública que brinda el sitio web como el nombre del domino.
La ventaja de esto, es que el auditor tiene la exclusividad de
encontrar lo mismo que podría encontrar el “hacker” porque el ataque es
hecho desde su mismo ambiente, es decir remotamente.
29
Documentación OWASP
OWASP es un proyecto de código abierto en el cual enfatiza a la
comunidad a participar de manera voluntaria en los proyectos de testeo
en aplicaciones web, pruebas de intrusión o pruebas en el desarrollo de
software web seguro, con el afán de trabajar localmente para así abarcar
la mayor parte declarando proyectos globales.
OWASP es muy conocida por su documentación, a continuación
las más emblemáticas:
Guía de Desarrollo Web Seguro
Ø Es uno de los primeros documentos que publicó, año 2005, sigue
vigente.
Ø Habla de las buenas prácticas en el desarrollo de aplicaciones web.
Ø Explica la parte de desarrollo en la infraestructura y puntos de
quiebre más frecuentes en la aplicación.
30
Guía de Pruebas
Ø Se extiende a una explicación de más de 80 puntos de control en
11 categorías distintas, a tener en cuenta, tanto en el desarrollo
como en la revisión de seguridad.
Ø Está enfocado más en las pruebas de seguridad, el mismo usuario
aplique su test en su aplicativo web.
Ø Cubre todas las fases de desarrollo de aplicación web brindando
recomendaciones a los desarrolladores.
Tops 10 de OWASP
Ø Los tops son pequeños documentos donde se enumeran los
problemas más frecuentes en aplicaciones web.
Ø Es un proyecto muy reconocido en OWASP porque son bastante
concisos, directos y resumidos en la explicación de los problemas o
vulnerabilidades.
31
Riesgos de seguridad en OWASP
Los usuarios maliciosos pueden usar diferentes rutas del sitio web
para dañar la integridad del negocio u organización. Cada uno de estos
caminos que llegue a tomar el atacante puede no tener ninguna
consecuencia o podría ser potencialmente riesgoso tanto como para
dejarlo fuera del negocio.
La figura N°2 muestra los caminos en que un atacante informático
puede acceder a la aplicación y causar perjuicios a la empresa. El
atacante puede valerse de varias rutas para llegar a una debilidad,
invadiendo los controles de seguridad para acceder a las funciones o
recursos de la organización, de esa manera causa un impacto técnico y
por consiguiente un impacto al negocio.
32
Figura No. 2 Ataque Genérico
Elaborado por: (OWASP-CISO, 2015)
Fuente: https://www.owasp.org/images/1/19/Owasp-ciso-guide_es.pdf
Factores de Riesgo por OWASP
OWASP tiene un top 10 de los riesgos más propensos a ser
empleados contra las organizaciones. Para cada riesgo tiene información
relevante y genérica sobre la probabilidad y el impacto que puede llegar a
tener.
El siguiente cuadro muestra una sinopsis de los Riesgos más
importantes de Seguridad de Aplicación 2017 y los elementos de riesgo
33
que determinan a cada uno. Dichos elementos se establecieron en
relación a los inventarios disponibles y a la práctica del equipo Top 10 de
OWASP. Con el fin de entender estos riesgos para un aplicativo u
organización en particular, debe tomar en cuenta sus propios agentes de
amenaza y las consecuencias que podrían ser hacia la compañía;
entendiéndose por agente de amenaza a todo factor, suceso, y/o persona
que puede provocar algún daño. Inclusive las vulnerabilidades del
software son importantes, logran mostrar un riesgo grave si no se cuenta
con agentes de amenaza definidos.
Cuadro No. 3 Diez factores de riesgo
Elaborado por: (OWASP, 2017)
Fuente: https://www.owasp.org/index.php/Top_10_2017-Top_10
34
1. A1: Injection – Inyección
Las inyecciones pueden ser de tipo SQL, SO, LDAP y otras que
ocurren cuando los datos ingresados a la aplicación web no son
validados adecuadamente y son interpretados como parte de un
comando consulta. Un atacante hostil puede realizar una
inyección para ejecutar comandos peligrosos o acceder a datos
sin la autorización requerida. (OWASP, 2017)
2. A2: Broken Authentication – Inadecuada Autenticación
Las funciones de la aplicación que regulan la autenticación y la
gestión de sesiones son muy frecuentemente implementadas de
forma incorrecta. Un atacante puede comprometer las
contraseñas, llave y token, y explotar otros fallos para asumir la
identidad de otro usuario de la aplicación de forma permanente
o temporal. (OWASP, 2017)
3. A3: Sensitive Data Exposure – Exposición de Datos
Sensibles
35
Muchas aplicaciones web o APIs no protegen apropiadamente
la información sensible y privada de sus usuarios como
información financiera, de estado de salud y datos de
identificación personal. Un atacante puede robar o modificar los
datos que se encuentren débilmente protegidos para llevar a
cabo operaciones fraudulentas con tarjetas de crédito, robo de
identidad y otros crímenes. (OWASP, 2017)
4. A4: XML External Entity - XML External Entity
Muchos procesadores de XML antiguos y débilmente
configurados evalúan y procesan entidades externas dentro de
documentos XML. Estas entidades externas añadidas pueden
ser usadas para mostrar archivos internos, archivos
compartidos en la red, escaneo de puertos, ejecución de código
remoto, denegación de servicios y billion laughs attack.
(OWASP, 2017)
36
5. A5: Broken Accces Control – Inadecuado Control de
Acceso
Muchas veces las restricciones de lo que lo usuarios están
permitidos a hacer no son apropiadamente aplicadas. Los
atacantes pueden explotar estas debilidades para acceder a
funcionalidades o datos de forma no autorizada como acceder a
cuentas de usuarios, ver archivos sensibles, modificar permisos
de 0061cceso, y mucho más. (OWASP, 2017)
6. A6: Security misconfiguration - configuración de seguridad
incorrecta
La inadecuada configuración de seguridad es un problema
increíblemente común que ocurre cuando se realizan las
configuraciones mínimas funcionales o por defecto, S3 buckets
abiertos, cabeceras HTTP mal configuradas, mensajes de error
con información sensible y sistemas, frameworks, dependencias
y componentes no actualizados de forma oportuna. (OWASP,
2017)
37
7. A7: Cross-Site Scripting – Cross-Site Scripting
La vulnerabilidad a XSS ocurre siempre que una aplicación
incluye datos no validados al actualizar o re direccionar la
página web para ser procesados como parte de código
JavaScript. Un atacante podría ejecutar scripts en el navegador
de la víctima para robar sesiones, modificar el contenido en las
páginas web, y generar redirecciones a sitios maliciosos.
(OWASP, 2017)
8. A8: Insecure Deserialization - Deserialización Insegura
La des-serialización insegura ocurre cuando una aplicación
vulnerable recibe objetos maliciosos serializados. Esto puede
conducir a ejecución de código remoto, a instar a los usuarios a
realizar acciones peligrosas, inyecciones y elevación de
privilegios. (OWASP, 2017)
9. A9: Using Components With known Vulnerabilites - Uso de
Componentes con Vulnerabilidades Conocidas
38
Muchos componentes como librerías, frameworks, y otros
módulos de software se ejecutan con los mismos privilegios que
la aplicación. Un atacante puede explotar un componente
vulnerable para ocasionar perdida de datos y tomar el control
del servidor. (OWASP, 2017)
10. A10: Insufficient Logging and Monitoring – Registro y
Monitoreo Insuficiente
El registro y monitoreo insuficiente ocasiona que no exista
respuesta ante incidentes y permite a los atacantes penetrar los
sistemas, mantener un control persistente, ganar acceso a otros
sistemas y modificar, extraer y destruir datos. Muchos estudios
de este tipo de brechas muestras que el tiempo de detección de
estos ataques ronda los 200 días y son detectados por
procesos externos al de monitoreo. (OWASP, 2017)
Metodología de Valoración de Riesgo OWASP
OWASP propone una metodología para evaluar la severidad que
podrían tener las vulnerabilidades detectadas y la posible toma de
decisiones para lograr mitigar aquellas vulnerabilidades.
39
OWASP se basa en un modelo estándar de valoración de riesgo:
Riesgo = Probabilidad de Ocurrencia * Impacto
Según el estudio realizado por (Navarro Edison, 2016):
Esta metodología se basa en 6 pasos los cuales se detallan a
continuación:
1. Identificación de un Riesgo
Paso donde se identifican los agentes de amenazas, las
debilidades que pueden ser explotadas, mediante la
recopilación de información, y el impacto que causa en el
negocio.
2. Factores de Riesgo Estimación
Paso donde se estima la probabilidad de que la
vulnerabilidad sea descubierta y explotada por un atacante,
se puede medir en términos cualitativos y para una medida
más exacta el cuantitativo.
40
3.- Estimación del Impacto
Paso donde se logra reflejar con mayor exactitud la
magnitud del impacto que tendría la materialización de la
vulnerabilidad tanto en el aspecto técnico como para el
negocio y se puede medir de 0-9. Donde el rango de 0 a 3
corresponde a un nivel bajo; de 3 – 6 corresponde a un nivel
medio; y de 6 – 9 corresponde un nivel alto.
4.- Determinación de la severidad del impacto
Paso donde se calcula la magnitud del riesgo, se usan dos
valores: la estimación de la probabilidad y la estimación del
impacto.
El siguiente cuadro hace referencia a los rangos de 0-9 para
determinar la magnitud del impacto.
Cuadro No. 4 Determinación de severidad del impacto
Probabilidad de ocurrencia Niveles de impacto
0 a < 3 BAJO
3 a < 6 MEDIO
41
6 a < 9 BAJO
Elaborado por: (OWASP, 2017)
Fuente: https://www.owasp.org/index.php/Top_10_2017-Top_10
5.- Resultados
Paso donde se detalla que vulnerabilidades tendrían más
impactos y que deberían ser corregidas inmediatamente.
6- Recomendaciones
Paso donde se sugiere que medidas deberían tomarse para
mitigar y poder dar una solución inmediata a la
vulnerabilidad identificada.
HERRAMIENTA DE OWASP
OWASP Zed Attack proxy (ZAP)
(OWASP, 2017) La página oficial de OWASP puntualizó
OWASP Zed Attack proxy (ZAP) del siguiente modo:
42
ZAP es una de las herramientas de resguardo de seguridad sin
costo más popular en el orbe y es sustentado activamente por centenas
de voluntarios en todo el mundo. Logra ayudarle a encontrar
automáticamente amenazas de seguridad en sus aplicativos web mientras
desarrolla y prueba sus aplicaciones. Asimismo es una gran herramienta
para testers con experiencia para emplear pruebas de seguridad
manuales. (Proxy, 2017)
Está diseñado para ser empleado por personas con un amplio
grado de experiencia en seguridad por lo cual es apto para los
programadores y testers que apenas inician en el mundo de las pruebas
funcionales. ZAP provee escáneres automáticos, así como un conjunto de
componentes que facilitan a encontrar vulnerabilidades de seguridad de
forma manual.
Según (Proxy, 2017) algunas de las especialidades de ZAP se
puntualizan seguidamente:
• Escáner automatizado
• Escáner neutral
43
• Escáner de fuerza brusca
• Fuzzer
• Escaneo de puertos
• Autenticados SSL eficientes
• Proxy de expropiación
• De fácil instalación(sólo necesita java 1.6)
• Destreza de uso una preferencia
• Páginas de ayuda completas
• Totalmente difundido
• Bajo progreso activo
• Código abierta
• Open Source
• Plataforma liberada
Firewall
El firewall es un componente que facilita el monitoreo del tráfico de
red entre las conexiones entrantes y salientes, con el fin de limitar
accesos no esperados que logren infringir a dispositivos de la red. Existen
firewall de red o de host, los de red son manejados para proteger los
44
equipos y sistemas informáticos centralmente de una red y los de host
protegen a los dispositivos de computación o servidores brevemente a
partir de un centro de conexiones.
La figura N°3 muestra una representación gráfica de cómo actúa un
firewall dentro de una red de computadoras.
Figura No. 3 Representación de firewall en una red de computadoras
Fuente: (Azuay, s.f.)
45
KALI LINUX
Kali es una distribución Linux delineada para la seguridad
informática. Mayormente las versiones de Linux son de código abierto y
sin ningún costo, así como la mayor parte de sus herramientas. Este
sistema operativo abarca una gran colección de instrumentos
consagrados a la auditoría informática entre las que se hallan las más
notorias son: nmap, metasploit, waf o john the ripper. Las aplicaciones se
encuentran separadas por secciones, las mismas que obedecen a la rama
de seguridad por las cuales están comprendidas. (Benito, 2014)
Según (Benito, 2014) el sistema Kali Linux posee las siguientes
características:
ü Robusto: tiene mayores números de herramientas para pentesting,
de las cuales se fueron optimizando.
ü Gratuito: los ensayos no son alterados por los autores en el tiempo,
así mismo tiene un sin números de código abiertos e intercesoras
que a pesar de no ser gratis por medio de algunas autorizaciones y
acuerdos con los proveedores la comercialización.
ü Open Source: tiene un repositorio donde podemos hallar el código
fuente del sistema Kali para mejorar o reconstruir.
46
ü FHS: crea una distribución de los registros y la creación de los
mismos.
ü Tiene la finalidad de soportar un sin números de dispositivos
inalámbricos, donde consiste en circular apropiadamente sobre
gran variedad de hardware, las concurrencias usb las soportas y
dispositivos móviles.
ü Instaurado bajo un ambiente seguro: las seguridades en los
paquetes son efectuadas en Kali Linux donde se generan un sin
números de formas de seguridad, con la composición de las
plataformas.
ü Soporta múltiples idiomas, a pesar que la mayoría de sus
elementos fueron encriptados en inglés.
ü Personalizable: Es factible descargar una adaptación
completamente caracterizada de Kali en que solo abarque envíos
de servicio al usuario.
47
FUNDAMENTACIÓN SOCIAL
Con el progreso de los sistemas informáticos en diversas áreas es
necesario la seguridad, debido a que la información que viaja en la red
puede verse expuesta a ataques cibernéticos, uno de los recursos más
valiosos para las compañías es la información, es por ello que para lograr
validar y examinar la seguridad de un servidor web es necesario realizar
una auditoria en los servidores web de la compañía con el fin de detectar
posibles amenazas y mitigarlas a tiempo.
Los sistemas de información web tienen la necesidad de
salvaguardar la información de envestidas informáticas. Al tratar de eludir
la seguridad de los sistemas y obtener el registro de los procedimientos
pueden acceder a la información privada a través de las brechas de
seguridad. Auditar los servidores web mediante el uso de la herramienta
OWASP facilitará la identificación de vulnerabilidades, realizando análisis
al sistema de información que consiente examinar si cumplen las
limitaciones de integridad y seguridad de los datos.
48
Se propone minimizar las inseguridades brindando soluciones a
través de instrumentos y procedimientos especializados que permitan
realizar la auditoria en los servidores web de la empresa Publynext S.A.
detectando vulnerabilidades que existen y demostrando las soluciones en
el sistema de información web.
FUNDAMENTACIÓN LEGAL
El presente trabajo de tesis se administra en bases legales
legislativas que señala la Asamblea Nacional del Ecuador compendiada
en los siguientes artículos:
Art. 229.-
Ø Revelación ilegal de base de datos.- La persona que, en
provecho propio o de un tercero, revele información registrada,
contenida en ficheros, archivos, bases de datos o medios
semejantes, a través o dirigidas a un sistema electrónico,
informático, telemático o de telecomunicaciones; materializando
voluntaria e intencionalmente la violación del secreto, la intimidad y
la privacidad de las personas, será sancionada con pena privativa
49
de libertad de uno a tres años. Si esta conducta se comete por una
o un servidor público, empleadas o empleados bancarios internos
o de instituciones de la economía popular y solidaria que realicen
intermediación financiera o contratistas, será sancionada con pena
privativa de libertad de tres a cinco años.
Ø Análisis del artículo 229.- El presente artículo indica la sanción
correspondiente si una persona revela información de carácter
confidencial de los usuarios contenida en la base de datos de los
sistemas informáticos.
Art 230.-
Ø Interceptación ilegal de datos.- La persona que sin orden judicial
previa, en provecho propio o de un tercero, intercepte, escuche,
desvíe, grave u observe, en cualquier forma un dato informático en
su origen, destino o en el interior de un sistema informático, una
señal o una transmisión de datos o señales con la finalidad de
obtener información registrada o disponible.
Ø Análisis del artículo 230.- Este artículo expresa las formas de
sacar provecho de la información de los sistemas informáticos sin
50
respaldo de alguna orden judicial, la misma contempla sanción con
prisión de tres a cinco años.
Art 232.-
Ø Ataque a la integridad de sistemas informáticos.- La persona
que destruya, dañe, borre, deteriore, altere, suspenda, trabe, cause
mal funcionamiento, comportamiento no deseado o suprima datos
informáticos, mensajes de correo electrónico, de sistemas de
tratamiento de información, telemático o de telecomunicaciones a
todo o parte de sus componentes lógicos que lo rigen, será
sancionada con pena privativa de libertad de tres a cinco años.
Con igual pena será sancionada la persona que:
1.- Diseñe, desarrolle, programe, adquiera, envíe,
introduzca, ejecute, venda o distribuya de cualquier manera,
dispositivos o programas informáticos maliciosos o
programas destinados a causar los efectos señalados en el
primer inciso de este artículo.
2.- Destruya o altere sin la autorización de su titular, la
infraestructura tecnológica necesaria para la transmisión,
recepción o procesamiento de información 39 en general. Si
51
la infracción se comete sobre bienes informáticos destinados
a la prestación de un servicio público o vinculado con la
seguridad ciudadana, la pena será de cinco a siete años de
privación de libertad.
Ø Análisis del artículo 232.- Este artículo manifiesta los tipos de
incursiones que puede ocasionar una personar a un sistema
informático, las mismas que están penadas por el código orgánico
integral penal.
Art 233.-
Ø Delitos contra la información pública reservada legalmente.- La
persona que destruya o inutilice información clasificada de
conformidad con la ley, será sancionada con pena privativa de
libertad de cinco a siete años. La o el servidor público que,
utilizando cualquier medio electrónico o informático, obtenga este
tipo de información, será sancionado con pena privativa de libertad
de tres a cinco años. Cuando se trate de información reservada,
cuya revelación pueda comprometer gravemente la seguridad del
Estado, la o el servidor público encargado de la custodia o
52
utilización legítima de la información que sin la autorización
correspondiente revele dicha información, será sancionado con
pena privativa de libertad de siete a diez años y la inhabilitación
para ejercer un cargo o función pública por seis meses, siempre
que no se configure otra infracción de mayor gravedad.
Ø Análisis del artículo 233.- La utilización incorrecta de información
clasificada considerada por el Estado como tal, es sancionada con
prisión a cualquier ciudadano que viole la seguridad de los
sistemas informáticos.
Art 234.-
Ø Acceso no consentido a un sistema informático, telemático o
de telecomunicaciones.- La persona que sin autorización acceda
en todo o en parte a un sistema informático o sistema telemático o
de telecomunicaciones o se mantenga dentro del mismo en contra
de la voluntad de quien tenga el legítimo derecho, para explotar
ilegítimamente el acceso logrado, modificar un portal web, desviar
o re direccionar de tráfico de datos o voz u ofrecer servicios que
estos sistemas proveen a terceros, sin pagarlos a los proveedores
53
de servicios legítimos, será sancionada con la pena privativa de la
libertad de tres a cinco años.
Ø Análisis del artículo 234.- Este artículo trata de la incursión a los
sistemas de información de personas no autorizadas, la misma
que está catalogada como ilegal sancionada con privación de
libertad de tres a cinco años.
Sección Octava
Ciencia, tecnología, innovación y saberes ancestrales
Art. 385.- El sistema nacional de ciencia, tecnología, Innovación y
saberes ancestrales, en el marco del respeto al ambiente, la naturaleza, la
vida, las culturas y la soberanía, tendrá como finalidad:
a. Generar, adaptar y difundir conocimientos científicos y
tecnológicos.
b. Desarrollar tecnologías e innovaciones que impulsen la
producción nacional, eleven la eficiencia y productividad,
mejoren la calidad de vida y contribuyan a la realización del
buen vivir.
54
Art. 386.- El sistema comprenderá programas, políticas, recursos,
acciones, e incorporará a instituciones del Estado, universidades y
escuelas politécnicas, institutos de investigación públicos y privados,
empresas públicas y privadas, organismos no gubernamentales y
personas naturales o jurídicas, en tanto realizan actividades de
investigación, desarrollo tecnológico, innovación.
El Estado, a través del organismo competente, coordinará el sistema,
establecerá los objetivos y políticas, de conformidad con el Plan Nacional
de Desarrollo, con la participación de los actores que lo conforman.
Art. 387.- Será responsabilidad del Estado:
a. Facilitar e impulsar la incorporación a la sociedad del conocimiento
para alcanzar los objetivos del régimen de desarrollo.
b. Promover la generación y producción de conocimiento, fomentar la
investigación científica y tecnológica.
c. Asegurar la difusión y el acceso a los conocimientos científicos y
tecnológicos, el usufructo de sus descubrimientos y hallazgos en el
marco de lo establecido en la Constitución y la Ley.
55
d. Garantizar la libertad de creación e investigación en el marco del
respeto a la ética, la naturaleza, el ambiente.
e. Reconocer la condición de investigador de acuerdo con la Ley.
Art. 388.- El Estado destinará los recursos necesarios para la
investigación científica, el desarrollo tecnológico, la innovación, la
formación científica, y la difusión del conocimiento. Un porcentaje de
estos recursos se destinará a financiar proyectos mediante fondos
concursables. Las organizaciones que reciban fondos públicos estarán
sujetas a la rendición de cuentas y al control estatal respectivo.
La fundamentación legal para los estudios según la nueva ley de
educación superior se refleja en los artículos:
Art. 8.- Serán Fines de la Educación Superior. - La educación superior
tendrá los siguientes fines:
a. Aportar al desarrollo del pensamiento universal, al despliegue de la
producción científica y a la promoción de las transferencias e
innovaciones tecnológicas;
b. Fortalecer en las y los estudiantes un espíritu reflexivo orientado al
logro de la autonomía personal, en un marco de libertad de
pensamiento y de pluralismo ideológico;
56
c. Contribuir al conocimiento.
d. Formar académicos y profesionales responsables, con conciencia
ética y solidaria, capaces de contribuir al desarrollo de las
instituciones de la República, a la vigencia del orden democrático, y
a estimular la participación social;
e. Aportar con el cumplimiento de los objetivos del régimen de
desarrollo previsto en la Constitución y en el Plan Nacional de
Desarrollo;
f. Fomentar y ejecutar programas de investigación de carácter
científico, tecnológico y pedagógico que coadyuven al
mejoramiento y protección del ambiente y promuevan el desarrollo
sustentable nacional;
g. Constituir espacios para el fortalecimiento del Estado
Constitucional, soberano, independiente, unitario, intercultural,
plurinacional y laico;
h. Contribuir en el desarrollo local y nacional de manera permanente,
a través del trabajo comunitario o extensión universitaria.
Art. 71.- Principio de igualdad de oportunidades. - El principio de
igualdad de oportunidades consiste en garantizar a todos los actores del
Sistema de Educación Superior las mismas posibilidades en el acceso,
57
permanencia, movilidad y egreso del sistema, sin discriminación de
género, credo, orientación sexual, etnia, cultura, preferencia política,
condición socioeconómica o discapacidad.
Las instituciones que conforman el Sistema de Educación Superior
propenderán por los medios a su alcance que, se cumpla en favor de los
migrantes el principio de igualdad de oportunidades. Se promoverá dentro
de las instituciones del Sistema de Educación Superior el acceso para
personas con discapacidad bajo las condiciones de calidad, pertinencia y
regulaciones contempladas en la presente Ley y su Reglamento. El
Consejo de Educación Superior, velará por el cumplimiento de esta
disposición.
Art. 117.- Tipología de instituciones de Educación Superior. – Las
instituciones de Educación Superior de carácter universitario o politécnico
se clasificarán de acuerdo con el ámbito de las actividades académicas
que realicen. Para establecer esta clasificación se tomará en cuenta la
distinción entre instituciones de docencia con investigación, instituciones
orientadas a la docencia e instituciones dedicadas a la educación superior
continua.
58
En función de la tipología se establecerán qué tipos de carreras o
programas podrán ofertar cada una de estas instituciones, sin perjuicio de
que únicamente las universidades de docencia con investigación podrán
ofertar grados académicos de PHD o su equivalente.
Esta tipología será tomada en cuenta en los procesos de evaluación,
acreditación y categorización.
Art. 118.- Niveles de formación de la educación superior. - Los niveles
de formación que imparten las instituciones del Sistema de Educación
Superior son:
Nivel técnico o tecnológico superior, orientado al desarrollo de las
habilidades y destrezas que permitan al estudiante potenciar el saber
hacer. Corresponden a éste los títulos profesionales de técnico o
tecnólogo superior, que otorguen los institutos superiores técnicos,
tecnológicos, pedagógicos, de artes y los conservatorios superiores.
59
Las instituciones de educación superior no podrán ofertar títulos
intermedios que sean de carácter acumulativo.
IDEA A DEFENDER
El brindar una auditoria a nivel del servidor web de la empresa
PUBLINEXT S.A. utilizando la metodología OWASP, con el fin de detectar
vulnerabilidades o amenazas a tiempo, registrar en informes las
anomalías detectadas para su pronto fortalecimiento en las brechas de
seguridad manifestadas y de esta manera salvaguardar la información
confidencial almacenada en la base de datos.
DEFINICIONES CONCEPTUALES
Cuadro No. 5 Definiciones conceptuales
PALABRA DEFINICIÓN
HTTP Abreviatura de la forma
inglesa Hypertext Transfer
60
Protocol, ‘protocolo de
transferencia de
hipertextos’, que se utiliza
en algunas direcciones de
internet.
Vulnerabilidades
Son aquellas brechas de
seguridad o debilidades
que posee un sistema
informático o equipo la
cual puede ser utilizada
con el fin de causar
perjuicios a la compañía.
Cifrar
Es el método por donde se
interpreta un mensaje en
clave por medio de
algoritmos.
Auditoria
Es un proceso que se lleva
a cabo por personal
experimentado,
61
fundamentalmente
preparados para el efecto,
y consiste en recolectar,
agrupar y examinar
evidencias para determinar
si un sistema informático
posee la seguridad
necesaria para proteger el
activo empresarial y
mantener la integridad de
la información.
Sistema de Información.
Es un grupo de
componentes dirigidos al
tratamiento y gestión de la
información, introducidos y
listos para su empleo
posterior, creados para
cubrir un objetivo
específico.
62
Servicios Web
Es una tecnología que
emplea un grupo de
protocolos y normas que
sirven para intercambiar
información entre
aplicaciones.
OWASP
Es un proyecto open
source dedicado a
comprobar y combatir las
causas que hacen que el
software no sea seguro.
Fuente: Investigación Propia
Autores: Erika Hernández-Gerson Pincay
63
CAPÍTULO III
METODOLOGÍA DE LA INVESTIGACIÓN
DISEÑO DE LA INVESTIGACIÓN
MODALIDAD DE LA INVESTIGACIÓN
La singularidad del presente proyecto de tesis se puntualiza como
investigación aplicada, tal y como lo manifiesta (Vargas Cordero, 2015)
El tipo de investigación que se ha desarrollado tiene el nombre
de “investigación empírica”, que se enfatiza en la búsqueda de
64
la aplicación de todos los conocimientos obtenidos, luego de
realizar la implementación y sistematización de la práctica. La
aplicación de los conocimientos y resultados de la
investigación da como resultado una forma más organizada y
sistemática de estar al tanto de la realidad. (Vargas Cordero,
2015)
Asimismo se conoce como investigación práctica o empírica la
misma se acopla al proyecto según las necesidades presentadas en el
camino.
Tipo de investigación
La investigación aplicada se divide en tres clases: exploratorio,
descriptivo y confirmatoria. Para el presente trabajo de tesis el tipo de
investigación a emplear es de exploratorio debido a que se demanda
realizar auditoria en el servidor web para detectar brechas de seguridad y
posibles amenazas que pueden afectar su seguridad, la misma será
realizada mediante el uso de OWASP por lo que el tipo de investigación
65
exploratoria es la idónea para familiarizarse con el proyecto OWASP y
aplicarlo correctamente.
Según (PANEQUE, 1998) indica que:
Las investigaciones exploratorias solo se sitúan en
campos de estudios pocos conocidos donde los
problemas necesitan ser delimitados y puntuales, esto
es la importancia del objetivo principal de la
investigación de campo exploratoria. Teniendo como
resultados uno o varios problemas que generan una
limitación o varios problemas que pueden ser
explorados para el área y estudio posterior. (PANEQUE,
1998)
Población y muestra
Según (Tamayo, 2011) indica que:
66
Población es el total de un fenómeno de estudio, contiene la
totalidad de unidades de análisis u objetos de población que
constituyen dicho fenómeno y que debe ponderarse para un
determinado estudio completando un conjunto N de entidades
que notifican de una determinada particularidad, y se le señala
como población por constituir la totalidad del fenómeno
agregado a un estudio o investigación.
Para el presente trabajo de tesis la población está compuesta por
el personal del departamento de sistemas de la empresa Publynext S.A.
Cuadro No. 6 Cuadro Distributivo de la Población
POBLACION CANTIDAD
Personal de Sistemas de la
Empresa Publynext S.A.
3
TOTAL 3
Fuente: Datos de investigación.
Autores: Erika Hernández-Gerson Pincay
67
La terminología muestra según (Tamayo, 2011) manifiesta que:
“Muestra a partir de la población cuantificada para una
investigación se determina la muestra, cuando no es
posible medir cada una de las entidades de población;
esta muestra, se considera, es representativa de la
población.”
Cuadro No. 7 Tamaño de la Muestra
MUESTRA CANTIDAD
Personal de Sistemas de la
Empresa Publynext S.A.
3
TOTAL 3
Fuente: Datos de investigación. Autores: Erika Hernández-Gerson Pincay
Debido a que la población es mínima para este caso la muestra es la
misma cantidad de la población de la empresa Publynext S.A.
68
Técnicas e instrumentos de recolección de datos
Técnica: la técnica de investigación para la recopilación de
información que se manejará en el actual proyecto, es la de campo
haciendo uso de las encuestas.
La encuesta según el autor (Fidia, 2012)
“Se puntualiza la encuesta como una habilidad que intenta
conseguir información que proporciona a una cierta cantidad
de personas o personas cercanas que también influyen en una
relación a un tema a tratar especifico”
La encuesta será efectuada al Personal de Sistemas de la
Empresa Publynext S.A. Con el objetivo de conseguir información para su
posterior estudio y tabulación de datos.
69
Recolección de la información
Para la implementación de Auditoria en la empresa Publynext S.A.
se emplearan procedimientos e instrumentos de análisis los cuales
facilitaran la obtención de información requerida para su ejecución.
La recolección de información será llevada a cabo con la técnica de
tipo exploratoria, con el objetivo de identificar las brechas de seguridad
que existen en los servidores web de la Empresa Publynext S.A.
realizando encuestas al personal de sistemas.
Análisis de resultados de las encuestas
Para el procesamiento de información se generaron preguntas tipo
abiertas dirigidas al personal de sistemas de la empresa Publynext S.A.,
una vez realizadas se procederá a efectuar la tabulación y análisis de los
resultados.
70
Pregunta # 1
1. ¿Piensa usted que la información en el sitio web de la empresa
Publynext S.A. es sensible a los hackers o usuarios maliciosos
que podrían afectarlas?
Cuadro No. 8 Resultado Pregunta # 1
OPCIONES FRECUENCIA PORCENTAJE
SI 3 100%
NO 0 0%
TOTAL 3 100%
Fuente: Investigación Propia
Figura No. 4 Fragilidad con los hackers
Fuente: Investigación Propia
Autores: Erika Hernández-Gerson Pincay
71
Análisis.- Todo el personal de sistemas de la empresa Publynext
S.A. que corresponde al 100% de la muestra estudiada, considera que la
información es vulnerable a hackers y usuarios maliciosos.
Pregunta # 2
2. ¿Considera usted que la información que se manipula dentro
de la empresa Publynext S.A. es segura?
Cuadro No. 9 Resultado Pregunta # 2
OPCIONES FRECUENCIA PORCENTAJE
SI 1 33%
NO 2 67%
TOTAL 3 100%
Fuente: Investigación Propia
Autores: Erika Hernández-Gerson Pincay
72
Figura No. 5 La información dentro de la empresa es segura
Fuente: Investigación Propia
Autores: Erika Hernández-Gerson Pincay
Análisis.- Según los resultados mostrados, se puede observar que
el 67% de la muestra de estudio de la empresa Publynext S.A. considera
que el manejo de la información no es segura, mientras que el 33%
restante indica que si lo es.
73
Pregunta # 3
3. ¿Se ha presentado robo de información en el sitio web de la
empresa Publynext S.A.?
Cuadro No. 10 Resultado Pregunta # 3
OPCIONES FRECUENCIA PORCENTAJE
SI 1 33%
NO 2 67%
TOTAL 3 100%
Fuente: Investigación Propia
Autores: Erika Hernández-Gerson Pincay
Figura No. 6 Robo de la información
Fuente: Investigación Propia
Autores: Erika Hernández-Gerson Pincay
74
Análisis.- Los resultados presentan que en un 33% se ha
demostrado rodo de la información dentro del sitio web de la empresa
Publynext S.A., lo que destaca la importancia de realizar una auditoría y
generar informes de amenazas encontradas para dar su respectiva
solución, y salvaguardar la información.
Pregunta # 4
4. ¿Cuál es el nivel de riesgo de amenaza si el servidor no posee
las políticas y seguridades convenientes?
Cuadro No. 11Resultado Pregunta # 4
OPCIONES FRECUENCIA PORCENTAJE
ALTO 2 67%
MEDIO 1 33%
BAJO 0 0%
NULO 0 0%
TOTAL 3 100%
Fuente: Investigación Propia
Autores: Erika Hernández-Gerson Pincay
75
Figura No. 7 Nivel de Amenaza
Fuente: Investigación Propia
Autores: Erika Hernández-Gerson Pincay
Análisis.- Según los resultados mostrados, se puede constatar que
el 33% cree que existe una amenaza media si no se aplican las políticas y
seguridades convenientes al servidor, el 67% considera que existe un alto
riesgo no aplicar la seguridades y políticas correctas al servidor.
76
Pregunta # 5
5. ¿Considera usted necesario realizar un análisis de
vulnerabilidades al sistema de web de la Empresa Publynext
S.A.?
Cuadro No. 12 Resultado Pregunta # 5
OPCIONES FRECUENCIA PORCENTAJE
DE ACUERDO 3 100%
PARCIALMENTE DE
ACUERDO 0 0%
EN DESACUERDO 0 0%
TOTAL 3 100%
Fuente: Investigación Propia
Autores: Erika Hernández-Gerson Pincay
77
Figura No. 8 Análisis de vulnerabilidades
Fuente: Investigación Propia
Autores: Erika Hernández-Gerson Pincay
Análisis.- Según los resultados obtenidos, el 100% del personal de
sistemas considera necesario realizar un análisis de vulnerabilidades al
sistema web de la Empresa la Empresa Publynext S.A. Se teoriza que
debe ejecutar un buen control de seguridad en el sistema de información
web de manera habitual empleando los elementos precisos minimizando
riesgos de amenazas en el servidor web.
78
Pregunta # 6
6. ¿Piensa usted que la realización de una auditoria en la
Seguridad Del Servidor Web De La Empresa Publynext S.A.
mediante el uso de OWASP será factible para la detección de
vulnerabilidades y amenazas dentro de la empresa?
Cuadro No. 13 Resultado Pregunta # 6
OPCIONES FRECUENCIA PORCENTAJE
DE ACUERDO 2 67%
PARCIALMENTE DE
ACUERDO 1 33%
EN DESACUERDO 0 0%
TOTAL 3 100%
Fuente: Investigación Propia
Autores: Erika Hernández-Gerson Pincay
79
Figura No. 9 Detección de vulnerabilidades
Fuente: Investigación Propia
Autores: Erika Hernández-Gerson Pincay
Análisis.- Los resultados indican que el 67% de la muestra
encuestada está de acuerdo con la realización de auditoría de seguridad
en el servidor web de la empresa Publynext S.A. implementando las
recomendaciones y herramientas de OWASP, mientras que el 33%
restante se encuentra parcialmente de acuerdo con la ejecución de la
misma.
80
Pregunta # 7
7. OWASP es una comunidad abierta dedicada a habilitar a las
organizaciones para desarrollar, comprar y mantener
aplicaciones confiables, ¿Conoce usted de esta entidad?
Cuadro No. 14 Resultado Pregunta # 7
OPCIONES FRECUENCIA PORCENTAJE
SI 1 33%
NO 2 67%
TOTAL 3 100%
Fuente: Investigación Propia
Autores: Erika Hernández-Gerson Pincay
81
Figura No. 10 Conocimiento de OWASP
Fuente: Investigación Propia
Autores: Erika Hernández-Gerson Pincay
Análisis.- Como se muestra en el gráfico solo un 33% de la
muestra de estudio tiene conocimiento de la Organización OWASP para
la realización de auditoria de seguridad en servidores web y el 67% no
tiene conocimiento de la misma.
Pregunta # 8
82
8. ¿Considera usted que la utilización de OWASP sería de gran
ayuda para detectar vulnerabilidades y brechas de seguridad
en el servidor web de la Empresa Publynext S.A.?
Cuadro No. 15 Resultado Pregunta # 8
OPCIONES FRECUENCIA PORCENTAJE
SI 3 100%
NO 0 0%
TOTAL 3 100%
Fuente: Investigación Propia
Autores: Erika Hernández-Gerson Pincay
Figura No. 11 Utilización de OWASP
83
Fuente: Investigación Propia
Autores: Erika Hernández-Gerson Pincay
Análisis.- El 100% de los encuestados piensan que el uso de la
herramienta OWASP para realizar una auditoría de seguridad en el
servidor web de la empresa Publynext S.A es de gran ayuda para la
detección de vulnerabilidades y brechas de seguridad del sitio web,
facilitando la respectiva información para su pronta solución.
84
85
CAPÍTULO IV
PROPUESTA TECNOLÓGICA
El objetivo de la propuesta se precisa en conocer la técnica de
estimación de riesgos OWASP que ayudará a efectuar el test de
penetración, con el que se podrá llevar a cabo la auditoria analizando y
valorando vulnerabilidades que posea el sitio web de la Empresa
Publynext S.A., minimizando los riesgos de amenaza en la seguridad de
la aplicación web.
Actualmente existen amenazas de usuarios maliciosos que emplean
diferentes caminos de acceso y logran adquirir información privada, a
continuación, se procede a detallar el proceso de riesgo:
86
Ø Factores que provoca la amenaza.
Ø Embestida que se desarrolla en los procesos de Acaparamiento.
Ø Brechas de seguridad encontradas por usuarios maliciosos.
Ø Eludir los registros de seguridad.
Ø Denunciando impactos técnicos en las gestiones de Base de
Datos.
Entre los métodos de OWASP para el presente trabajo de tesis se
tomó en cuenta la siguiente herramienta:
Owasp ZAP (Zed Attack Proxy)
Analiza el tráfico HTTP/HTTPS y logra manipular la interfaz del
aplicativo web, opera como un escáner computarizado, detectando las
debilidades que suelen existir en el sistema de información web.
Posee la capacidad de proporcionar rastreo y monitorizar la
seguridad del aplicativo web, brindando un análisis integro, proporciona
una descripción y solución por cada vulnerabilidad.
87
ANALISIS
Para el proceso de la auditoria, basado en la metodología de
OWASP, se procede a realizar un análisis de riesgos para determinar el
nivel de impacto que se tendrá si las vulnerabilidades encontradas en el
servidor logran ser explotadas por un atacante, sobre la empresa
Publynext S.A.
IDENTIFICACION DEL RIESGO
La información de la cual se hace uso, fue proporcionada por el
departamento de sistemas de la empresa, en las entrevistas realizadas
dentro de las instalaciones de Publynext S.A.
Agentes de amenaza
Se considera según el valor numérico: 3 = ALTO, 2 = MEDIO, 1 =
Bajo, 0 = Desconocido.
Habilidades técnicas para:
Programación y redes: 3
Conocimiento avanzado en computación: 2
88
Habilidades en nivel medio: 2
No tiene habilidades: 0
Tienen accesos:
Total: 2
Algunos: 3
Sin acceso: 0
Vulnerabilidades
Se considera según el valor numérico: 3 = ALTO, 2 = MEDIO, 1 =
Bajo, 0 = Desconocido.
Grados de conocimiento en vulnerabilidades:
Bajo: 1
Detectores de Intrusos:
Localización activa: 1
Monitoreado: 2
Sin monitoreo: 0
89
Estimación Del Impacto
Se considera según el valor numérico: 5 = ALTO, 4 = MEDIO, 2 =
Mínima.
Impacto Técnico (servicios, datos)
Perdida en la confiabilidad
Datos considerados críticos: 5
Datos considerados no críticos: 4
Mínima: 2
Perdida en la disponibilidad
Servicios considerados críticos: 5
Servicios considerados no críticos: 4
Mínima: 2
Perdida en la integridad
Datos considerados críticos: 5
Datos considerados no críticos: 4
90
Mínima: 2
ESTIMACIÓN DE LA PROBABILIDAD DEL RIESGO
Se lo realiza mediante el cálculo del promedio de la sumatoria de
las variables de agentes de amenaza y variables de vulnerabilidades
sobre la cantidad total de variables.
Al realizar el análisis calificamos la variable de agentes de
amenaza en 2 que es un promedio general entre el promedio de las
habilidades técnicas (2) y el promedio que tienen acceso (2).
Al realizar el análisis calificamos la variable de vulnerabilidades en
1 que es un promedio general entre el promedio de los grados de
conocimiento en vulnerabilidades (1) y el promedio de detectores de
Intrusos (1).
Por lo tanto:
= 0.75
Según los rangos indicados por la metodología de OWASP (0 to <
3) la probabilidad general es BAJA. (Ver Cuadro No. 4)
91
ESTIMACIÓN DEL IMPACTO
Se lo realiza mediante el cálculo del promedio de la sumatoria de
las variables del impacto técnico sobre la cantidad total de variables.
Al realizar el análisis calificamos la variable de pérdida en la
confidencialidad en 5 debido a que los datos que maneja Publynext S.A.
son considerados críticos.
Al realizar el análisis calificamos la variable de pérdida de la
disponibilidad en 4 debido a que los servicios que maneja Publynext S.A.
son considerados no críticos.
Al realizar el análisis calificamos la variable de pérdida de la
integridad en 5 debido a que los datos que maneja Publynext S.A. son
considerados críticos.
Por lo tanto:
= 4.66
Según los rangos indicados por la metodología de OWASP (3 to <
6) la probabilidad del impacto técnico es MEDIO. (Ver Cuadro No. 4)
92
DETERMINACIÓN DE LA SEVERIDAD DEL IMPACTO
Se determina mediante el promedio de los valores obtenidos entre
la estimación de la probabilidad del impacto y la estimación de la
probabilidad del riesgo.
= 2.5
Según los rangos indicados por la metodología de OWASP, la
severidad del impacto es BAJA. (Ver cuadro en Anexo A)
Los resultados y las recomendaciones se argumentan en el Informe
de la auditoria.
INFORME DE AUDITORIA
Identificación del Informe
Auditoria de Seguridad
Identificación del Cliente
Área de Sistemas
93
Identificación de la Empresa
Publynext S.A.
Objetivos
Ø Comprobar la optimización del servidor.
Ø Comprobar que existan controles, procedimientos y patrones de
seguridad.
Ø Evaluar los niveles de acceso al sistema.
Ø Verificar las configuraciones, seguridad del servidor y equipos
informáticos.
Ø Evaluación de las vulnerabilidades detectadas en el servidor.
Descripción
Tras la auditoría realizada en la empresa se comprueba el uso
debido de controles y procesos de seguridad.
Ø Se comprueba la debida seguridad en los controles de accesos
al sistema.
Ø Se comprueba que se esté desarrollando análisis de
vulnerabilidades.
94
Ø Se comprueba que se realiza prueba de intrusiones al sistema y
servidor.
Ø Se comprueba que la empresa ha tomado medidas de
seguridades.
Se detectaron 4 alertas de vulnerabilidades, las mismas que se
detallan a continuación:
Figura No. 12 Alertas por la herramienta OWASP ZAP
Fuente: Datos de investigación. Elaborado por: Erika Hernández-Gerson Pincay
1. - Incomplete Or No Cache-Control And Pragma Http Header Set
Riesgo: Bajo
Confianza: Medio
Alcance: 19 objetos afectados
95
Descripción: Según el análisis realizado el control de cache y el
encabezado de HTTP no se han definido correctamente o existe un
falso/positivo en el navegador y servidores proxy.
Los navegadores por lo general tienen la función de
almacenar en caché recursos descargados/páginas, etc.; cada
página tiene un uso distinto, esto conlleva a que el almacenamiento
caché sea deshabilitado.
Al manejar información confidencial se sugiere realizar
configuraciones adicionales, debido a que los datos pueden estar
siendo almacenados en un lugar distinto.
Solución:
Asegurarse de que la configuración del cache-control del
encabezado http se encuentre en: no-cache, no-store, must-
revalidate y que el encabezado de http se establezca en Pragma:
no-cache
96
No-cache: fuerza a los cachés a enviar la solicitud al servidor de
origen para su validación antes de liberar una copia en caché, esto
lo hace todo el tiempo.
No-store: indica a los cachés a no guardar una copia de cualquier
objeto bajo ninguna condición.
Must-Revalidate: les dice a los cachés que deben obedecer
cualquier información de expiración del objeto ya sea para
renovarlo o utilizarlo.
Max-age: indica el tiempo en que se puede llegar a usar de nuevo
el archivo o petición guardado en cache, terminado el tiempo, se
vuelve a pedir al servidor, este tiempo es presentado en segundos.
Figura No. 13 Configuración Problema 1
Fuente: https://www.keycdn.com/blog/http-cache-headers/ Elaborado por: Erika Hernández-Gerson Pincay
97
2. Web Browser XSS Protection not enabled
Riesgo: Bajo
Confianza: Medio
Alcance: 28 objetos afectados
Descripción: Según el análisis realizado se encuentra
deshabilitado la protección X-XSS del servidor web.
El encabezado de respuesta http permite al servidor web
habilitar o deshabilitar el mecanismo de protección del explorador
web.
El encabezado de respuesta HTTP X-XSS-Protection es
soportado actualmente por las plataformas de Internet Explorer,
Chrome, Safari y son utilizadas como un bloqueo que impide que
las páginas se carguen cuando detectan algún tipo de ataque de
Cross-site-scripting (XSS).
Solución:
Validación de entrada (Input Validation)
98
El sitio web toma en algunos usuarios parámetros de URL o datos
de un texto, para evitar un ataque Cross-Site Scripting es limitar las
entradas del usuario, una lista de restringidos o también llamada
lista negra.
Se puede evitar que un usuario introduzca ciertos caracteres como
mayor que, menor que (“<” y “>”), o símbolos (“). Se compara la
entrada con la lista de caracteres, también frases tales como
etiquetas de scripts que estas se saben que son peligrosas o
maliciosas.
Figura No. 14 Solución Input Validation
Fuente: Datos de investigación. Elaborado por: Erika Hernández-Gerson Pincay
99
La validación de entradas por una lista negra solo funciona si
incluye todos los caracteres o cadenas potencialmente peligrosas,
sin embargo, es imposible llegar a tener todo en una lista negra por
lo que otra técnica debe ser implementada para añadir seguridad
adicional.
Transformar entradas (Input Transformation)
La codificación implica hacer transformaciones directas a la entrada
de un usuario de modo que no se pueda interpretar como código
html. Muchos caracteres pueden ser utilizados para manipular una
página web, mediante el uso de una entidad de caracteres, las
cadenas de caracteres no especiales corresponderán a cada
símbolo especial, esto ayudará a que el navegador determine entre
el código real del sitio web y la entrada del usuario, así eliminamos
las amenazas en inyección de código.
100
Figura No. 15Solución Input Transformation
Fuente: Datos de investigación. Elaborado por: Erika Hernández-Gerson Pincay
Para JavaScript y CSS (Cascading Stylesheets) se emplea un “escape”
para asegurar que los caracteres especiales se manejen adecuadamente,
por ejemplo, hay códigos que usan comillas dobles para definir el
comienzo y final.
String: “Hola Mundo”
Si una entrada contiene comillas, el código pensaría que es el final de la
cadena agregando el fragmento malicioso.
Entrada: “Fragmento Malicioso=” Script.js ”
101
El código puede ser evitado por el manejo de caracteres especiales o
“escape”, de modo que solo están interpretados como texto en lugar de
código, esto se logra con el uso de una barra invertida lo que impedirá
que la cadena de códigos sea analizada.
Entrada de Escape: \”Fragmento Malicioso = \” Script.js \”
La barra invertida impide que las comillas se analicen como código
Escape.- Manejando la propiedad de los caracteres especiales impidiendo
que sean analizados como código.
Políticas de Seguridad – http header
El contenido de una política de seguridad es una lista blanca, un método
de defensa en la que los desarrolladores especifican a qué recursos se
les dará el permiso de ser cargados en la página web, así
proporcionamos una fuerte forma de protección de la escritura exterior.
Esto se logra habilitado el filtro XSS del explorador web estableciendo el
encabezado de respuesta HTTP de protección X-XSS en 1 de esta
manera se tendría un entorno más robusto.
102
Figura No. 16 Configuración Problema 2
Fuente: https://www.keycdn.com/blog/http-cache-headers/ Elaborado por: Erika Hernández-Gerson Pincay
Prevención de las bibliotecas
El acceso como la prevención de las bibliotecas son bibliotecas de código
abierto construidas para evitar ataques XSS
3. X-Frame-Options Header Not Set
Riesgo: Medio
Confianza: Medio
Alcance: 16 objetos afectados
103
Descripción: Según el análisis realizado la cabecera X-Frame-
Options no se encuentra configurada en la respuesta http lo que
resulta vulnerable contra ataques de "clickjacking", es decir que
fácilmente un atacante puede engañar a un usuario para que de un
clic en una página distinta a la que pueda estar visualizando
El ataque clickjacking trabaja por medio de dos capas, la primera
capa es la visible, la que tendrá el trabajo de incitar a la víctima que
de clic al botón de cualquier formulario que comprometa los datos
ingresados. La segunda capa es la invisible o transparente, está
tiene la función de hacer creer a la víctima que se encuentra en
página deseada.
Este ataque tiene como objetivo en el peor de los casos que el
usuario esté digitando una contraseña de una cuenta bancaria y
esté siendo almacenada en una página distinta contralada por el
atacante.
104
El ataque se lo maneja por la sentencia “iframe” en la codificación
html, sirve para invocar o llamar la página invisible (original) en la
página visible (falsa).
Solución:
Para evitar este tipo de ataque se debe impedir que invoquen la
página en el “iframe”, antes se solía colocar el siguiente script en
cada página.
<script>
if(top != window) {
top.location = window.location
}
</script>
Pero, no era tan confiable ese método por lo que el atacante
llegaba a evitar o modificar el script.
Ahora, en el protocolo http, hay una cabecera llamada X-Frame-
Options, en cada página debe configurarse la cabecera para poder
evitar ser llamados ilegítimamente por un “iframe”.
105
Para la seguridad se puede emplear una de los siguientes
comandos en la cabecera de HTTP:
DENY: el navegador evitará que la página sea llamada por un
iframe.
SAMEORIGIN: la página solo puede ser llamada por un iframe
siempre y cuando provenga del mismo dominio.
ALLOW-FROM: Sirve para especificar en qué páginas solo se
podrán llamar por un iframe.
Figura No. 17 Configuración Problema 3
Fuente: https://www.keycdn.com/blog/http-cache-headers/ Elaborado por: Erika Hernández-Gerson Pincay
106
Los servidores de aplicaciones y lenguajes de programación también
tienen métodos para incluir el campo de X-Frame-Options en las
respuestas http.
Otro método de protección contra clickjaking puede ser el “clearclick”, este
plugin Noscript lo ofrece el navegador de FireFox para que el usuario
trabaje en las páginas web sin preocupación de la amenaza de ser timado
en la web.
4. X-Content-Type-Options
Riesgo: Bajo
Confianza: Medio
Alcance: 60 objetos afectados
Descripción: Según el análisis realizado el tipo de optimizador
ANTI-MIME-Sniffing no está configurado en la opción “nosniff”, lo
que permitiría que el atacante pueda examinar el contenido de
cualquier activo de la empresa; inclusive los navegadores más
antiguos permiten dicha configuración.
107
El encabezado de seguridad previene ciertos ataques al ser
deshabilitada, la función de localización de MIME siempre que el
administrador lo realice desde el servidor de origen.
Solución: Asegurarse de que en la aplicación y en el
servidor web se configure debidamente el encabezado de tipo de
contenido, y que se establezca el encabezado X-Content-Type-Options en
"nosniff" para todas las páginas web.
También asegurarse de que los usuarios usen un navegador
moderno y que cumpla con las políticas de la empresa, que no ejecute
Mime-Sniffing.
108
Figura No. 18 Configuración Problema 4
Fuente: https://www.keycdn.com/blog/http-cache-headers/
Elaborado por: Erika Hernández-Gerson Pincay
Verificación de nivel de Seguridad de Aplicaciones del servidor WEB
Para la verificación se realizó un checklist donde se definieron tres niveles
de seguridad, incrementando la profundidad con cada nivel los mismo que
están basados en el Estándar de Verificación de Seguridad en
Aplicaciones (ASVS por sus siglas en inglés)
• ASVS nivel 1 se encuentra dirigido a todo tipo de software.
• ASVS nivel 2 es para aplicaciones que contienen datos
sensibles, que requieren protección.
109
• ASVS nivel 3 es para las aplicaciones más críticas - aplicaciones
que realizan transacciones de alto valor, contienen datos
médicos confidenciales, o cualquier aplicación que requiera el
más alto nivel de confianza.
Figura No. 19 Niveles de Verificación de Seguridad en Aplicaciones de
OWASP
Elaborado por: (OWASP, 2017) Fuente: Datos de Investigación
La figura 15 muestra los niveles de verificación de seguridad con el
nombre específico que se le da a cada nivel.
110
Nivel 1: Oportunista
Una aplicación alcanza ASVS nivel 1 (u oportunista) si se defiende
adecuadamente contra vulnerabilidades de seguridad de
aplicaciones que son fáciles de descubrir y se incluyen en el
OWASP Top 10 u otras listas similares.
Nivel 2: Estándar
Una aplicación alcanza ASVS nivel 2 (o estándar), si se defiende
adecuadamente contra la mayoría de los riesgos asociados con el
software de hoy en día, asegura que controles de seguridad se
encuentran en el lugar adecuado, son efectivos y son utilizados
dentro de la aplicación.
Nivel 3: Avanzado
El nivel 3 en ASVS es el más alto nivel de verificación dentro de
ASVS. Este nivel está reservado normalmente para aplicaciones
que requieren niveles significativos de verificación de seguridad,
como las que se encuentran dentro de áreas de militares, salud,
seguridad, infraestructuras, etc. Requiere un análisis de mayor
profundidad, arquitectura, codificación y Testing en todo nivel.
111
La verificación de nivel de Seguridad de Aplicaciones del servidor WEB se
detalla en el Anexo E.
Propuesta de solución adicional
Actualmente la arquitectura del servidor de Publynext S.A. está
compuesto por un servidor web Apache ejecutado bajo un sistema
operativo Debian 7 con un lenguaje de programación PHP 7 y un servidor
MySQL 5.5, para realizar conexiones con dicha base de datos.
Figura No. 20 Arquitectura actual de Publynext .S.A.
Fuente: Datos de investigación.
Elaborado por: Erika Hernández-Gerson Pincay
112
Mediante el uso de una herramienta adicional (Maltego) podemos
comprobar que el servidor es un Apache, la ejecución de la
herramienta muestra información adicional susceptible a ser usada
para ejecutar algún tipo de ataque al sitio web. (Ver Anexo B)
En busca de minimizar las vulnerabilidades de tipo Inyección SQL y
XSS de las aplicaciones web, encontradas en la auditoría se plantea
una solución que garantice el aseguramiento de los servicios web y de
los datos.
Para la solución que se propone, la arquitectura se fundamenta en el
modelo que se describió anteriormente más un elemento de seguridad
como medida de autenticación y acceso a los datos del servidor web,
los mismos que se especifican en el diseño propuesto.
113
Figura No. 21 Propuesta de solución arquitectura
Fuente: Datos de investigación.
Elaborado por: Erika Hernández-Gerson Pincay
114
Donde se tienen los siguientes elementos:
Aplicación Rest
Componente principal de la solución; contiene los tres
subcomponentes que interactúan entre sí: con el objetivo de dar
soluciones a las peticiones que realizara el cliente.
Ø Persistencia: interactúa directamente con la base de datos y
tiene la capacidad de integrarse a cualquier base de datos
siempre que sea un esquema similar de datos.
Ø Negocio: contiene la lógica para extraer los datos, además de
una fachada llamada AbstractFacade que representará la
fachada del patrón de diseño seleccionado y ApplicationConfig
para configuración, encargada de asociar los archivos que
conlleven al funcionamiento de los servicios RESTful.
Ø Servicios: serán el componente encargado de consumir la
lógica del negocio, específicamente de la clase del componente
115
negocio AbstractFacade, para exponer los datos mediante el
uso de los servicios RESTful.
Tanto el componente de negocio y servicios son parte del patrón de
diseño seleccionado; el componente de negocio será la fachada y el
componente de los servicios será quien consumirá el razonamiento de
la fachada.
Ø Autenticación JAAS: la autenticación será el control de
seguridad lógica, dotará de seguridad a los servicios web; esta
técnica permitirá gestionar el acceso a los servicios web. Este
componente permitirá configurar ciertos niveles de privacidad y
acceso.
Ø Base de datos: este componente es el elemento base de donde
partirá la construcción los servicios web, a partir de los datos
recopilados se definirá los recursos a exponer. Uno de los
propósitos de los servicios web es que el cliente no conozca el
esquema de la base de datos por seguridad de la información.
También importante citar que una base de datos contribuye a la
integridad y seguridad de los datos.
116
Ø Servidor: el servidor de aplicaciones gestionará y desplegará la
aplicación RESTful que a su vez dará respuesta a las
invocaciones de los servicios web. La elección del servidor de
aplicaciones conlleva un compromiso por parte de quién
participa del diseño, puesto que el servidor debe proporcionar
rendimiento y estabilidad necesaria para que los servicios estén
disponibles siempre.
Ø Cliente: será el destinatario final de los recursos, el cliente
puede definirse como una aplicación web, hasta un dispositivo
móvil que trabaje sobre cualquier sistema operativo móvil, entre
las más populares Android, iOS, entre otros.
REST exige el uso de una arquitectura tipo Cliente – Servidor; por tanto,
se detalla la relación o interacción entre actores: cliente y servidor, según
el modelo arquitectónico planteado en la siguiente figura.
117
Figura No. 22 Propuesta con un elemento adicional
Fuente: Datos de investigación.
Elaborado por: Erika Hernández-Gerson Pincay
118
De acuerdo al flujo se especifica una secuencia lógica de pasos para
entender el proceso desde la petición hasta la respuesta del servidor;
se detalla la sucesión de pasos necesarios para demostrar el vínculo
entre componentes del diseño arquitectónico.
1. El Cliente realiza una petición GET HTTPS al servidor.
2. El servidor responde, solicitando al cliente su autenticación.
3. El Cliente envía sus credenciales de autenticación.
4. El módulo de autenticación comprueba las credenciales de
acceso, y decide si el solicitante tiene permisos para acceder a
los servicios web. Si tiene permisos invoca a la aplicación
REST; sino, retorna al Cliente un mensaje de error de
autenticación.
5. Considerando que el cliente realizó una autenticación
satisfactoria, el servidor ejecuta la aplicación REST; de ahí, se
ejecuta la interacción entre componentes del aplicativo para
obtener los datos solicitados. Internamente se ve que:
a. Primeramente, el componente de servicios invoca a la
funcionalidad correspondiente desarrollada en el
componente de negocio con el objeto de consumar la
119
solicitud del cliente.
b. En segundo lugar, según el método invocado por el
componente de servicios web, el componente de
negocio; que es quién contiene la lógica necesaria para
resolver las peticiones, solicita a la persistencia se
ejecute la llamada correspondiente al Procedimiento
Almacenado necesario para cumplir con el
requerimiento.
c. Luego es el componente de persistencia quién se
encarga de negociar e interactuar con el motor de base
de datos, para dar respuesta a la solicitud expuesta por
el cliente.
6. Finalmente una vez resuelta la petición del cliente por parte del
aplicativo; se retorna la información solicitada por el cliente, en
un formato de datos estructurado.
De esta manera, mediante la arquitectura propuesta se pretende
construir y asegurar los distintos servicios web que cumplan las
funcionalidades propuestas.
120
Figura No. 23 Arquitectura de Publynext S.A con propuesta de solución
Fuente: Datos de investigación.
Elaborado por: Erika Hernández-Gerson Pincay
121
Recomendaciones
Las recomendaciones que se indican a continuación son las
inmediatas a tomar correctivos luego de realizar el análisis de las
vulnerabilidades:
Ø Realizar las respectivas configuraciones
Ø Actualizar las herramientas creadoras de contenido web.
Ø Realizar un constante monitoreo en los sistemas de aplicaciones
web.
Ø Registrar el acceso de cualquier usuario sea o no el administrador
o programador a los archivos de la página web.
Adicionalmente, se puede llevar una muy buena gestión y políticas de
seguridad de la información con el fin de evitar el acceso a personas no
autorizadas, por medio de la NORMA ISO 27001, las mismas que
contienen todos controles y políticas que facilitan la implantación e
implementación de seguridad de la información dentro de la empresa.
Por tal motivo se recomienda revisar, analizar y tomar en consideración
la implantación de ciertas políticas expuestas en el Anexo D.
122
Fecha Del Informe
DISEÑO DESARROLLO INFORME
FECHAS 13/12/2017 –
15/12/2017
03/01/2018 –
05/01/2018
15/01/2018 –
17/01/2018
ANÁLISIS DE FACTIBILIDAD
Una vez que se han evaluado las encuestas efectuadas al personal
de sistemas de la empresa Publynext S.A., en donde se logró constatar
desde una perspectiva providencial la realización de la auditoria de
seguridad en el servidor web, por lo que se especifica al proyecto como
factible en relación con todos los elementos tomados en cuenta para la
ejecución del presente ofrecimiento.
Factibilidad Operacional
El beneficio más relevante que se obtendrá con la realización de la
auditoria en el servidor web de la empresa Publynext S.A, es que se
logrará detectar vulnerabilidades y amenaza de ataques cibernéticos
de toda clase como virus informáticos, técnicas de infección, etc.,
dando paso a las soluciones pertinentes.
123
Para su respectivo cumplimiento se procedió a seguir los siguientes
pasos:
• Establecer zonas de inseguridades en la infraestructura de sitio
web con sus concernientes gestiones y afectaciones.
• Precisar instrucciones y monitoreo de las inseguridades más
frecuentes en la web.
• Ejecutar pruebas sobre el sitio web para prescribir sus debilidades,
por medio de instrumentos de testeo (Software).
• Conservar los servicios del lugar web restablecidos.
Planteado lo descrito anteriormente, se establece que es
completamente factible su consumación desde el punto de vista
operacional la auditoria de seguridad en el servidor web de la empresa
Publynext S.A.
Factibilidad Técnica
Con el fin de que el presente proyecto de despliegue y trabaje de
manera correcta, se requiere cumplir con especificaciones técnicas tanto
en elemento hardware como software, la empresa Publynext S.A. posee
124
equipos de computación en sus instalaciones la cuales están disponibles
para ser utilizados en la auditoria a efectuar en el servidor web de la
empresa.
A continuación se especifican las características técnicas del
equipo (PC) con el cual se efectuó la auditoria en Publynext S.A. cabe
indicar que los equipos que el departamento de sistema posee son
adecuados para realizar escaneos constantes en el servidor, de esta
forma se logra reducir costos y se evita la compra de equipos adicionales.
Figura No. 24 Especificaciones técnicas Hardware
Fuente: Investigación Propia
Autores: Erika Hernández-Gerson Pincay
125
El tipo de software utilizará herramientas de libre licenciamiento,
para este proyecto se eligió usar el sistema avanzado Kali Linux ya que
es usada principalmente para la auditoria informática y que además
contiene las herramientas necesarias para realizar escaneos en busca de
vulnerabilidades.
La técnica es factible de realizar en el servidor web de la empresa,
ya que la misma cumple con los requerimientos y las especificaciones
técnicas requeridas.
Factibilidad Legal
El actual proyecto de tesis ha sido llevado a cabo siguiendo las
normas del marco legal apropiado y las herramientas manipuladas se
hallan a disposición en internet siendo las mismas de código abierto, es
decir, su es licencia gratis. Desempeñando lo estipulado en el artículo 16
de la Constitución de la República del Ecuador la cual indica el derecho
de admisión universal a las tecnologías de la información.
126
Factibilidad Económica
Los instrumentos técnicos y humanos demandados para la
ejecución del proyecto existente se detallan seguidamente:
Ø Una computadora Macbook Pro Intel Core i5 con 16 Gb de RAM.
La estimación económica se compone de lo siguiente:
Ø El precio de componentes hardware será nulo ya que la empresa
Publynext S.A. posee dichos recursos.
Ø El precio de software y licencias no poseerá ningún valor debido a
que son componentes de código abierto.
Ø Las licencias para los sistemas operativos se encuentran
contenidos desde el momento en que se compraron los equipos.
Ø Los precios concernientes a elementos humanos de detallan a
continuación en horas hombre para la auditoria de seguridad en el
servidor web de la empresa Publynext S.A. utilizando mecanismos
basados en OWASP.
127
Cuadro No. 16 Recursos Humanos
Fuente: Investigación Propia
Autores: Erika Hernández-Gerson Pincay
Económicamente es factible debido a que no es necesario gastos
adicionales de hardware y software, la auditoria de seguridad en el
servidor web será realizada por el investigador del proyecto existente para
la empresa Publynext S.A.
128
ETAPAS DE LA METODOLOGÍA DEL PROYECTO
Para el desarrollo del actual proyecto de tesis se ha empleado la
metodología de Proyecto AGILE y se detalla en las siguientes fases:
ANÁLISIS Y DIAGNÓSTICO: Se verifica el análisis y diagnóstico
de la aplicación web inicialmente para comprobar si es vulnerable a
embestidas cibernéticas que pongan en peligro la aplicación y
fortalecimiento de las brechas de seguridad existentes.
DISEÑO: Inmediatamente después del análisis y diagnóstico
ejecutado se procede a verificar lo que concierne al diseño de lo que se
va a desarrollar, respetando la disposición cronológica de cómo se va a ir
efectuando el análisis y generando los respectivos informes.
IMPLEMENTACIÓN: Respetando el diseño perfilado, y como
indica el orden cronológico proporcionado, se va a estar implementado
OWASP junto con más herramientas de testeo con el fin de detectar
riesgos de amenazas y vulnerabilidades en la aplicación web.
129
REALIZACIÓN DE PRUEBAS: Se desarrollaron las pruebas
adecuadas en un ambiente de prueba, para consecutivamente reafirmar
que consecuencia puede causar las vulnerabilidades detectadas en dicho
ambiente.
ENTREGABLES DEL PROYECTO
Los entregables concluyentes del presente proyecto de titulación
conciernen a los informes generados por la auditoría efectuada con las
herramientas que se implementaron en el proyecto existente a nivel de la
aplicación web.
CRITERIOS DE VALIDACIÓN DE LA PROPUESTA
Para la validación de la propuesta planteada en el actual proyecto
de tesis, se hizo uso de la encuesta de satisfacción, la misma que fue
efectuada al personal de sistemas de la empresa Publynext S.A., los
cuales constituyen la muestra de estudio.
130
CRITERIOS DE ACEPTACIÓN DEL PRODUCTO O SERVICIO
Para la aprobación de la propuesta del proyecto de titulación
existente, se ha cumplido con los estándares y criterios que pertenecen a
los alcances previamente establecidos para el proyecto en curso.
Cuadro No. 17 Criterios de Aceptación del Proyecto
INDICADORES ESTRATEGIAS NIVEL DE
CUMPLIMIENTO
Evaluación de la
aplicación web.
Generar informes de
riesgo de amenazas y
vulnerabilidades
encontradas en la
aplicación web.
100%
Resultados obtenidos
de evaluación
Con los informes
generados se procede
a emplear las
acciones adecuadas.
100%
Fuente: Investigación Propia
Autores: Erika Hernández-Gerson Pincay
131
CONCLUSIONES Y RECOMENDACIONES
CONCLUSIONES
Ø Se ejecutó un análisis técnico para detectar lo sensible que es la
aplicación web y de acuerdo a los escaneos realizados al servidor
web de Publynext S.A a través de OWASP ZAP se puede concluir
que en ella se encontraron varias vulnerabilidades provenientes
desde cómo se ha desarrollado la aplicación y la forma como sed
tiene configurado el servidor web, las vulnerabilidades identificadas
fueron consideradas con un nivel de riesgos entre medio y bajo
debido al impacto que estas pueden causar en caso de que un
atacante aproveche dicha vulnerabilidad.
Ø Una vez identificadas las vulnerabilidades, se dio a conocer
recomendaciones sostenibles para la mitigación de riesgos, así
como el establecimiento de políticas de seguridad para garantizar
la confidencialidad, integridad y disponibilidad del servidor y sus
aplicaciones.
132
Ø Se presentó un informe de los resultados generados en la auditoría
de seguridad en el servidor web de la empresa Publynext S.A.
donde se especifica cada vulnerabilidad identificada, las posibles
soluciones y recomendaciones para futuros desarrollos de
aplicaciones, cabe recalcar que este documento debe ser una
consulta necesaria que se debe tomar en consideración para que
los nuevos aplicativos presenten el mínimo de vulnerabilidades.
Ø Se procedió a realizar un checklist para calificar y determinar en
qué nivel del estándar de verificación de seguridad en aplicaciones
de OWASP se encuentra la empresa, según lo calificado podemos
concluir que la empresa Publynext S.A posee un nivel de seguridad
Estándar ubicado en el Nivel 2, los análisis del checklist reflejan
que la empresa se defiende adecuadamente contra la mayoría de
los riesgos asociados con el software de hoy en día, la empresa se
encuentra en un nivel ajustado para aplicaciones que manejan
transacciones business-to-business, implementan funciones
sensibles o críticas o incluyen el proceso de otros activos
sensibles.
133
Ø Se planteó una solución que garantice el aseguramiento de los
servicios web y de los datos, mediante el uso de un componente de
seguridad como medida de autenticación (Autenticación JAAS) que
trabaja en conjunto con una aplicación (REST), que ofrecería al
negocio visibilidad, escalabilidad y rendimiento. Para aquello se
presentaron arquitecturas y diagramas de flujos donde se explica
cómo sería el funcionamiento y cómo estaría implantado en la
empresa.
RECOMENDACIONES
Las recomendaciones que se exponen a continuación son por parte de
los autores:
Ø Según las necesidades que se presenten en la empresa se deben
desarrollar políticas de seguridad.
Ø Sensibilizar al personal del departamento de sistemas de la
empresa de la importancia de conocer las políticas de seguridad
que se deben implementar, que ya están implementadas además
de la necesidad de ponerlas en práctica.
134
Ø Los desarrolladores de aplicaciones WEB deben validar cada
campo de ingreso de datos, esto con el fin de evitar la inyección de
datos, el cual es uno de los riesgos con más alto nivel de
vulnerabilidad.
Ø Para emplear Owasp Zap se requiere efectuar un plan de pruebas
en ambientes de trabajo locales, con el fin de conocer la clase de
vulnerabilidad y realizar configuraciones que no perturben el
funcionamiento del aplicativo web.
Ø Configurar adecuadamente el servidor web, con el fin de aumentar
la seguridad en las aplicaciones.
Ø Brindar conocimientos acerca de los criterios de seguridad, en que
se recomiende a los administradores de la aplicación web manejar
la herramienta Owasp Zap, para solucionar las fragilidades de la
aplicación y conseguir soluciones eficaces.
135
Ø Se recomienda conocer y manipular instrumentos Open Source
para los diversos tipos de métodos de investigación en
particularidad con los sistemas web.
136
BIBLIOGRAFÍA
Alvarez, M. A. (22 de 08 de 2001). Desarrollo Web. Recuperado el 22 de
12 de 2017, de https://desarrolloweb.com/articulos/513.php
Anssi Johansson. (14 de 09 de 2017). cENTos. Recuperado el 22 de 12
de 2017, de cENTos: https://wiki.centos.org/es
Burgos María, S. (20 de 03 de 2011). Recuperado el 18 de 12 de 2017, de
http://www.rafaelmellado.cl/material/inf3242/complemet/01.pdf
debian.org. (9 de 12 de 2017). debian. Recuperado el 20 de 12 de 2017,
de debian:
https://www.debian.org/releases/jessie/mips/ch01s03.html.es
Diaz, Alzórriz, Sancristobal, & Alonso. (2014). Recuperado el 18 de 12 de
2017, de http://repositorio.ug.edu.ec/bitstream/redug/11426/1/PTG-
B-
CISC%20845%20Mosquera%20Chiquito%20Pedro%20Gregorio.p
df
Digital Guide. (2017). Digital Guide. Recuperado el 22 de 12 de 2017, de
https://www.1and1.es/digitalguide/servidores/know-how/que-es-
centos-versiones-y-requisitos-del-sistema/
Fco Javier Bermudez Ruiz. (2017). Recuperado el 17 de 12 de 2017, de
https://aulavirtual.um.es/umugdocente-
137
tool/htmlprint/guia/R2H8H0pyVrhQgNFB1aA12nBBH5HMTr31pB8a
3mI8FeNBvn5MuQh
Francisco Prieto Donate. (2015). bibing. Recuperado el 17 de 12 de 2017,
de http://repositorio.ug.edu.ec/bitstream/redug/11426/1/PTG-B-
CISC%20845%20Mosquera%20Chiquito%20Pedro%20Gregorio.p
df
Hilda Gómez. (16 de 11 de 2014). COMPUTERWORLD. Recuperado el
17 de 12 de 2017, de COMPUTERWORLD:
http://cso.computerworld.es/seguridad-en-cifras/wordpress-es-la-
aplicacion-web-mas-atacada
Javier Sanz. (21 de 01 de 2013). Linux Zone. Recuperado el 22 de 12 de
2017, de https://linuxzone.es/distribuciones-principales/debian/
José Dagoberto Pinilla. (07 de 2012). Recuperado el 18 de 12 de 2017, de
https://www.uaeh.edu.mx/docencia/P_Presentaciones/tlahuelilpan/s
istemas/auditoria_informatica/auditoria_informatica.pdf
José Eduardo Rojas Coppari. (2008). Universidad Nacional del Este-
Facultad Politécnica. Recuperado el 20 de 12 de 2017, de
Universidad Nacional del Este- Facultad Politécnica:
http://www.une.edu.py:82/fpune_scientific/index.php/fpunescientific/
article/viewFile/68/70
138
Luis Cardador Cabello, 2. (s.f.). Recuperado el 16 de 12 de 2017, de
http://repositorio.ug.edu.ec/bitstream/redug/11426/1/PTG-B-
CISC%20845%20Mosquera%20Chiquito%20Pedro%20Gregorio.p
df
Martinez, M. (11 de 08 de 2013). Owasp. Recuperado el 17 de 12 de
2017, de https://www.owasp.org/images/5/5f/OWASP_Top_10_-
_2013_Final_-_Espa%C3%B1ol.pdf
Networking and Emerging Optimization. (2017). Networking and Emerging
Optimization. Recuperado el 17 de 12 de 2017, de
http://neo.lcc.uma.es/evirtual/cdd/tutorial/aplicacion/http.html
OWASP. (2017). Recuperado el 15 de 12 de 2017, de
https://www.owasp.org/index.php/About_The_Open_Web_Applicati
on_Security_Project#The_OWASP_Foundation
OWASP. (13 de 07 de 2017). OWASP. Obtenido de OWASP:
https://www.owasp.org/index.php/About_The_Open_Web_Applicati
on_Security_Project#The_OWASP_Foundation
OWASP, F. (2017). OWASP. Obtenido de OWASP:
https://www.owasp.org/index.php/Top_10_2017-Top_10
Quero, García, & Peña. (2007). Recuperado el 17 de 12 de 2017, de
http://repositorio.ug.edu.ec/bitstream/redug/11426/1/PTG-B-
139
CISC%20845%20Mosquera%20Chiquito%20Pedro%20Gregorio.p
df
Universidad de Palermo. (2013). Escritos en la Facultad. Buenos Aires:
Universidad de Palermo.
Vargas Cordero Zoila Rosa. (24 de 03 de 2015). Recuperado el 19 de 12
de 2017, de http://www.redalyc.org/pdf/440/44015082010.pdf
VERACODE. (2017). Recuperado el 17 de 12 de 2017, de
https://www.veracode.com/directory/owasp-top-10
Victor Ricardo Díaz. (2012). REDDES. Recuperado el 17 de 12 de 2017,
de REDDES:
http://reddes.bvsalud.org/reddes3/files/2012/09/Protocolos-de-
interoperabilidad.pdf
Benito, F. G. (2014). Laboratorio de Seguridad Informática. Obtenido de
http://index-of.co.uk/USB/PFC-B.14.pdf
Fidia, A. (2012). Encuesta. Obtenido de
https://uazuay.edu.ec/estudios/sistemas/teleproceso/apuntes_1/fire
wall.htm
Jiménez, R. E. (2017). PRUEBAS DE PENETRACIÓN EN
APLICACIONES WEB. REVISTA TECNOLÓGICA,
http://redicces.org.sv/jspui/bitstream/10972/3018/1/Articulo2.pdf.
140
MOSQUERA, P. G. (2015). ANÁLISIS DE VULNERABILIDAD DE UN
SISTEMA DE INFORMACIÓN WEB . Obtenido de
http://repositorio.ug.edu.ec/bitstream/redug/11426/1/PTG-B-
CISC%20845%20Mosquera%20Chiquito%20Pedro%20Gregorio.p
df
OWASP. (2017). Top 10-2017 Top 10. Obtenido de
https://www.owasp.org/index.php/Top_10_2017-Top_10
PANEQUE, R. J. (1998). METODOLOGÍA DE LA INVESTIGACIÓN .
Obtenido de
http://www.sld.cu/galerias/pdf/sitios/bioestadistica/metodologia_de_
la_investigacion_1998.pdf
PINILLA. (2012). Universidad Autónoma del Estado de Hidalgo . Obtenido
de
https://www.uaeh.edu.mx/docencia/P_Presentaciones/tlahuelilpan/s
istemas/auditoria_informatica/auditoria_informatica.pdf
Sánchez, M. R. (2014). Auditoría de aplicaciones web: metodología y
práctica profesional. pág. 90.
Vargas Cordero, Z. R. (2015). UNA FORMA DE CONOCER LAS
REALIDADES CON EVIDENCIA. Obtenido de
http://www.redalyc.org/pdf/440/44015082010.pdf
ANEXOS
Anexo A
Determinación De La Severidad Del Impacto
Promedio de los valores obtenidos entre la estimación de la
probabilidad del impacto y la estimación de la probabilidad del riesgo u
ocurrencia.
En el siguiente cuadro-matriz, al ubicar que la probabilidad del
impacto es MEDIO y la probabilidad de ocurrencia es BAJO vemos que al
intersectarse da como resultado una severidad del riesgo BAJO.
Anexo B
Uso de herramienta Maltego
Es una herramienta de auditoría no solo para páginas web, si no
que también hace un seguimiento a todo enlace relacionado al domino de
la empresa.
Pestaña Machines
Fuente: Datos de investigación.
Elaborado por: Erika Hernández-Gerson Pincay
Empezamos la ejecución de la herramienta ubicando la pestaña
“Machines” para comenzar el escaneo o seguimiento del dominio.
Función Choose Machine
Fuente: Datos de investigación.
Elaborado por: Erika Hernández-Gerson Pincay
Nos aparecerá una ventana en la cual elegiremos a qué tipo de
entidad haremos el seguimiento, en este caso seleccionaremos a la
compañía Publynext.
Función Choose Machine
Fuente: Datos de investigación.
Elaborado por: Erika Hernández-Gerson Pincay
Colocaremos el dominio de la empresa a la que estamos
auditando.
Opción colocar dominio de empresa.
Fuente: Datos de investigación.
Elaborado por: Erika Hernández-Gerson Pincay
Terminado el escaneo, aparecerá una imagen con el nombre del
dominio.
Fin de escaneo
Fuente: Datos de investigación.
Elaborado por: Erika Hernández-Gerson Pincay
Al dar clic derecho se desplegara una serie opciones para ejecutar
las transformadas, las mismas que sirven para buscar por medio de
cabeceras algún registro de lo que deseamos saber del dominio, en este
caso, nos enfocaremos en la página web.
Maltego
Fuente: Datos de investigación.
Elaborado por: Erika Hernández-Gerson Pincay
Seleccionamos la opción que revela la página web.
Opción para revelar la página web
Fuente: Datos de investigación.
Elaborado por: Erika Hernández-Gerson Pincay
Daremos clic derecho en la página web y seleccionaremos la
siguiente transformada.
Ejecución de la transformación
Fuente: Datos de investigación.
Elaborado por: Erika Hernández-Gerson Pincay
“To Server Technologies” para buscar las herramientas que usa el sitio
web.
Arquitectura del sistema web Publynext
Fuente: Datos de investigación.
Elaborado por: Erika Hernández-Gerson Pincay
Como podemos ver, nos revela que el sitio web está construido en
Adobe Dreamweaver, sabemos que Dreamweaver basa su código en
HTML, también notamos que el servidor que usa es Apache.
El programador al crear la página web debería ocultar la
información relacionada a la programación y las herramientas que usa,
nos permite concluir que cualquier persona entendida del tema puede
llegar a identificar las herramientas, y llegar a diseñar o implementar un
ataque al sitio web.
Anexo C OWASP Zep Ataque Proxy (ZAP)
OWASP ZAP es una aplicación que sirve para identificar, evaluar o hacer
un testeo al aplicativo web para descubrir o hallar vulnerabilidades, este
aplicativo funciona como un servidor proxy, es decir, intersectará toda
petición o respuesta entre el servidor y el usuario.
Una de las herramientas más utilizadas para la auditoria en la
metodología de OWASP es OWASP ZED ATTACK PROXY (ZAP)
FIG. 1 inicio
Fuente: Investigación Propia
Elaborado por: Gerson Briones y Erika Hernández
Para hacer un ataque directo al dominio de nuestra página web, en la
barra que dice URL colocamos el dominio que queremos atacar.
Al seleccionar “Atacar” se cagarán varios procesos, atacará todo el
dominio y nos mostrará todas las vulnerabilidades que tiene la página
web.
FIG. 2 Herramientas
Fuente: Investigación Propia
Elaborado por: Gerson Briones y Erika Hernández
En la figura 2 distinguimos diferentes maneras de hacer un análisis a la
página web, la pestaña historial registra los ataques a distintos dominios
que vayamos atacando.
FIG. 3 Spider
Fuente: Investigación Propia
Elaborado por: Gerson Briones y Erika Hernández
El primer análisis para el mapeo de la página es con la herramienta
“spider”, nos sirve mucho para registrar el árbol de directorios de la página
web y podemos ver con que otras páginas se relacionan o cuales están
fuera del contexto o alcance.
El segundo análisis sería la herramienta “Escaneo Activo”, esta
herramienta sirve para revelar las alertas o vulnerabilidades del sitio web.
FIG. 4 Alertas
Fuente: Investigación Propia
Elaborado por: Gerson Briones y Erika Hernández
La pestaña alerta nos indica las vulnerabilidades que tiene el dominio, nos
da una breve descripción de la vulnerabilidad, cuantos directorios o
documentos están afectados y que nivel de gravedad tiene la
vulnerabilidad.
FIG. 5 Descripción
Fuente: Investigación Propia
Elaborado por: Gerson Briones y Erika Hernández
Si seleccionamos algún objeto afectado, nos dará tal información ya
mencionada, con el detalle de la solución a dicha vulnerabilidad, esto
ayuda mucho a los novatos que lleguen adentrarse en el aplicativo.
FIG. 6 Árbol de Directorios
Fuente: Investigación Propia
Elaborado por: Gerson Briones y Erika Hernández
En la parte izquierda del aplicativo nos mostrará el árbol de directorios
que tiene la página web, cuáles son las páginas que usa, el nombre de las
páginas y cualquier activo que puede llegar a contener el sitio web.
También nos enseña cual es el método que usa la página, si es POST
quiere decir que es una contestación para una petición, pero si es GET es
una respuesta o el mismo código de la página web.
FIG. 7 Panel Superior
Fuente: Investigación Propia
Elaborado por: Gerson Briones y Erika Hernández
En la figura 7 podemos ver que la página “contáctanos” se puede ingresar
los tres parámetros de parte del usuario, “nombre”, “correo” y “mensaje”
FIG. 8 Panel Superior
Fuente: Investigación Propia
Elaborado por: Gerson Briones y Erika Hernández
En el panel superior nos da la opción de ver la petición, es decir, lo que
solicita el cliente y la respuesta que el servidor contestará.
FIG. 9 Panel Superior
Fuente: Investigación Propia
Elaborado por: Gerson Briones y Erika Hernández
Por lo general en la pestaña Respuesta nos mostrará el código de la
página web y también la cabecera del protocolo http.
FIG. 9 Panel Superior
Fuente: Investigación Propia
Elaborado por: Gerson Briones y Erika Hernández
También podemos generar informes en html para una mejor presentación
del estudio
FIG. 9 Panel Superior
Fuente: Investigación Propia
Elaborado por: Gerson Briones y Erika Hernández
Nos detalla ya lo mencionado, especifica que hay una vulnerabilidad
alta, una media y dos bajas.
Este aplicativo es usado para test de penetración en las páginas
webs, muestra las vulnerabilidades y da soluciones a ellas, pero hay que
resaltar que a más de dar mucha información relevante para un ataque,
no hace ataques hacia el dominio.
Anexo D
NORMA ISO/IEC 27001
ISO (Organización Internacional de Normalización) e IEC (Internacional
Comisión misión Electrotécnica) forman el sistema especializado para la
normalización en todo el mundo.
Los requisitos establecidos en esta Norma Internacional son genéricos y
son pretende que sean aplicables a todas las organizaciones, sin importar
su tipo, tamaño o naturaleza.
A.5 Políticas De Seguridad
A.5.1 Dirección de Gestión de Seguridad de la Información Objetivo: Proporcionar orientación y apoyo a la gestión de seguridad de la información en de acuerdo con los requerimientos del negocio y las leyes y reglamentos pertinentes.
A.5.1.1 Políticas para la Información de Seguridad
Control Un conjunto de políticas de seguridad de la información será definido, aprobado por la administración, publicado y comunicada a los empleados y relevantes externa
A.5.1.2
Revisión de la políticas para información seguridad
Control Las políticas de seguridad de la información se revisarán a intervalos planificados o si se producen cambios significativos en asegurar su conveniencia, adecuación y eficacia
A.6 Organización de la seguridad de la información A.6.1 Organización interna Objetivo: Establecer un marco de gestión para iniciar y controlar la implementación de seguridad de la información dentro de la organización
A.6.1.1
Información funciones de seguridad y responsabilidades
Control Todas las responsabilidades de seguridad de la información serán definido y asignado
A.6.1.2 Contactar con autoridades
Control Los contactos pertinentes con las autoridades pertinentes serán mantenido
A.6.1.3 Contactar con interés especial grupos
Control Los contactos adecuados con los grupos de interés especiales u otros foros de seguridad especializada y profesional asociaciones deberán mantenerse
A.6.1.4 Información la seguridad en el proyecto administración
Control Seguridad de la información se dirigirá en el proyecto gestión, independientemente del tipo del proyecto.
A.6.1.5 La segregación de deberes
Control En conflicto deberes y áreas de responsabilidad será segregados para reducir las oportunidades de no autorizado o modificación intencional o mal uso del los activos de la organización
A.8 Gestión de activos
A.8.1 La responsabilidad de los activos Objetivo: lograr y mantener la protección adecuada de los activos de la organización
A.8.1.1 Inventario de activos
Control Activos relacionados con la información y la información instalaciones de procesamiento serán identificados y un inventario de estos activos se elaborarán y mantendrán
A.8.1.2 La propiedad de bienes
Control Serán propiedad Activos mantenidos en el inventario
A.8.1.3 El uso aceptable de bienes
Control Normas para el uso aceptable de la información y los activos asociada a la información y procesamiento de la información instalaciones serán identificados, documentados y implementado
A.8.2 Clasificación de la información Objetivo: Garantizar que la información recibe un nivel adecuado de protección en de acuerdo con su importancia para la organización
A.8.2.1 Clasificación de la información
Control La información se clasifica en términos de su valor, requisitos legales, la sensibilidad o criticidad a la organización
A.8.2.2 Etiquetado de información
Control Un conjunto adecuado de los procedimientos de información etiquetado deberá ser desarrollado e implementado en de acuerdo con el esquema de clasificación de la información adoptado por la organización
A.8.2.3 Manipulación de los activos
Control Los procedimientos para el manejo de los activos deberán desarrollarse e implementado de
acuerdo con la información esquema de clasificación adoptado por la organización
A.9.4 Control del sistema y acceso a las aplicaciones Objetivo: evitar el acceso no autorizado a sistemas y aplicaciones
A.9.4.1 Acceso a la información restricción
Control El acceso a la información y las funciones del sistema de aplicación se limitará de acuerdo con el control de acceso política
A.9.4.2 Inicio de sesión seguro procedimientos
Control Cuando lo exija la política de control de acceso, el acceso a sistemas y aplicaciones deberán ser controladas por un seguro log-on procedimiento
A.9.4.3 Contraseña administración sistema
Control Sistemas de gestión de contraseñas deberán ser interactivo y velarán contraseñas de calidad
A.9.4.4 El uso de privilegiada programas de utilidad
Control El uso de programas de utilidad que podría ser capaz de sistemas y aplicaciones controles primordiales serán restringido y estrechamente controlado
A.9.4.5
Control de acceso a fuente de programas código
Control El acceso al código fuente del programa se limitará
A.12.2 Protección contra el malware Objetivo: asegurar que las instalaciones de la información y procesamiento de la información son protegido contra el malware A.12.2.1 Controles contra Control
el malware
Detección, prevención y recuperación de controles para proteger contra se aplicará malware, combinado con sensibilización de los usuarios apropiados
A.12.4 Registro y seguimiento Objetivo: Para grabar eventos y generar pruebas
A.12.4.2 Protección de registro información
Control Registro de instalaciones y registrar información será protegidos contra la manipulación y acceso no autorizado
A.12.4.3 Administrador y registros del operador
Control Administrador del sistema y del sistema de las actividades del operador deberá estar conectado, protegido y revisado con regularidad
A.12.7 Sistemas de información consideraciones de auditoría Objetivo: minimizar el impacto de las actividades de auditoría en los sistemas operativos
A.12.7.1
Información Auditoría de sistemas controles
Control Requisitos y actividades de verificación de auditoría de los sistemas operativos deben ser cuidadosamente planificadas y acordado para minimizar las interrupciones a los procesos de negocio
A.13 Seguridad de las comunicaciones
A.13.1 Gestión de la seguridad de red Objetivo: garantizar la protección de la información en las redes y su apoyo instalaciones de procesamiento de información
A.13.1 Controles red Control Redes deberán ser gestionados y controlados para proteger información en los sistemas y aplicaciones
A.13.1.2 Seguridad de servicios de red
Control Los mecanismos de seguridad,
niveles de servicio y gestión se identificarán necesidades de todos los servicios de red e incluida en los acuerdos de servicios de red, ya sea estos servicios son prestados en la empresa o subcontratados
A.13.2 La transferencia de información Objetivo: mantener la seguridad de la información transferida dentro de una organización y con cualquier entidad externa
A.13.2.1
Información Políticas de transferencia y procedimientos
Control Formales de transferencia de políticas, procedimientos y controles se estar en su lugar para proteger la transferencia de información mediante el uso de todo tipo de instalaciones de comunicación
A.13.2.2 Acuerdos sobre Información transferencia
Control Acuerdos deberán abordar la transferencia segura de información de negocios entre la organización y partes externas
A.13.2.3 Electrónico mensajería
Control Información involucrado en la mensajería electrónica será apropiadamente protegido
A.13.2.4 La confidencialidad o no divulgación acuerdos
Control Los requisitos para la confidencialidad o de no divulgación acuerdos que reflejen las necesidades de la organización para la protección de la información deberá ser identificado, regularidad revisado y documentado
A.16 Información de gestión de incidentes de seguridad
A.16.1 Gestión de incidentes de seguridad de la información y mejoras Objetivo: garantizar un enfoque coherente y eficaz para la gestión de los incidentes de seguridad de la información, incluyendo la comunicación de eventos de seguridad y debilidades
A.16.1.1 Responsabilidades y procedimientos
Control Responsabilidades y procedimientos de manejo deberán ser establecido para asegurar una rápida, eficaz y ordenada respuesta a incidentes de seguridad de la información
A.16.1.2
Informes Información eventos de seguridad
Control Eventos seguridad de la información se comunicarán a través de canales de gestión adecuadas tan pronto como sea posible
A.16.1.3
Informes información seguridad debilidades
Control Los eventos de seguridad de información se evaluarán y decidido si se clasificarán como información incidentes de seguridad
A.16.1.5
Responder a Información incidentes de seguridad
Control Los incidentes de seguridad de información deberán recibir una respuesta en de acuerdo con los procedimientos documentados
A.16.1.6
Aprender de Información incidentes de seguridad
Control Los conocimientos adquiridos desde el análisis y la resolución de incidentes de seguridad de información se utilizarán para reducir la probabilidad o el impacto de futuros incidentes
A.16.1.7 Colección de evidencia
Control La organización debe definir y aplicar procedimientos para la
identificación, recolección, adquisición y preservación de la información, que puede servir como evidencia
A.17 Los aspectos de seguridad de información de gestión de la continuidad del negocio
A.17.1 Información de la continuidad de seguridad Objetivo: Información sobre la continuidad garantía se incrusta en la organización de gestión de continuidad del negocio (BCM) para garantizar la protección de la información en cualquier momento y anticipar acontecimientos adversos
A.17.1.1
Planificación Información la continuidad de seguridad
Control La organización debe determinar sus requisitos para seguridad de la información y la continuidad de la información gestión de la seguridad en situaciones adversas, por ejemplo, durante una crisis o desastres
A.17.1.2
Implementar Información la continuidad de seguridad
Control La organización debe establecer, documentar, implementar y mantener los procesos, procedimientos y controles a garantizar el nivel necesario de continuidad seguridad de la información durante una situación adversa
A.17.1.3
Verificar, revisión y evaluar información La continuidad de seguridad
Control La organización debe verificar lo establecido y controles de continuidad de seguridad de la información aplicadas a intervalos regulares con el fin de asegurarse de que son válidos y eficaz durante situaciones adversas
A.18 Conformidad
A.18.1 Revisiones de seguridad de información Objetivo: Garantizar que la seguridad informática es implementado y operado en de acuerdo con las políticas y procedimientos de la organización
A.18.1.1 Independiente repaso de información seguridad
Control El enfoque de la organización para la gestión de la información seguridad y su aplicación (es decir, los objetivos de control, controles, políticas, procesos y procedimientos para seguridad de la información) se revisará de forma independiente a intervalos planificados o cuando cambios significativos en el ocurren implementación de seguridad
Anexo E
Niveles de verificación de seguridad de aplicaciones
V1 ARQUITECTURA, DISEÑO Y MODELADO DE AMENAZAS Niveles # Descripción 1 2 3 1.1 Verificar que todos los componentes de la aplicación se
encuentran identificados y asegurar que son necesarios. ü
1.2 Verificar todos los componentes, tales como bibliotecas, módulos y sistemas externos, que no son parte de la aplicación pero que la misma los necesita para funcionar se han identificado
ü
1.3 Verificar que se ha definido una arquitectura de alto nivel para la aplicación
ü
1.5 Verificar que todos los componentes que no son parte de la aplicación pero que son necesarios para su funcionamiento, sean definidos de acuerdo a las funciones de negocio o de seguridad que proporcionan.
ü
1.7 Verificar que todos los controles de seguridad (incluyendo las bibliotecas que llaman a servicios de seguridad externos) tiene una implementación centralizada.
ü
1.8 Verificar que los componentes están separados unos de otros mediante controles de seguridad, tales como segmentación de la red, reglas de firewall, o grupos de seguridad basados en la nube.
ü
1.9 Verificar que la aplicación tiene una clara separación entre la capa de datos, la capa de control y la capa de presentación, tal que las decisiones de seguridad pueden aplicarse en sistemas confiables.
ü
1.10 Verificar que no hay ninguna lógica de negocio sensible, claves secretas u otra información propietaria en el código del lado del cliente
ü
1.11 Verificar que todos los componentes de la aplicación, bibliotecas, módulos, frameworks, plataformas y sistemas operativos se encuentran libres de vulnerabilidades conocidas.
ü
V2 REQUISITOS DE VERIFICACIÓN DE AUTENTICACIÓN Niveles # Descripción 1 2 3 2.1 Verificar que todas las páginas y recursos requieran autenticación
excepto aquellos que sean específicamente destinados a ser públicos (Principio de mediación completa).
ü
2.3 Verificar que todos los controles de autenticación se realicen del lado del servidor.
ü
2.4 Verificar que los controles de autenticación fallan de forma segura ü
para evitar que los atacantes no puedan iniciar sesión. 2.5 Verificar que los campos de contraseña permiten o fomentan el
uso de frases como contraseñas (passphrases) y no impide el uso de gestores de contraseñas, contraseñas largas o altamente complejas.
ü
2.7 Verificar que la funcionalidad de cambio de contraseña solicite la contraseña anterior, la nueva contraseña y una confirmación de contraseña.
ü
2.8 Verificar que todas las decisiones de autenticación son registradas en la bitácora sin almacenar información sobre la contraseña o el identificador de la sesión. Esto debería incluir los metadatos necesarios para investigaciones de seguridad.
ü
2.9 Verificar que las contraseñas de las cuentas se encuentren almacenadas utilizando una rutina de hashing y que requiera un factor de trabajo lo suficiente alto para evitar un ataque de fuerza bruta.
ü
2.10 Verificar que las credenciales son transportadas mediante un enlace cifrado adecuadamente y que todas las páginas/funciones que requieren que el usuario introduzca credenciales se realicen utilizando enlaces cifrados.
ü
2.11 Verificar que las funciones de recuperar contraseña y acceso no revelen la contraseña actual y que la nueva contraseña no se envíe en texto plano al usuario.
ü
2.12 Verificar que no es posible enumerar información mediante las funcionalidades de: inicio de sesión, reinicio o recuperación contraseñas.
ü
2.13 Verificar que no se utilizan contraseñas por defecto en la aplicación o cualquiera de los componentes utilizados por la misma (como "admin/password).
ü
2.14 Verificar que existen mecanismos de anti-automatización que previenen la verificación de credenciales obtenidas de forma masiva, ataques de fuerza bruta y ataques de bloqueos de cuentas.
ü
2.15 Verificar que todas las credenciales de autenticación para acceder a servicios externos a la aplicación se encuentran cifradas y almacenadas en un lugar protegido.
ü
2.18 Verificar que el sistema puede configurarse para no permitir el uso de un número de contraseñas utilizadas anteriormente.
ü
2.19 Verificar que existen medidas para bloquear el uso de contraseñas comúnmente utilizadas y contraseñas débiles.
ü
2.20 Verificar que todos los desafíos de autenticación, ya sea exitosa o fallida, responden en el mismo tiempo promedio
ü
2.21 Verificar que secretos, llaves de API y contraseñas no se incluyen en el código fuente o en los repositorios en línea de código fuente.
ü
2.23 Verificar que las interfaces administrativas de la aplicación no sean accesibles a intrusos.
ü
V3 REQUISITOS DE VERIFICACIÓN DE GESTIÓN DE SESIONES Niveles # Descripción 1 2 3 3.1 Verificar que no se utiliza un gestor de sesiones personalizado, o
que, si el gestor de sesiones es personalizado, éste sea resistente contra los ataques más comunes.
ü
3.2 Verificar que las sesiones se invalidan cuando el usuario cierra la sesión.
ü
3.3 Verificar que las sesiones se invalidan luego de un período determinado de inactividad.
ü
3.4 Verificar que todas las páginas que requieren autenticación poseen acceso fácil y visible a la funcionalidad de cierre de sesión.
ü
3.6 Verificar que toda autenticación exitosa y re autenticaciones generen un nuevo identificador de sesión.
ü
3.7 Verificar que sólo los identificadores de sesión generados por la aplicación son reconocidos como activos por ésta.
ü
3.8 Verificar que los identificadores de sesión almacenados en cookies poseen su atributo “path” establecido en un valor adecuadamente restrictivo y que además contenga los atributos "Secure" y "HttpOnly"
ü
3.9 Verificar que la aplicación limita el número de sesiones concurrentes activas.
ü
3.10 Verificar que una lista de sesiones activas esté disponible en el perfil de cuenta o similar para cada usuario. El usuario debe ser capaz de terminar cualquier sesión activa.
ü
3.11 Verificar que al usuario se le sugiera la opción de terminar todas las otras sesiones activas después de un proceso de cambio de contraseña exitoso.
ü
V4 REQUISITOS DE VERIFICACIÓN DEL CONTROL DE ACCESO Niveles # Descripción 1 2 3 4.4 Verificar que los controles de acceso fallen de forma segura. ü 4.5 Verificar que las mismas reglas de control de acceso implícitas en
la capa de presentación son aplicadas en el servidor. ü
4.6 Verificar que todos los atributos de usuario, datos e información de las políticas utilizadas por los controles de acceso no puedan ser manipulados por usuarios finales a menos que sean específicamente autorizados.
ü
4.7 Verificar que existe un mecanismo centralizado (incluyendo las bibliotecas que requieren servicios de autorización externa) para
ü
proteger el acceso a cada tipo de recursos protegidos. 4.8 Verificar que todas las acciones de control de acceso pueden ser
registradas y que todas las acciones fallidas son registradas. ü
4.9 Verificar que la aplicación o su infraestructura emite tokens anti-CSFR aleatorios existe otro mecanismo de protección de la transacción.
ü
4.12 Verificar que la aplicación aplique correctamente la autorización contextual para no permitir la manipulación de parámetros de la URL.
ü
V5 REQUISITOS DE VERIFICACÓN PARA MANEJO DE ENTRADAS DE DATOS MALICIOSOS
Niveles
# Descripción 1 2 3 5.1 Verificar que el entorno de ejecución no es susceptible a
desbordamientos de búfer, o que los controles de seguridad previenen desbordamientos de búfer.
ü
5.2 Verificar que las fallas de validación de entradas de datos del lado del servidor sean rechazadas y registradas.
ü
5.3 Verificar que se aplican las rutinas de validación de entradas de datos del lado del servidor.
ü
5.4 Verificar que un único control de validación de entrada es utilizado por la aplicación para cada tipo de datos que es aceptado.
ü
5.6 Verificar que la aplicación no es susceptible a la inyección de comandos del sistema operativo, o que los controles de seguridad previenen la inyección de comandos del sistema operativo.
ü
5.7 Verificar que la aplicación no es susceptible a la inclusión de archivo remoto (RFI) o inclusión de archivo Local (LFI) cuando el contenido es utilizado como una ruta a un archivo.
ü
5.8 Verificar que la aplicación no es susceptible a ataques comunes de XML, como manipulación de consultas XPath, ataques de entidad externa XML, y ataques de inyección XML.
ü
5.12 Verificar que las validaciones del lado del cliente se utilizan como una segunda línea de defensa, en adición a la validación del lado del servidor.
ü
5.15 Para tecnologías de plantilla de codificación automática, si ésta se ha deshabilitado, asegurar que la sanitización de HTML esté habilitada en su lugar.
ü
5.16 Verificar que los datos transferidos desde un contexto DOM a otro, utilice métodos de JavaScript seguro, como pueden ser .innerText y .val
ü
5.17 Verificar que los datos de autenticación se eliminen del almacenamiento del cliente, tales como el DOM del navegador, después de terminada la sesión.
ü
V6 REQUISITOS DE VERIFICACIÓN PARA LA CRIPTOGRAFÍA EN EL ALMACENAMIENTO
Niveles
# Descripción 1 2 3 6.1 Verificar que todos los módulos criptográficos fallen de forma
segura, y que los errores sean manejados de tal manera que no permitan ataques Oracle padding.
ü
6.3 Verificar que los algoritmos criptográficos utilizados por la aplicación hayan sido validados contra FIPS 140-2 o un estándar equivalente.
ü
6.4 Verificar que los módulos criptográficos operen en su modo aprobado según sus políticas de seguridad publicadas.
ü
6.5 Verificar que los consumidores de servicios criptográficos no poseen acceso directo a los datos de la clave. Aislar procesos criptográficos, incluyendo secretos maestros y considerar el uso de un módulo de seguridad de hardware (HSM).
ü
6.6 La información de identificación personal debe almacenarse de forma cifrada y verificar que la comunicación se lleve a cabo utilizando de canales protegidos.
ü
6.7 Verificar que contraseñas y claves criptográficas sean sobrescritas con ceros en memoria tan pronto no sean necesarias, con el fin de mitigar ataques de volcado de memoria.
ü
6.8 Verificar que todas las claves y contraseñas sean reemplazables, y sean generadas o reemplazadas durante la instalación
ü
V7 REQUISITOS DE VERIFICACIÓN DE GESTIÓN DE ERRORES Niveles # Descripción 1 2 3 7.1 Verificar que la aplicación no emita mensajes de error o rastros de
pilas que contengan datos sensibles que podrían ayudar a un atacante, incluyendo el identificador de sesión, versiones de software/entorno y datos personales.
ü
7.2 Verificar que la lógica de manejo de errores en controles de seguridad niegue el acceso por defecto.
ü
7.3 Verificar que los controles del registro de seguridad proporcionen la capacidad para registrar los eventos de éxito y sobre todo los eventos de falla que son identificados como relevantes para la seguridad.
ü
7.4 Verificar que cada registro de evento incluya la información necesaria para permitir una eventual investigación y correlación con otros eventos.
ü
7.5 Verificar que todos los eventos que incluyen datos no confiables no se ejecuten como código en el software destinado a la visualización del registro.
ü
7.6 Verificar que los registros de seguridad estén protegidos contra ü
modificación y acceso no autorizado. 7.8 Verificar que todos los símbolos no imprimibles y separadores de
campos estén codificados correctamente en las entradas del registro, para evitar la inyección del registro que no permita seguir las pistas de un acto malicioso.
ü
7.9 Verificar que los campos del registro de fuentes confiables y no confiables sean identificables en las entradas del registro.
ü
7.10 Verificar que un registro de auditoría o similar permita la no repudiación de transacciones claves.
ü
7.11 Verificar que los registros de seguridad poseen alguna forma de verificación o control de integridad para prevenir modificaciones no autorizadas.
ü
7.12 Verificar que los registros estén almacenados en una partición diferente a donde ejecuta la aplicación con una rotación de registros adecuada.
ü
V8 REQUISITOS DE VERIFICACIÓN DE PROTECCIÓN DE DATOS Niveles # Descripción 1 2 3 8.1 Verificar que todos los formularios que contengan información
sensible se les haya desactivado el almacenamiento de caché en el cliente, incluyendo funciones de autocompletar.
ü
8.2 Verificar que la lista de datos sensibles procesados por la aplicación se encuentra identificada, y que existe una política explícita de cómo debe controlarse el acceso a estos datos, cifrarse y reforzarse bajo las directivas de protección de datos pertinentes.
ü
8.3 Verificar que toda información sensible es enviada al servidor en el cuerpo o cabeceras del mensaje HTTP (por ejemplo, los parámetros de la URL nunca se deben utilizar para enviar datos sensibles).
ü
8.4 Verificar que, en el servidor, todas las copias almacenadas en caché o temporales de datos sensibles estén protegidos de accesos no autorizados o son purgados/invalidados después del acceso por parte del usuario autorizado.
ü
8.5 Verificar que existe un mecanismo para eliminar de la aplicación todo tipo de dato sensible luego de transcurrido el tiempo definido por la política de retención.
ü
8.6 Verificar que la aplicación reduce al mínimo el número de parámetros en una solicitud, como campos ocultos, variables de Ajax, cookies y valores en encabezados.
ü
8.8 Verificar que datos almacenados en el cliente (como almacenamiento local de HTML5, almacenamiento de la sesión, IndexedDB, cookies normales o las cookies de Flash) no
ü
contengan información sensible o información personal identificable.
8.9 Verificar que el acceso a datos sensibles es registrado en bitácora, los datos son registrados acorde a las directivas de protección de datos o cuando el registro de los accesos es requerido.
ü
8.10 Verificar que la información sensible mantenida en memoria es sobre escrita con ceros tan pronto como no es requerida, para mitigar ataques de volcado de memoria
ü
V9 REQUISITOS DE VERIFIACIÓN DE SEGURIDAD DE LAS COMUNITARIAS
Niveles
# Descripción 1 2 3 9.1 1 Verificar que puede construirse la cadena de confianza desde
una CA (Autoridad de Certificación) para cada certificado TLS (Transport Layer Security) del servidor, y que cada certificado del servidor sea válido
ü
9.2 Verificar que se utiliza TLS para todas las conexiones (incluyendo conexiones back-end y externas) autenticadas o que involucran funciones o información sensible, y no recaigan en protocolos inseguros o sin cifrado. Asegúrese de que la alternativa más fuerte es el algoritmo preferido.
ü
9.3 Verificar que se registran los fallos de conexiones TLS en el backend.
ü
9.4 Verificar que se construyen las cadenas de confianza para todos los certificados de clientes mediante anclajes de confianza e información de revocación de certificados.
ü
9.5 Verificar que todas las conexiones a sistemas externos que involucran acciones o información sensible sean autenticadas.
ü
9.6 Verificar que haya una sola implementación estándar de TLS utilizada por la aplicación la cual esté configurada para operar en un modo aprobado de operación.
ü
9.7 Verificar que el certificado de clave pública se encuentre fijado (Certificate Pinning) con la clave de producción y la clave pública de respaldo. Para obtener más información, vea las referencias abajo.
ü
9.8 Verificar que los encabezados HTTP Strict Transport Security sean incluidos en todas las peticiones y para todos los subdominios, como Strict-Transport-Security: max-age = 15724800; includeSubdomains
ü
9.10 Verificar que una adecuada revocación de certificados, tal como el protocolo de estatus de certificado en línea (OSCP), está habilitada y configurada para determinar el estado de vigencia del certificado.
ü
9.11 Verificar que se utilicen únicamente algoritmos, cifra dores y ü
protocolos fuertes, a través de toda la cadena de confianza, incluyendo certificados raíz y certificados intermediarios de la autoridad certificadora seleccionada.
9.12 Verificar que la configuración de TLS esté en línea con las mejores prácticas actuales, particularmente debido a que configuraciones comunes se convierten en inseguras a medida que transcurre el tiempo.
ü
V10 REQUISITOS DE VERIFICACIÓN DE CONFIGURACIÓN DE SEGURIDAD HTTP
Niveles
# Descripción 1 2 3 10.1 Verificar que la aplicación acepte solo un conjunto definido de
métodos de solicitud HTTP y que son necesarios, como GET y POST, y métodos no utilizados (por ejemplo: TRACE, PUT y DELETE) se encuentran explícitamente bloqueados.
ü
10.3 Verificar que los encabezados HTTP agregados por un proxy confiable o dispositivos SSO, tales como un token de portador (bearer), son autenticados por la aplicación.
ü
10.4 Verificar que el cabezal X-FRAME-OPTIONS se encuentra especificado para los sitios que no deben ser embebidos en X-Frame en sitios de terceros
ü
10.5 Verificar que los encabezados HTTP o cualquier parte de la respuesta HTTP no expongan información detallada de la versión de los componentes del sistema.
ü
10.6 Verificar que todas las respuestas del API contienen opciones X-Content-Type: nosniff y ContentDisposition: attachment; filename="api.json" (u otro nombre de archivo apropiado para el tipo de contenido).
ü
10.7 Verificar que la política de seguridad de contenido (CSPv2) está en uso de tal manera que ayude a mitigar vulnerabilidades de inyección comunes de DOM, XSS, JSON y Javascript
ü
10.8 Verificar que el encabezado "X-XSS-Protection: 1; mode=block" esté presente para habilitar a los navegadores a filtrar XSS reflejados
ü
V11 REQUISITOS DE VERIFIACIÓN PARA CONTROLES MALICIOSO
Niveles
# Descripción 1 2 3 11.1 Verificar que toda actividad maliciosa sea adecuadamente aislada
o encajonada para retrasar y disuadir a los atacantes de atacar a otras aplicaciones.
ü
11.2 Verificar que el código fuente de la aplicación y tantas bibliotecas de terceros como sean posibles, no poseen puertas traseras, huevos de pascua, o fallas de lógica en la autenticación, control de
ü
acceso, validaciones de entrada y lógica de negocio en transacciones de alto valor.
V12 REQUISITOS DE VERIFIACIÓN PARA LÓGICA DE NEGOCIOS Niveles # Descripción 1 2 3 12.2 Verificar que la aplicación tiene límites de negocio y el aplique
correctamente por cada usuario, con alertas configurables y reacciones automatizadas ante ataques inusuales o automáticos.
ü
V13 REQUISITOS DE VERIFIACIÓN DE ARCHIVOS Y RECURSOS Niveles # Descripción 1 2 3 13.1 Verificar que las URL de redireccionen y reenvíen sólo a destinos
clasificados en la lista blanca, o mostrar una advertencia cuando se redirija a contenido potencialmente no confiable.
ü
13.3 Verificar que los archivos procedentes de fuentes no confiables sean validados para ser del tipo del cual se espera y sean analizados por escáneres antivirus para evitar la carga de contenido malicioso conocido.
ü
13.4 Verificar que datos no confiables no se utilicen en funcionalidades de reflexión, cargado de clases o inserción para prevenir vulnerabilidades de inclusión de archivos remotos/locales.
ü
13.5 Verificar que datos no confiables no se utilicen en recursos de dominios compartidos (CORS) para proteger contra el contenido remoto arbitrario.
ü
13.6 Verificar que los archivos obtenidos de fuentes no confiables se almacenen fuera del webroot, con permisos limitados, preferiblemente con una fuerte validación.
ü
13.7 Verificar que el servidor web o de aplicación se encuentra configurado por defecto para negar el acceso a recursos remotos o sistemas fuera del servidor web o de aplicación.
ü
13.8 Verificar que el código de la aplicación no ejecuta datos cargados obtenidos de fuentes no confiables.
ü
13.9 Verificar que no utiliza Flash, Active-X, Silverlight, NACL, Java del lado del cliente u otras tecnologías del lado del cliente que no sean soportadas de forma nativa a través de los estándares de navegador W3C.
ü
V14 REQUESITOS DE VERIFIACIÓN DE SERVICIOS WEB Niveles # Descripción 1 2 3 14.1 Verificar que el mismo estilo de codificación se utiliza tanto en el
cliente como el servidor. ü
14.2 Verificar que el acceso a las funciones de administración y gestión de la aplicación proveedora de servicios web sea limitado a los administradores.
ü
14.3 Verificar que existen esquemas XML o JSON y que éstos son ü
verificados por la aplicación antes de aceptar datos de entrada. 14.4 Verificar que todos los datos de entrada se encuentren limitados a
un tamaño adecuado. ü
14.5 Verificar que los servicios REST comprueben explícitamente que el Content-Type entrante sea el que se espera, como aplicación/xml o aplicación/json.
ü
14.6 Verificar que el contenido de los mensajes se encuentra firmado para asegurar el transporte confiable entre el cliente y el servicio, utilizando JSON Web Signing o WS-Security para servicios SOAP.
ü
14.7 Verificar que no existen rutas de acceso alternativas y menos seguras.
ü
V15 REQUISITOS DE CONFIGURACIÓN Niveles # Descripción 1 2 3 15.2 Las comunicaciones entre componentes, tales como entre el
servidor de aplicaciones y el servidor de base de datos, deberían ser cifradas, particularmente cuando los componentes están en diferentes contenedores o en sistemas diferentes.
ü
15.3 Las comunicaciones entre componentes, tales como entre el servidor de aplicaciones y el servidor de base de datos deberían autenticarse utilizando una cuenta con los mínimos privilegios necesarios.
ü
15.4 Verificar que los despliegues de la aplicación se encuentren dentro de Sandboxes, en contenedores o aislados para retrasar y disuadir a los atacantes de atacar a otras aplicaciones.
ü
15.5 Verificar que los procesos de compilación y despliegue de la aplicación se realizan de forma segura.
ü
15.6 Verificar que los administradores autorizados posean la capacidad de verificar la integridad de todas las configuraciones de seguridad pertinentes para garantizar que no hayan sido manipuladas.
ü
15.7 Verificar que todos los componentes de aplicación se encuentren firmados.
ü
15.8 Verificar que los componentes de terceros proceden de repositorios de confianza.
ü
15.9 Verificar que los procesos de compilación para los lenguajes de nivel de sistema operativo tengan todas las banderas de seguridad activas, tales como controles de seguridad, DEP y ASLR.
ü
15.10 Verificar que todos los recursos de la aplicación se encuentran alojados en la aplicación en vez de confiar en un CDN o proveedores externos, tales como bibliotecas JavaScript, estilos CSS o web fonts
ü
