TESINA - Ricardo Torres Final

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS
FACULTAD DE INGENIERÍA ELECTRÓNICA Y ELÉCTRICA
EVALUACIÓN DEL USO DE LA METODOLOGÍA OWASP PARA EL

MEJORAMIENTO DE LA SEGURIDAD DE APLICACIONES WEB DE
INSTITUCIONES EDUCATIVAS
TESINA PROFESIONAL
PARA OPTAR EL TÍTULO PROFESIONAL DE
INGENIERO DE TELECOMUNICACIONES
PRESENTADO POR
RICARDO MARTIN TORRES SILVA
PROMOCIÓN
2016-II
LIMA – PERÚ
2018
II
RESUMEN
El presente trabajo evalúa el uso de la metodología propuesta por la organización
Open Web Application Security Project - OWASP para el mejoramiento de la seguridad de
aplicaciones web de instituciones educativas. El trabajo tiene como fin corregir ciertos
errores que se visualizan en los aplicativos web de diversas universidades.
Dado que siempre se quiere obtener un punto de partida o unas recomendaciones
mínimas antes de publicar una aplicación web, este trabajo tiene algunas recomendaciones
técnicas y controles, los cuales fueron recopilados de OWASP, los que ayudan a reducir los
riesgos a los que se encuentran expuestos las aplicaciones web.
Así mismo, la metodología de calificación de riesgo de OWASP es un documento muy
útil al momento de identificar y calificar los riesgos presentes. Debido a ello, los análisis
realizados se basaron en esta metodología.
Finalmente, se observó una mejora significativa en la seguridad de las aplicaciones
web luego de implementadas las recomendaciones y controles, llegando a un porcentaje de
reducción de hasta 60% del nivel de riesgo. A futuro, este trabajo puede ayudar a las
instituciones educativas peruanas a cómo aprovechar la metodología OWASP para mejorar la
seguridad de sus aplicaciones web.

III
ABSTRACT
The present work evaluates the correct use of the Open Web Application Security
Project - OWASP methodology for the improvement of educational institutions’ web
applications security. This investigation is based on educational institutions due to the
audience to which it is addressed, as well as some errors that were seen in web applications of
various universities.
For every developer is always difficult to have a starting point or implement
recommendations before publishing a web application. Thus, this work has some technical
recommendations and controls, which were compiled from OWASP and will help to mitigate
a large number of risks.
Also, OWASP’s risk rating methodology is a very useful document when identifying
and rating the risks. Due to that, the analysis made where based in this methodology.
Finally, there was a significant improvement in the security of web applications after
implementing the recommendations and controls, reaching a reduction percentage of up to
60% of the risk level. In this way, it is highlighted that the OWASP documentation is very
useful for every developer and its use is recommended. In the future, this work can help
Peruvian educational institutions how to take advantage of the OWASP methodology to
improve the security of their web applications.

IV
ÍNDICE DE CONTENIDO
RESUMEN............................................................................................................................... II
ABSTRACT ........................................................................................................................... III
INTRODUCCIÓN ................................................................................................................... 1
I. EL PROBLEMA DE LA INVESTIGACIÓN ................................................................ 2
1.1. Descripción de la realidad del problema. ............................................................................ 2
1.2. Definición del problema......................................................................................................11
1.2.1. Problema general ........................................................................................................11
1.2.2. Problemas específicos .................................................................................................11
1.3. Justificación e importancia de la investigación. ...............................................................12
1.3.1. Justificación Teórica ...................................................................................................12
1.3.2. Justificación Práctica ..................................................................................................12
1.3.3. Justificación metodológica..........................................................................................13
1.4. Objetivos de la investigación. .............................................................................................13
1.4.1. Objetivo general ..........................................................................................................13
1.4.2. Objetivos específicos. ..................................................................................................13
II. MARCO TEÓRICO ....................................................................................................... 14
2.1. Antecedentes de la investigación. .......................................................................................14
2.1.1. Antecedentes internacionales .....................................................................................14
2.1.2. Antecedentes nacionales .............................................................................................16
2.2. Bases Teóricas .....................................................................................................................18
2.2.1. Fundamentos de la variable “Mejoras de Seguridad de Aplicaciones Web”.........18
2.2.2. Fundamentos de la variable “Metodología de OWASP”.........................................23
2.3. Marco conceptual ................................................................................................................38
III. FORMULACIÓN DE LA HIPÓTESIS ....................................................................... 40
3.1. Hipótesis general .................................................................................................................40
3.2. Hipótesis específicas ............................................................................................................40
3.3. Variables ..............................................................................................................................40
3.3.1. Identificación de variables..........................................................................................40
3.3.2. Operacionalización de variables ................................................................................41
IV. DISEÑO DE LA INVESTIGACIÓN ............................................................................ 43
4.1. Tipo de Investigación ..........................................................................................................43
4.2. Diseño de la Investigación ..................................................................................................43
4.3. Población y Muestra ...........................................................................................................43
V
4.3.1. Población ......................................................................................................................43

4.3.2. Muestra ........................................................................................................................43
4.4. Técnicas e instrumentos de recolección de datos..............................................................48
4.5. Técnicas de procesamiento y análisis de datos .................................................................48
4.5.1. Nivel de Impacto..........................................................................................................48
4.5.2. Nivel de Posibilidad.....................................................................................................51
4.5.3. Nivel de Riesgo ............................................................................................................54
V. ANALISIS E INTERPRETACION DE RESULTADOS ........................................... 56
5.1. Presentación de Resultados ................................................................................................56
5.2. Contrastación de Hipótesis .................................................................................................69
5.2.1. Hipótesis general .........................................................................................................69
5.2.2. Hipótesis específicas ....................................................................................................70
5.3. Discusión de Resultados......................................................................................................71
VI. CONCLUSIONES Y RECOMENDACIONES ........................................................... 72
6.1. Conclusiones ........................................................................................................................72
6.2. Recomendaciones ................................................................................................................73
REFERENCIAS BIBLIOGRÁFICAS ................................................................................. 75
ANEXOS ................................................................................................................................. 80
VI
ÍNDICE DE TABLAS
Tabla 1. Ranking de países amenazados / países satisfactoriamente atacados. ......................... 4

Tabla 2. Investigaciones según fases de desarrollo de software .............................................. 16
Tabla 3. Operacionalización de variable “X” .......................................................................... 41
Tabla 4. Operacionalización de variable “Y” .......................................................................... 42
Tabla 5. Frecuencias de la muestra de estudio: Instituciones educativas atacadas por año ..... 44
Tabla 6. Frecuencias de la muestra de estudio: Métodos de ataques registrados .................... 45
Tabla 7. Frecuencias de la muestra de estudio: Vulnerabilidades explotadas registradas ....... 46
Tabla 8. Frecuencias de la muestra de estudio: Impactos registrados...................................... 47
Tabla 9. Impacto Técnico ........................................................................................................ 49
Tabla 10. Impacto Empresarial ................................................................................................ 50
Tabla 11. Posibilidad – Factor Agente de Amenaza ................................................................ 52
Tabla 12. Posibilidad – Factor Vulnerabilidad ........................................................................ 53
Tabla 13. Comparación de Niveles de Riesgo antes y después de aplicar las recomendaciones
y controles OWASP ................................................................................................................. 56
Tabla 14. Clasificación OWASP de los ataques estudiados .................................................... 62
VII
ÍNDICE DE FIGURAS
Figura 1. Exposición de Perú ..................................................................................................... 3

Figura 2. Compromisos por tipo de dato objetivo. .................................................................... 5
Figura 3. Métodos de compromiso ............................................................................................ 6
Figura 4. Top de ataques web .................................................................................................... 6
Figura 5. Rubros objetivos de amenazas automatizadas ............................................................ 8
Figura 6. Clasificación de los incidentes cibernéticos según motivo, método y objetivo por
rubro ........................................................................................................................................... 9
Figura 7. Objetivos de Ataques a las instituciones educativas 2017 ....................................... 10
Figura 8. Objetivos de Ataques a las instituciones educativas primer trimestre de 2018 ........ 11
Figura 9. Frecuencia de la muestra de estudio: Instituciones educativas atacadas por año. .... 44
Figura 10. Frecuencia de la muestra de estudio: Métodos de ataques registrados................... 45
Figura 11. Frecuencia de la muestra de estudio: Vulnerabilidades explotadas registradas ..... 46
Figura 12. Frecuencia de la muestra de estudio: Impacto registrados ..................................... 47
Figura 13. Nivel de Riesgo ...................................................................................................... 54
Figura 14. Comparación de Niveles de Riesgos ...................................................................... 61
1
INTRODUCCIÓN
En los últimos años se ha visto que lo concerniente a ciberseguridad y cibercrímenes
han ganado notoriedad. Es así que encontramos ejemplos como el bien conocido WannaCry
el cual en el año 2017 generó muchas pérdidas tanto monetarias como de información,
infectando más de 300.000 ordenadores en más de 180 países usando una vulnerabilidad
conocida pero la cual no había sido correctamente parchada (Frieiro, Pérez & Pascual, 2017).
Otro ejemplo de gran notoriedad es el ransomware conocido como Petya, el cual aprovechó
un malware del mismo nombre para impedir el arranque de las computadoras.
Luego de conocer los ejemplos anteriores nos damos cuenta que, adicional a la calidad
y utilidad de las aplicaciones web, es necesario que los desarrolladores presten especial
atención a la seguridad de las mismas. Debido a ello es que día a día los oficiales de
seguridad de las empresas, así como también los profesionales de seguridad, están en la
continua búsqueda de controles, vulnerabilidades y tipos de ataques.
Se han encontrado casos en los que una vulnerabilidad, cuya solución ha sido
publicada varios meses atrás por organizaciones de seguridad, ha comprometido varias
instituciones entre los que están instituciones educativas (BBC, 2017), así como también gran
cantidad de dinero involucrado. Un mecanismo de seguridad que ayude a proteger a estas
instituciones educativas basadas en recomendaciones permitiría proteger los activos de
información de estas instituciones.

2
I. EL PROBLEMA DE LA INVESTIGACIÓN
1.1. Descripción de la realidad del problema.
Es de conocimiento general que una de las amenazas que avanza a la misma velocidad
que las innovaciones es el cibercrimen, pero ¿Sabemos que tan expuesto está el Perú en
relación a los demás países?
Según el informe del Banco Interamericano de Desarrollo, Ciberseguridad ¿Estamos
preparados en América Latina y el Caribe? (BID, 2016):
La ausencia de una estrategia y una cadena de mando clara continúan impidiendo el
fortalecimiento de la seguridad cibernética del país. Las fuerzas armadas también
tienen un nivel básico de capacidad de defensa cibernética, pero no existe una política
de defensa cibernética. Entre los constantes desafíos que se enfrentan, cabe citar su
limitada capacidad técnica para el manejo de evidencia electrónica en los tribunales y
la falta de una política de divulgación para el sector privado. Mientras que los
servicios de gobierno electrónico y comercio electrónico continúan expandiéndose en
el Perú, la conciencia social de la seguridad cibernética es generalmente baja. (BID,
2016: p. 94)
Debido a lo anterior, y adicionando que cada vez somos un país con más dispositivos
conectados y por ende con más información sensible, hace que el Perú sea un país muy
expuesto.
3
Revisando el último informe National Exposure Index (Rapid7, 2017), el Perú se
encuentra en el puesto 29 en nivel de exposición a nivel mundial.
Figura 1. Exposición de Perú

Fuente: National Exposure Index, Rapid7, 2017.
A su vez, un informe realizado por la empresa FireEye, Regional Advanced Threat
Report: Latin America 1H 2015 (FireEye, 2015), indica que el Perú es el cuarto país objetivo
de Latinoamérica que genera alertas de software malicioso o exploits. Así mismo, indica que
Perú es el segundo país objetivo que fue víctima de ataques exitosos. Según FireEye (2015),
Perú genera menos alertas de seguridad que Chile, pero Chile logra frenar más eficientemente
los ataques, llegando estos a no concretarse. FireEye (2015) cierra la explicación indicando:
Esta discrepancia refleja que ser más amenazado no necesariamente desemboca en ser
comprometido satisfactoriamente y que las prácticas de seguridad de Chile puede ser
más efectivas de lo que aparentan. (FireEye, 2015, p. 4)

4
Tabla 1.
Ranking de países amenazados / países satisfactoriamente atacados.
Posición Países Amenazados Países Satisfactoriamente Atacados
1 Brasil Brasil
2 Chile Perú
3 México México
4 Perú Chile
5 Argentina Argentina
Nota. Datos obtenidos de FireEye. (2015). Regional Advanced Threat Report: Latin America
1H 2015
Adicionalmente tenemos que tomar en cuenta los diferentes objetivos de los
cibercrímenes. Según el último reporte de Trustwave, 2018 Trustwave Global Security Report
(Trustwave, 2018), indica:
Los atacantes apuntan a la información confidencial de tarjetas de pago en la mayoría
de los incidentes, comprometiendo la seguridad de las bandas magnéticas de las
tarjetas en un 23% de incidentes, y comprometiendo la información de tarjetas no
presentes (Card not present, CNP), que es mayormente usado en transacciones de
comercio electrónico, en el 20%. Esto es un declive significativo en comparación con
el 2016, cuando los atacantes apuntaron a información de tarjetas en 2 de cada 3
incidentes. Sin embargo, al mismo tiempo, ha habido un aumento en los incidentes
que involucran dinero (11%), principalmente debido a brechas existentes en las
transacciones realizadas en cajeros automáticos fraudulentos, los que están presentes
debido a sistemas vulnerables de gestión de cuentas en las entidades financieras.
(Trustwave, 2018, p. 30)

5
Por otro lado, en la Figura 2 Trustwave describe otros objetivos de los atacantes que
están causando en las organizaciones.
Figura 2. Compromisos por tipo de dato objetivo.

Fuente: 2018 Trustwave Global Security Report, Trustwave, 2018.
Hay que tener en cuenta que para que los ataques sean exitosos, debe existir una
forma de comprometer los sistemas. Al respecto Trustwave (2018) indica que, entre varios
otros métodos de compromiso, uno que ha logrado persistir es el ataque conocido como
Inyección de Código. Obviamente este método no es el único que existe, pero si uno de los
que se encuentra presente en varios de los ambientes conocidos; tal como podemos observar
en la Figura 3.
6
Figura 3. Métodos de compromiso

Una vez entendido lo descrito en la Figura 3, se observa que varios de los métodos de
compromiso están dirigidos a las aplicaciones web, En la Figura 4 se puede observar los
ataques más comunes hacia estas aplicaciones web.
Figura 4. Top de ataques web

7
Tanto la Figura 3 como la Figura 4 indican que los ataques por inyección de código
(XSS, SQLi) son los más comunes hacia las aplicaciones web.
Una vez entendido que uno de los problemas de seguridad más grandes para toda
empresa o institución es asegurar sus aplicaciones web, debemos enfocarnos en saber a qué
rubro pertenecen las entidades más afectadas a lo largo de los años. Para ello, Watson y Zaw
(2018) nos presenta en el “OWASP Automated Threat Handbook – Web Applications” 21
amenazas automatizadas, las cuales tienen los siguientes rubros objetivos:

8
Sector Objetivo
Evento de Amenaza Automatizado Educación Entretenimiento Financiero Gobierno Salud Retail Tecnología Redes sociales
OAT-001 Carding X X
OAT-002 Token Cracking X X X
OAT-003 Ad Fraud X X X X X X
OAT-004 Fingerprinting X X X X X X X X
OAT-005 Scalping X X X
OAT-006 Expediting X X X X X
OAT-007 Credential Cracking X X X X X X X X
OAT-008 Credential Stuffing X X X X X
OAT-009 CAPTCHA Defeat X X X X X X
OAT-010 Card Cracking X
OAT-011 Scraping X X X X X X X X
OAT-012 Cashing Out X X X
OAT-013 Sniping X X X
OAT-014 Vulnerability Scanning X X X X X X X X
OAT-015 Denial of Service X X X X X X
OAT-016 Skewing X X X X X X X X
OAT-017 Spamming X X X
OAT-018 Footprinting X X X X X X X X
OAT-019 Account Creation X X X X X
OAT-020 Account Agregation X X X
OAT-021 Denial of Inventory X X X X X X X
TOTAL 9 19 18 13 8 19 9 14
Figura 5. Rubros objetivos de amenazas automatizadas

Fuente: Elaboración propia / Datos obtenidos de OWASP Automated Threat Handbook – Web Applications, 2018.
9
Así mismo, Positive Technologies (2018) nos indica la cantidad de ataques reportados
según sector en el primer trimestre del 2018:
Figura 6. Clasificación de los incidentes cibernéticos según motivo, método y objetivo por
rubro
Fuente: Cybersecurity threatscape Q1 2018, 2018.
10
Debido al público al que está dirigido la investigación, el presente trabajo se centrará
en el rubro educativo. Luego de revisar las imágenes anteriores, tanto OWASP como Positive
Technologies coinciden en que el rubro de la educación es uno de los más atacados, ya que
OWASP (2018) lo coloca como el sexto puesto en rubros más afectados según el Automated
Threat Handbook. Así mismo, Positive Technologies (2018) lo coloca como sexto puesto en
rubros más afectados según el Cybersecurity Threatscape Q1 2018, según se observa en la
Figura 6.
Así mismo, Positive Technologies (2018) nos brinda los objetivos de los ataques que
han sufrido las instituciones en el rubro educativo, los cuales corresponden al 2017 y al
primer trimestre del 2018.
Figura 7. Objetivos de Ataques a las instituciones educativas 2017

Fuente: Cybersecurity Threatscape 2017: Trends and Forecasts, 2018.
11
Figura 8. Objetivos de Ataques a las instituciones educativas primer trimestre de 2018

Fuente: Cybersecurity Threatscape Q1 2018, 2018.
Revisando ambas figuras, nos damos cuentas que el porcentaje que ahora representa
los ataques a recursos web en instituciones educativas han aumentado. Dándonos una idea
acerca de la tendencia por explotar vulnerabilidades en ellas.
1.2. Definición del problema.
1.2.1. Problema general.
¿En qué medida las recomendaciones técnicas de OWASP reducen el nivel de riesgo
de las aplicaciones web de las instituciones educativas?
1.2.2. Problemas específicos.
 ¿Cuáles son los ataques más comunes reportados hacia las instituciones del
sector educativo?
12
 ¿Cuáles son las vulnerabilidades que los atacantes más explotan para
comprometer las aplicaciones web de las instituciones del sector educativo?
 ¿Cómo se puede poner en práctica la metodología de OWASP para identificar
riesgos y poder tomar una decisión para su mitigación?
1.3. Justificación e importancia de la investigación.
1.3.1. Justificación Teórica
En lo teórico, la investigación ha permitido indagar la información más actualizada y
disponible acerca de las buenas prácticas al momento de desarrollar e implementar una
aplicación web, así como también de los riesgos y amenazas a los que se encuentran más
expuesto, a fin de mejorar la seguridad en las mismas.
1.3.2. Justificación Práctica
En lo práctico, la investigación va a hacer posible que en posteriores trabajos
relacionados a las aplicaciones web, seguridad de las mismas y recomendaciones de un
organismo como OWASP; se tenga un referente sobre cómo aplicar las recomendaciones, así
como también cómo ejecutar análisis de riesgos para las aplicaciones web en general.
13
1.3.3. Justificación metodológica
En lo metodológico, la investigación va a servir como orientación a otros tesistas
acerca de los pasos del método analítico y su aplicación en la elaboración de documentos
investigativos.
1.4. Objetivos de la investigación.
1.4.1. Objetivo general.
Evaluar en qué medida las recomendaciones técnicas de OWASP reducen el nivel de
riesgo de las aplicaciones web de las instituciones educativas.
1.4.2. Objetivos específicos.
 Determinar los ataques más comunes reportados hacia las instituciones del
sector educativo.
 Identificar las vulnerabilidades que los atacantes más explotan para
comprometer las aplicaciones web de las instituciones del sector educativo.
 Poner en práctica el uso de la metodología de OWASP para identificar
correctamente los riesgos a los que está expuesto una aplicación web y poder tomar una
decisión para su mitigación.

14
II. MARCO TEÓRICO
2.1. Antecedentes de la investigación.
2.1.1. Antecedentes internacionales
a. End-to-end Web Application Security (Seguridad de aplicaciones web de extremo a
extremo)
La seguridad de las aplicaciones web es un asunto de vital importancia para la
operación de toda empresa o entidad que usa las páginas web como medio para comunicarse
con sus clientes o usuarios. Así mismo, según Erlingsson, Livshits y Xie (2007), es necesario
que la seguridad de las aplicaciones web no solo sea compromiso del desarrollador en el
servidor de aplicaciones web; sino que debe ser una colaboración entre cliente y servidor la
que llegue a alcanzar los objetivos de seguridad de las aplicaciones.
Así mismo, se indica que las reglas para un correcto filtrado de scripts o una correcta
detección de intentos de ataques debe ser apoyada por un mecanismo adicional a las políticas
de la aplicación web, la cual es formulada por los autores: Mutation-Event Transforms, o
METs. Estos permiten que las políticas de seguridad de la aplicación sean especificadas en
formato de programación, los cuales facilitan el uso directo de las mismas por parte del
cliente. (Erlingsson et al., 2007)
De la lectura anterior, se puede rescatar un principio que en la actualidad se debe tener
muy en cuenta: la seguridad en las aplicaciones web es un esfuerzo conjunto de todos los
involucrados.
15
b. Web Application Security Vulnerabilities Detection Approaches: a Systematic
Mapping Study (Enfoques de detección de vulnerabilidades de seguridad de
aplicaciones web: un estudio sistemático de mapeo)
Este trabajo aborda la pregunta acerca de la cantidad de trabajos de investigación
existen sobre seguridad de aplicaciones web. En ella; Rafique, Humayun, Hamid, Abbas,
Akhtar e Iqbal (2015) sintetizan el trabajo existente para conocer el estado de la investigación
de aplicaciones web, buscando identificar la solidez y calidad de las soluciones propuestas
encontradas.
Así mismo, Rafique et al. (2015) se basó en las siguientes preguntas de investigación:
 ¿Qué soluciones de seguridad de aplicaciones web se han propuesto para el
desarrollo de sistemas de software?
 ¿Podemos categorizar estas soluciones usando OWASP Top 10?
De lo anterior, podemos darnos cuenta que el enfoque de ambas preguntas ayuda a los
objetivos de la presente investigación, así como también nos brinda un punto de partida del
cual podemos complementar y actualizar, ya que la investigación se basó en OWASP Top 10
del año 2010.
Otro punto importante, es que de todos los trabajos encontrados, la gran mayoría se
centra en la detección y remediación de vulnerabilidades durante las fases de implementación

16
y testeo de las aplicaciones Web; mientras que las fases de requerimiento, diseño y
mantenimiento muestran valores muy bajos (Ver Tabla 2). (Rafique et al., 2015).
Tabla 2.
Investigaciones según fases de desarrollo de software
Fases Porcentaje de Investigaciones
investigaciones
Requerimiento 7% 3
Diseño 17% 7
Implementación 66% 27
Testeo 51% 21
Mantenimiento 0% 0
Nota. Fuente: Adaptado de S. Rafique, M. Humayun, B. Hamid, A. Abbas, M. Akhtar, K.
Iqbal. (Junio de 2015). Web application security vulnerabilities detection approaches: A
systematic mapping study. 2015 IEEE/ACIS 16th Conferencia Internacional de Ingeniería de
Software de Redes de Inteligencia Artificial y Computación Distribuida / Paralela (SNPD) (p.
3)
2.1.2. Antecedentes nacionales
a. Subsistema de seguridad
En esta tesis, Valdivia y De la Barra (2015) indican el gran esfuerzo que supone para
las empresas el poder tener un sistema capaz de soportar todos sus procesos de negocio, pero
que casi siempre olvidan un detalle: la seguridad, indicando además que un ambiente seguro
abarca muchos tópicos y que no sólo se limita al uso de credenciales para autenticar usuarios.
En efecto, a menudo se suele pensar que con el uso de credenciales la información ya
está segura y fuera del alcance de los atacantes, sin embargo desconocen la mayoría de
vectores y formas de ataque que pueden ocurrir.

17
b. Implementación de un sistema de información para un Mype comercial con
componentes de libro y facturación electrónica
En esta tesis, Ordaya (2015) plantea la implementación de un sistema informático
para fines comerciales, el cual debido a su naturaleza debe estar correctamente asegurado.
Para ello, el autor usa las recomendaciones de OWASP como referente en términos de
seguridad, lo que garantizará que el sistema no sea un blanco fácil para los atacantes.
En cuanto al ámbito de seguridad, es bien conocido que OWASP es un referente en
aplicaciones web, por lo que sus recomendaciones y documentación son bastante usados para
desarrollos e implementaciones.
c. Análisis, diseño e implementación de un sistema para el control de la emisión
y consumo de vales basado en una arquitectura de servicios
En este trabajo, Flores (2018) propone e implementa un sistema de control
relacionado al uso de vales, los cuales deben tener un robusto sistema de seguridad para
evitar los fraudes, debido a ello, usan las recomendaciones de OWASP con tal de brindar la
robustez que requiere su sistema.
Del anterior trabajo se resalta, una vez más, la necesidad de las recomendaciones de
OWASP para poder garantizar la seguridad de las aplicaciones y de los activos que en ella se
manejan. No cabe duda del impacto e influencia que las recomendaciones OWASP tienen en
la industria de la seguridad de aplicaciones web.

18
2.2. Bases Teóricas.
2.2.1. Fundamentos de la variable “Mejoras de Seguridad de Aplicaciones Web”
A. Definición de la variable
Rafique et al. (2015) sostienen que las tecnologías de aplicaciones web proveen un
prometedor mecanismo de integración de múltiples componentes funcionales a través de
internet, permitiendo a usuarios y organizaciones interactuar entre ellos utilizando un interfaz
de aplicación aun cuando se encuentren separados por grandes distancias. Billones de
usuarios alrededor del mundo usan las aplicaciones web para obtener información, realizar
transacciones financieras, divertirse y comunicarse entre ellos.
Así mismo, se conoce como seguridad de la información a asegurar los activos-
recursos-procesos involucrados en el giro del negocio, es decir implementar políticas,
procesos, procedimientos, estructuras organizacionales y funciones de hardware y software
para minimizar el riesgo (Sangoluisa, 2015: p. 3).
Debido a que los objetivos de la seguridad de la información son la confidencialidad,
integridad y disponibilidad de la información (Sangoluisa, 2015: p. 3), se adecuarán dichos
objetivos a las aplicaciones web.
De ese modo, se define la variable “Mejoras en seguridad de aplicaciones web” como
aquellas medidas necesarias para mantener la confidencialidad, integridad y disponibilidad de
la información que es contenida por y enviada a través de aplicaciones web. De ese modo, las
dimensiones de esta variable serán Confidencialidad, integridad y disponibilidad.

19
B. Dimensionamiento de la variable
Las dimensiones de la variable son las siguientes:
a. Confidencialidad
Propiedad en la que la información no se encuentra disponible o divulgada para
personas, entidades o procesos no autorizados (ISO / IEC, 2018: pág. 2).
Así mismo, según Laybats y Tredinnick (2016) la confidencialidad se refiere a limitar
la disponibilidad de la información a personas o entidades no autorizadas, lo que evita que la
información caiga en manos de aquellos a los que se debe impedir el acceso.
b. Disponibilidad
Propiedad en la que la información es accesible y usable bajo demanda por entidades
autorizadas (ISO / IEC, 2018: pág. 2).
Así mismo, según Laybats y Tredinnick (2016) la disponibilidad es asegurar que la
información está disponible para los procesos en los que se requiera, y que los controles y
procesos de seguridad sean adecuados para el propósito.
c. Integridad
Propiedad en la que la información es precisa y completa (ISO / IEC, 2018: pág. 5).
20
Así mismo, según Laybats y Tredinnick (2016) la integridad se refiere con mantener
la recopilación de información precisa y completa a lo largo de su ciclo de vida, incluyendo
la gestión y auditoría de modificaciones en los datos o recopilación de datos.
C. Criterios de calidad de Aplicaciones Web
Teniendo en cuenta la cantidad de usos que se les puede dar a las aplicaciones web, es
necesario que éstas tengan algunas características que aseguren la calidad de la aplicación. Es
por ello que Offut (2002) determina 7 criterios para determinar la calidad de una aplicación
web:
a. Confiabilidad
Los usuarios de aplicaciones web esperan que éstas funcionen con la misma
confiabilidad como si fuesen a la tienda, banco o institución. En caso las aplicaciones web no
funcionen bien, los usuarios pueden dirigirse a otra tienda, banco o institución simplemente
ingresando a otras URL, suponiendo grandes pérdidas de dinero (Offut, 2002: pág. 5).
Considerando lo anterior, podemos suponer que este criterio de calidad está
directamente relacionado con los principios de seguridad de la información, ya que una
aplicación web no confiable podría suponer el no cumplimiento de la disponibilidad,
integridad y confidencialidad de la información almacenada en ella.
b. Usabilidad
21
Al ser una gran cantidad los usuarios que usan las aplicaciones web, ellos esperan que
estas aplicaciones sean fáciles de usar y / o cuenten con un entorno amigable. En caso de no
diseñar una aplicación web de esta manera, sumado a la mínima lealtad a los sitios web por
parte de los usuarios, supondrá la pérdida de gran cantidad de usuarios (Offut, 2002: pág: 5).
c. Seguridad
Debido a la gran cantidad de funciones que una aplicación web puede realizar, una
brecha de seguridad puede significar grandes pérdidas de ingresos, costos de reparaciones de
daños, consecuencias legales y pérdida de credibilidad ante los clientes. Es debido a esto, la
seguridad es esencial para las aplicaciones, sobre todo para aquellas que almacenan
información de usuarios o realizan transacciones bancarias (Offut, 2002: pág. 5).
Por obvias razones, este criterio es alrededor del cual girará la presente investigación.
Un fallo en este punto implicaría pérdidas millonarias e incluso la bancarrota.
d. Disponibilidad
Disponibilidad se entiende por estar operativo todos los días y por todos los
navegadores. Esto supone que las aplicaciones web no pidan algún complemento adicional
que importune a los usuarios (Offut, 2002: pág. 6).
e. Escalabilidad
22
Esto significa que la aplicación web debe estar preparada para crecer tanto en
números de usuarios que ingresan como en servicios que puede ofrecer (Offut, 2002: pág. 6).
Este criterio es de suma importancia para seguridad de la información, ya que en caso
fallase se incurre en el no cumplimiento del principio de disponibilidad. Algunos ejemplos de
fallos en este criterio terminan en un ataque DoS, haciendo que la aplicación no sea accesible.
f. Mantenibilidad
Este criterio es descrito como la necesidad que todo mantenimiento, actualización o
corrección pueda ser capaz de desplegarse en el menor tiempo posible, y sin usar recursos
adicionales para su ejecución (Offut, 2002: pág. 7).
Este criterio está relacionado con el principio de disponibilidad de seguridad de la
información, ya que durante el periodo de mantenimiento la aplicación no será accesible.
Adicionalmente, toda actualización debe de pasar ciertos filtros previos ya que podrían
significar brechas en las aplicaciones.
g. Oportuno
Por algunos puede no ser considerado muy importante, pero se debe saber que es igual
de crítico que los demás criterios. Este criterio supone que todo despliegue de aplicaciones
web debe tratarse siempre a tiempo y ser lo suficientemente novedoso para los usuarios
(Offut, 2002: pág. 7).

23
D. Amenazas a las aplicaciones Web.
Tradicionalmente, la seguridad en aplicaciones web se enfrenta a dos tipos de
atacantes: atacantes web y atacantes de red. Un atacante web controla al menos un servidor
que responde a cualquier solicitud HTTP (S) que se le envíe con contenido malicioso
arbitrario elegido por el atacante. Los atacantes de red amplían las capacidades de los
atacantes web con la capacidad de detectar e interceptar todo el tráfico enviado entre dos
extremos de red. Estos atacantes tienen la posibilidad de inspeccionar, falsificar y corromper
todo el tráfico HTTP enviado a la red, pero no pueden romper la criptografía. Aunque los
ataques de red son posiblemente más difíciles de llevar a cabo que los ataques web, pueden
tener consecuencias catastróficas ya que le otorgan al atacante control total sobre las páginas
web que usan HTTP (Calzavara, Bugliesi y Focardi, 2016: pág. 4).
En el presente trabajo se profundizan algunas de las amenazas y ataques hacia las
aplicaciones, los cuales serán explicados a medida que avance la investigación.
2.2.2. Fundamentos de la variable “Metodología de OWASP”
A. Definición de la variable
OWASP es una organización sin fines de lucro, enfocada en mejorar la seguridad de
software. Sus siglas en inglés son: Open Web Application Security Project; que significa
Proyecto Abierto de seguridad de aplicaciones web. Tiene como misión hacer que la
seguridad de software sea visible, de manera que organizaciones e individuos puedan tomar
24
decisiones informadas. La forma en que opera es como comunidad, brindado herramientas y
documentos de seguridad en aplicaciones (OWASP, 2018).
B. OWASP Top 10 – 2017 The Ten Most Critical Web Application Security
Risks.
El Top 10 de OWASP es un potente documento de concienciación para la seguridad de
las aplicaciones web. Representa un amplio consenso sobre los riesgos de seguridad más
críticos para las aplicaciones web. Los miembros del proyecto incluyen una variedad de
expertos en seguridad de todo el mundo que han compartido su experiencia para producir esta
lista (OWASP, 2018).
De lo anterior, entendemos que el proyecto de top 10 de OWASP no es un estándar
ni una norma. Por el contrario, se trata de la lista de los riesgos a los que las aplicaciones
web están más expuestos, luego de hacer una consulta a diversos profesionales. La lista se
actualiza cada cierto tiempo, basándose en los ataques/riesgos/amenazas que se reportaron
en los años anteriores, así como también de la “popularidad” que tienen algunos durante el
periodo.
Los riesgos que se encuentran en la lista son los siguientes:
a. A1:2017 Inyección
De acuerdo a OWASP (2017), las inyecciones ocurren cuando los datos que no son de
confianza se envían a un intérprete como parte de una consulta o comando; de manera que los
25
datos que envía el atacante puede engañar al intérprete para que ejecute comandos no
deseados o acceda a datos sin la debida autorización.
Para explicar la inyección, utilizaremos como ejemplo el siguiente:
 Se tiene la siguiente URL, en la que se considera el parámetro “id” como el
identificador de usuario:
http://example.com/app/account?id=12345
 Consideremos que dicha url, ejecuta el siguiente query:
SELECT * FROM accounts WHERE custID=’12345’
 Una inyección consideraría en ingresar algún dato malicioso en ese parámetro, de
tal manera de obtener/modificar/eliminar información.
http://example.com/app/account?id=’ or ‘1’=’1
 Reemplazando estos datos maliciosos en la consulta, el query resultante sería el
siguiente:
SELECT * FROM accounts WHERE custID=’’ or ‘1’=’1’

26
 Interpretando el query anterior, la BD nos mostraría información de la totalidad de
cuentas, con lo que el ataque de inyección habría sido exitoso.
El anterior fue un ejemplo en el que la obtención de datos por parte de la aplicación
usa SQL. Se debe tener en cuenta que la inyección no sólo ataca a este lenguaje para
consultas, sino también a otros como LDAP, SOAP, XPath y consultas basadas en REST.
b. A2:2017 Ruptura de autenticación
De acuerdo a OWASP (2017), a menudo las funciones de la aplicación relacionadas a
la autenticación y administración de sesión son implementadas de manera incorrecta,
permitiendo que se comprometan credenciales de usuarios, llaves o tokens de sesión, así
como también explotar otras fallas de implementación para asumir identidades de manera
temporal o permanente.
Para explicar mejor este riesgo, podemos brindar varios ejemplos de lo que un
atacante podría lograr:
 Atacante buscando acceder a algún sistema en el que se encuentre información
confidencial, así como también realizar operaciones simulando ser el usuario.
 Intento de cambio de contraseña de un usuario, para acceder a un sistema e
inyectar código malicioso.

27
Con los ejemplos anteriores, podemos observar que implicancias tiene el que una
aplicación web no autentique correctamente a un usuario, o que no mantenga un manejo de
sesiones adecuado.
Adicionalmente, es necesario entender el significado de algunos términos como
autenticación y manejo de sesión. De acuerdo a Keary et al. (2017), la autenticación es el
proceso en el que se verifica que un usuario, entidad u aplicación web es quien dice ser. Esto
se logra utilizando nombres de usuario o números de ID, junto con alguna información
privada que sólo el usuario conocería.
Referente al manejo de sesiones, es un proceso mediante el cual un servidor de
aplicaciones mantiene el estado de una entidad, el cual interactúa con el servidor (Keary et
al., 2017). Esto es necesario para que un servidor recuerde cómo reaccionar a solicitudes
posteriores a lo largo de una transacción. Las sesiones se mantienen en el servidor mediante
un identificador de sesión que se puede pasar de un lado a otro entre el cliente y el servidor al
transmitir y recibir solicitudes. Las sesiones deben ser únicas por usuario y
computacionalmente muy difíciles de predecir.
c. A3:2017 Exposición de información confidencial
De acuerdo a OWASP (2017), muchas aplicaciones web y APIs no protegen
adecuadamente la información confidencial (financiera, salud, información personal),
permitiendo que un atacante pueda sustraer la información y realizar delitos como fraude con
tarjetas de crédito, robo de identidad, entre otros.

28
Algunos ejemplos de los peligros que pueden significar la exposición de información
podrían ser:
 Un aplicativo que usa el algoritmo de encriptado por defecto de SQL para
“proteger” datos bancarios y almacenarlos en la base de datos, al momento de
realizarse un ataque por inyección SQL, la misma base de datos desencripta la
información y lo muestra en texto plano.
 La base de datos de credenciales usa hashes simples o sin una clave secreta
(conocida como salt) para almacenar credenciales. Un atacante podría obtener
la totalidad de la tabla y todas las credenciales podrían ser expuestas con una
tabla de hashes pre calculados.
d. A4:2017 Entidades Externas de XML
De acuerdo a OWASP (2017), muchos procesadores XML antiguos o mal configurados
evalúan referencias de entidades externas dentro de documentos XML. Así mismo, las
entidades externas se pueden utilizar para divulgar archivos internos utilizando el manejador
de archivos URI, recursos compartidos de archivos internos, escaneo de puertos interno,
ejecución remota de código y ataques de denegación de servicio.

29
El estándar XML 1.0 define la estructura de los archivos XML, en la se define un
concepto llamado entidad, que es una unidad de almacenamiento de cualquier tipo (Yergeau,
Sperberg-McQueen, Maler, Paoli y Bray, T., 2008).
Hay algunos tipos diferentes de entidades, en la que la entidad externa es aquella que
puede acceder a contenido local o remoto a través de un identificador declarado de sistema, el
cual es un URI que puede ser accedido por el procesador XML al procesar la entidad. El
procesador XML luego reemplaza las ocurrencias de la entidad externa nombrada con los
contenidos accedidos por el identificador del sistema. Si el identificador de sistema contiene
información contaminada y el procesador XML ingresa esta información, el procesador podría
divulgar información confidencial que normalmente no podría ser accedida por la aplicación
(OWASP, 2017).
e. A5:2017 Ruptura de control de acceso
De acuerdo a OWASP (2017), las restricciones sobre lo que los usuarios autenticados
pueden hacer a menudo no se aplican correctamente, permitiendo que los atacantes puedan
explotar estos defectos para acceder a funcionalidades y/o datos no autorizados, así como
acceder a cuenta de otros usuarios, ver archivos confidenciales, modificar datos de otros
usuarios, cambiar derechos de acceso, etc.
De acuerdo a MITRE (2018), el control de acceso implica el uso de varios
mecanismos de protección, tales como:
 Autenticación (probar la identidad)

30
 Autorización (asegurando que un usuario específico pueda acceder a un
recurso)
 Responsabilidad (rastreo de actividades que son realizadas)
Así mismo, MITRE (2018) indica que, si uno de los mecanismos no es aplicado o
fallase, los atacantes pueden comprometer la seguridad del software ganando privilegios,
leyendo información sensible, ejecutando comandos, evadiendo la detección, entre otros.
f. A6:2017 Errores en las configuraciones de seguridad.
De acuerdo a OWASP (2017), este es uno de los problemas más comunes en toda
aplicación, siendo el resultado de configuraciones predeterminadas no seguras,
configuraciones incompletas, almacenamiento en la nube, encabezados HTTP mal
configurados y mensajes de error detallados que contienen información confidencial; así
mismo se debe considerar los parchados y actualizaciones de manera oportuna.
Como se conoce, los atacantes tratarán de sacar provecho de los defectos sin parchar o
acceder a cuentas por defecto, directorios o archivos desprotegidos con tal de ganar acceso no
autorizado al sistema. Cabe mencionar que estos errores pueden suceder a cualquier nivel de
la estructura de la aplicación, incluyendo servicios de red, plataforma, servidores web,

31
servidores de aplicaciones, base de datos, marcos de trabajo, código y en máquinas virtuales
preinstaladas.
OWASP (2017) nos brinda algunos ejemplos en donde podemos observar por qué
estos errores son tan perjudiciales:
 El servidor de aplicaciones viene con algunas aplicaciones de ejemplo, las
cuales no han sido removidas del servidor de producción. Algunas de estas
aplicaciones tienen vulnerabilidades conocidas, las que los atacantes tratarán
de explotar con tal de ganar acceso. Si una de estas aplicaciones es la consola
de administrador, y las cuentas por defecto no fueron cambiadas, los atacantes
podrán acceder con credenciales por defecto y comprometer el servidor.
 El listado de directorios no está deshabilitado del servidor. Un atacante
descubre que puede enumerar los directorios, encontrando y descargando
archivos Java, los que descompila y aplica ingeniería inversa para obtener el
código. Con esto, el atacante puede encontrar una falla para lograr
comprometer la aplicación.
 La configuración del servidor permite mostrar mensajes de errores detallados.
Esto puede exponer información sensible o también información que puede
comprometer al servidor como la versión de algún componente, el cual es
conocido por tener algunas vulnerabilidades.

32
Como se pudo ver anteriormente, las configuraciones por defecto al ser de libre
conocimiento, significan un riesgo latente.
g. A7:2017 Cross-Site Scripting (XSS)
De acuerdo a OWASP (2017), las fallas XSS ocurren cuando una aplicación incluye
datos no confiables en una nueva página web sin la validación adecuada, o actualiza una
página web con datos proporcionados por el usuario usando una API de navegador que puede
crear HTML o Javascript. XSS permite a los atacantes ejecutar scripts en el navegador de la
víctima que pueden secuestrar sesiones de usuario, desfigurar sitios web o redirigir al usuario
a sitios maliciosos.
Los ataques XSS son un tipo de inyección, en el que scripts maliciosos son inyectados
en sitios web benignos. Estos ataques ocurren cuando un atacante usa una aplicación web
para enviar un código malicioso a otro usuario. Los fallos que normalmente permiten estos
ataques son bien conocidos y ocurre siempre y cuando una aplicación web utiliza la
información de un usuario dentro de la salida que genera, sin validarla ni codificarla. De esta
manera, un atacante envía scripts maliciosos a un usuario, cuyo navegador no tiene forma de
saber que el script no es verídico ya que este proviene de un servidor confiable, logrando
obtener cookies, tokens de sesión o cualquier otra información obtenida por el navegador y
usada por la página web (OWASP, 2018).
Existen 3 tipos de XSS:

33
 XSS Almacenado (Persistente o Tipo 1): Ocurre generalmente cuando la
entrada del usuario se almacena en el servidor de destino, como en una base de
datos, foro de mensajes, registro de visitantes, campo de comentarios, etc.
Luego, una víctima puede recuperar los datos almacenados de la aplicación
web sin que la información sea verificada y validada para ser
mostrado/ejecutado en el navegador. (Wichers et al., 2017)
 XSS Reflejado (No persistente o Tipo 2): Ocurre cuando la entrada del usuario
es devuelta inmediatamente por una aplicación web en un mensaje de error,
resultado de búsqueda o cualquier otra respuesta que incluye parte o la
totalidad de la entrada proporcionada por el usuario como parte de la solicitud,
sin que los datos sean seguros para procesar por el navegador y sin almacenar
permanentemente los datos proporcionados por el usuario. (Wichers et al.,
2017)
 XSS basado en DOM (Tipo 0): En este tipo, el flujo de datos contaminados
desde el origen hasta el receptor toma lugar en el navegador, es decir, el origen
de la información está en el DOM, el receptor está en el DOM y el flujo de
información nunca sale del navegador. Por ejemplo, la fuente (donde se leen
los datos maliciosos) podría ser la URL de la página (por ejemplo,
document.location.href), o podría ser un elemento del HTML, y el receptor es
una llamada al método confidencial que causa el ejecución de los datos
maliciosos (por ejemplo, document.write)”. (Wichers et al., 2017)

34
h. A8:2017 Deserialización insegura
De acuerdo a OWASP (2017), esta amenaza normalmente conduce a la ejecución
remota de código, así como también ataques de repetición, inyección y de escalamiento de
privilegios.
Dabirsiaghi y Hsu (2018) indican que la serialización es el proceso de convertir algún
objeto a un formato de datos específico, que puede ser restaurado más adelante. Este proceso
es comúnmente usado para almacenar objetos o enviarlos a través de algún medio. Entendido
este proceso, la deserialización es el proceso inverso.
Existen muchos formatos para serializar y deserializar objetos, así como también
muchos lenguajes que ofrecen una capacidad nativa para realizar este proceso.
Desafortunadamente, las características de estos mecanismos de deserialización nativa puede
reutilizarse para efectos maliciosos cuando se opera con datos que no son de confianza,
llegando a ser víctima de DoS, control de acceso o ejecución remota de código (Dabirsiaghi y
Hsu, 2018).
35
Este tipo de ataques sucede cuando los desarrolladores no ponen restricciones a las
“cadenas de gadgets”, o series de instancias e invocaciones de métodos que pueden auto
administrarse durante el proceso de deserialización (MITRE, 2018).
Un ejemplo de este tipo de ataque sería:
 Una aplicación React llama a un conjunto de micro servicios Spring Boot.
Siendo programadores funcionales, intentaron asegurar que su código sea
inmutable. La solución que se les ocurrió fue serializar el estado del usuario y
pasarlo de un lado a otro con cada solicitud. Un atacante nota la firma de
objeto Java "R00" y utiliza la herramienta Java Serial Killer para obtener la
ejecución remota de código en el servidor de aplicaciones.
i. A9:2017 Uso de componentes con vulnerabilidades conocidas.
De acuerdo a OWASP (2017), es conocido que los componentes como bibliotecas,
marcos y otros módulos de software se ejecutan con los mismos privilegios que la aplicación;
debido a ello si se explota algún componente vulnerable, el ataque podría conducir a una
pérdida grave de información o al compromiso del servidor. Las aplicaciones o APIs que
usan componentes con vulnerabilidades conocidas pueden debilitar las defensas de las
aplicaciones.
Un ejemplo podría ser el siguiente:

36
 CVE-2017-5638, una vulnerabilidad de ejecución remota de código de Struts
2 que permite la ejecución de código arbitrario en el servidor, ha sido
explotado logrando brechas significativas.
j. A10:2017 Registro y monitoreo insuficientes
De acuerdo a OWASP (2017), este problema junto con la falta o ineficaz integración
con algún procedimiento de respuestas de incidentes, permite a los atacantes persistir en el
ataque, afectando a más sistemas, lo que conduciría a la manipulación, extracción o
destrucción de información. La mayoría de estudios muestran que el tiempo de detección de
una violación de seguridad es mayor a 200 días, siendo normalmente detectados por terceros
y no por procedimientos internos.
C. OWASP Risk Rating Methodology
La metodología de calificación de riesgo de OWASP, es un modelo que sirve para
estimar lo más preciso posible el nivel de riesgo al que están expuestos los sistemas. Así
mismo, el modelo da unas pautas acerca de cómo calificar el nivel de probabilidad e impacto.
D. Dimensionamiento de la variable
a. Impacto
El impacto o consecuencia se refiere a la medida en que un evento de riesgo podría
afectar a una empresa (Curtis y Carey, 2012: pág. 3).

37
OWASP (2018) considera que para determinar el nivel de impacto en un análisis de
riesgo, es necesario considerar dos tipos de impacto: impacto técnico e impacto empresarial.
El impacto técnico tiene que ver con la aplicación, la información que utiliza y las funciones
que brinda. El impacto empresarial tiene que ver con el negocio, sus finanzas, reputación,
auditorías y privacidad.
b. Posibilidad
OWASP (2018) considera que la posibilidad es una medida aproximada de que un
atacante descubra y aproveche una vulnerabilidad. Así mismo, indica que hay una serie de
factores que apoyan a determinar el nivel de posibilidad los cuales son:
 Factor Agente de amenaza: Mediante este factor se estima la posibilidad de un
ataque exitoso de un grupo de potenciales atacantes. Se debe tener en cuenta
que pueden existir múltiples agentes de amenaza que pueden explotar una
vulnerabilidad en particular, por lo que se suele usar el peor de los casos.
 Factor Vulnerabilidad: Mediante este factor se estima la posibilidad que una
vulnerabilidad en particular sea descubierta y explotada.
c. Riesgo
38
El riesgo está asociado con el potencial en que las amenazas pueden explotar
vulnerabilidades de un activo o grupo de activos de información y de este modo causar daño
a la organización (ISO / IEC, 2018: pág. 8).
Luego de entendido lo anterior, OWASP (2018) indica que la manera de determinar el
nivel de riesgo es de la siguiente manera:
𝑁𝑁𝑁𝑁𝑁 𝑁𝑁 𝑁𝑁𝑁𝑁𝑁𝑁 = 𝑁𝑁𝑁𝑁𝑁 𝑁𝑁 𝑁𝑁𝑁𝑁𝑁𝑁𝑁 × 𝑁𝑁𝑁𝑁𝑁 𝑁𝑁 𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁
Como vemos en la ecuación, se debe realizar esta operación luego de determinar el
nivel de posibilidad y el nivel de impacto.
2.3. Marco conceptual
Amenaza: Potencial causa de un incidente no deseado, el cual puede resultar en un
daño para un sistema u organización (ISO / IEC, 2018: pág. 10).
API: Significa Interfaz de programación de aplicaciones (Application Programming
Interface, API). Una API es un conjunto de comandos, funciones, protocolos y objetos que
los programadores pueden usar para crear software o interactuar con un sistema externo.
Proporciona a los desarrolladores comandos estándar para realizar operaciones comunes para
que no tengan que escribir el código desde cero (Christensson, 2016).

39
Ataque: Intento de destruir, exponer, alterar, deshabilitar, sustraer u obtener acceso
no autorizado o hacer un uso no autorizado de los activos de una organización (ISO / IEC,
2018: pág. 1).
Control: Medida que modifica el riesgo. Incluye cualquier proceso, política,
dispositivo, práctica, o cualquier otra acción que modifica el riesgo (ISO / IEC, 2018: pág. 3).
Control de acceso: Significa garantizar que el acceso a los activos es autorizado y
restringido basado en los requerimientos de seguridad y del negocio (ISO / IEC, 2018:
pág. 1).
Vulnerabilidad: Debilidad de un activo o control que puede ser explotado por uno o
más amenazas (ISO / IEC, 2018: pág. 11).

40
III. FORMULACIÓN DE LA HIPÓTESIS
3.1. Hipótesis general
Mediante la aplicación de recomendaciones técnicas de OWASP sería posible mejorar
la seguridad en las aplicaciones web de instituciones del sector educativo.
3.2. Hipótesis específicas
 Sería posible determinar los ataques más comunes reportados hacia las
instituciones del sector educativo.
 Sería posible identificar las vulnerabilidades que los atacantes más explotan
para comprometer las aplicaciones web de las instituciones del sector educativo.
 Sería posible poner en práctica la metodología de OWASP para identificar
correctamente los riesgos a los que está expuesto una aplicación web y tomar una decisión
para su mitigación.
3.3. Variables
3.3.1. Identificación de variables.
Variable “X”: Mejoras de Seguridad de Aplicaciones Web.
Variable “Y”: Metodología de OWASP.

41
3.3.2. Operacionalización de variables.
Tabla 3.
Operacionalización de variable “X”
Dimensiones Indicadores Técnica / Instrumento / Rangos
I. Confidencialidad 1.1. Ataques cuyo impacto es divulgar información confidencial. Técnica:

1.2. Ataques cuyo impacto es obtener información confidencial. Nivel de Impacto / Análisis de riesgos
1.3. Ataques cuyo nivel de riesgo pueden suponer un mayor Instrumento:
problema para la confidencialidad. Nivel de Impacto utilizando la
metodología OWASP.
II. Disponibilidad 2.1. Ataques cuyo impacto es detener los procesos de la aplicación Rango:
web. - Nivel de Impacto: Catastrófico (5),
2.2. Ataques cuyo nivel de riesgo pueden suponer un mayor Crítico (4), Moderado (3), Menor (2),
problema para la disponibilidad. Inofensivo (1).
- Nivel de Riesgo: Bajo (1-3), Medio (4-9),
III. Integridad 3.1. Ataques cuyo impacto es modificar o eliminar la información. Alto (10-15), Crítico (16-25).
3.2. Ataques cuyo nivel de riesgo pueden suponer un mayor
problema para la integridad.
Nota. Fuente: Elaboración Propia.

42
Tabla 4.
Operacionalización de variable “Y”
Dimensiones Indicadores Técnica / Instrumento / Rangos
I. Impacto 1.1. Determinar el nivel de impacto técnico. Técnica:

1.2. Determinar el nivel de impacto empresarial. Nivel de Impacto / Nivel de Posibilidad /
Análisis de riesgos
Instrumento:
Nivel de Impacto / Nivel de Posibilidad
utilizando la metodología OWASP.
II. Posibilidad 2.1. Determinar el nivel de posibilidad del factor agente de amenaza. Rango:
2.2. Determinar el nivel de posibilidad del factor vulnerabilidad. - Nivel de Impacto: Catastrófico (5),
Crítico (4), Moderado (3), Menor (2),
Inofensivo (1).
- Nivel de Posibilidad: Muy posible (5),
Posible (4), Poco posible (3), Muy poco
III. Riesgo 3.1. Determinar el nivel de riesgo.
posible (2), Imposible (1).
- Nivel de Riesgo: Bajo (1-3), Medio (4-9),
Alto (10-15), Crítico (16-25).

43
IV. DISEÑO DE LA INVESTIGACIÓN
4.1. Tipo de Investigación
El tipo de investigación es uno de tipo explicativo, ya que se analizarán ataques
ocurridos anteriormente a instituciones educativas, de manera de ubicar las vulnerabilidades
que fueron explotadas y los tipos de ataques que se utilizaron.
4.2. Diseño de la Investigación
El presente es un estudio con diseño no experimental, correlacional ya que se
evaluarán las propuestas con escenarios pasados y se buscará la relación existente.
4.3. Población y Muestra
4.3.1. Población
Debido a la naturaleza de la investigación a realizar, la población en la que se basará
será el conjunto de aplicaciones web de las instituciones educativas.
4.3.2. Muestra
En el presente estudio, teniendo en cuenta que el diseño es no experimental,
correlacional, se trabaja con una muestra no probabilística, la cual no implica el uso de
ninguna fórmula estadística. Teniendo en cuenta los datos de ataques a aplicaciones web a
instituciones educativas listados en OWASP WASC Web Hacking Incidents Database Project,
se contarán con 27 casos de ataques a aplicaciones web entre 2010 y 2015. Se aplicarán
44
análisis de riesgos a las vulnerabilidades que fueron explotadas para que los ataques
reportados fueran exitosos, así como también se evaluarán contramedidas, controles y
recomendaciones técnicas.
Tabla 5.
Frecuencias de la muestra de estudio: Instituciones educativas atacadas por año
Cantidad de instituciones educativas

Año
atacadas por año
2010 2
2011 7
2012 8
2014 3
2015 7
Total general 27
Nota. Datos obtenidos de OWASP WASC Web Hacking Incidents Database Project, 2015
(Elaboración propia).
7%
26%
2010
26% 2011
2012
2014
11%
2015
30%
Figura 9. Frecuencia de la muestra de estudio: Instituciones educativas atacadas por año.

Fuente: Datos obtenidos de OWASP WASC Web Hacking Incidents Database Project, 2015
45
Tabla 6.
Frecuencias de la muestra de estudio: Métodos de ataques registrados
Método de Ataque Cantidad
Abuso de funcionalidad 2
Envenenamiento de motor de búsqueda 1
Fuerza Bruta 2
Inyección de Código 1
Inyección SQL 15
Inyección XSS 1
Robo de Credenciales 4
Spoofing de contenido 1
Total 27
Abuso de funcionalidad
Envenenamiento de motor de
4% 7% búsqueda
15% 4%
Fuerza Bruta
7%
4% 4% Inyección de Código
Inyección SQL
Inyección XSS
55% Robo de Credenciales
Spoofing de contenido
Figura 10. Frecuencia de la muestra de estudio: Métodos de ataques registrados

46
Tabla 7.
Frecuencias de la muestra de estudio: Vulnerabilidades explotadas registradas
Vulnerabilidad explotada Cantidad
Autenticación insuficiente 5
Configuración incorrecta de la aplicación 1
Indexación insegura 1
Insuficiente Anti-automatización 1
Manejo de entrada incorrecto 17
Manejo de salida incorrecto 1
Recuperación de contraseña insuficiente 1
Total 27
Autenticación insuficiente
Configuración incorrecta de
4%4% la aplicación
18%
Indexación insegura
3%
4% Insuficiente Anti-
4% automatización
Manejo de entrada
incorrecto
63%
Manejo de salida incorrecto
Recuperación de contraseña
insuficiente
Figura 11. Frecuencia de la muestra de estudio: Vulnerabilidades explotadas registradas

47
Tabla 8.
Frecuencias de la muestra de estudio: Impactos registrados
Impacto Cantidad
Adquisición de cuenta 1
Desfiguración 2
Desinformación 1
Perdida de reputación por enlace spam 1
Fraude 3
Fuga de información 17
Secuestro de sesión 1
Spam 1
Total 27
4% 4% 3% 7% Adquisición de cuenta
4%
Desfiguración
4%
Desinformación
Enlace spam
11%
Fraude
Fuga de información
Secuestro de sesión
63% Spam
Figura 12. Frecuencia de la muestra de estudio: Impacto registrados

48
4.4. Técnicas e instrumentos de recolección de datos
4.4.1. Técnica de determinación de nivel de impacto según la metodología OWASP.
4.4.2. Técnica de determinación de nivel de posibilidad según la metodología OWASP.
4.4.3. Técnica de determinación de nivel de riesgo según la metodología OWASP.
4.5. Técnicas de procesamiento y análisis de datos
Como se indicó, la investigación se realizará primero identificando el nivel de
impacto, posibilidad y riesgo que tuvieron las aplicaciones web de las instituciones
educativas, previo a los ataques reportados. Luego, basándonos en el tipo de ataque, se
clasificará el riesgo según el OWASP Top 10: The Ten Most Critical Web Application
Security Risks, a partir del cual se realizarán recomendaciones técnicas o controles para poder
mitigar el riesgo. Posteriormente, se evaluará el riesgo nuevamente teniendo en cuenta las
recomendaciones o controles implementados. Finalmente se compararán los niveles de riesgo
obtenidos.
4.5.1. Nivel de Impacto
Para el nivel de impacto, se tendrán en cuenta las definiciones de OWASP (OWASP
Risk Rating Methodology), en la cual los valores serán representados del 1 al 5 dependiendo
del nivel en que el impacto se encuentre. Como parte de la determinación de nivel de
impacto, se hará un promediado y redondeo de cada tipo de impacto para obtener el nivel de
impacto final. Se determinarán tanto impacto técnico como impacto empresarial.

49
Tabla 9.
Impacto Técnico
Impacto Técnico
Confidencialidad Integridad Disponibilidad Rastreabilidad

Nivel Puntaje (¿Cuánta información (¿Cuánta información (¿Cuánto servicio se puede (¿Los agentes de amenaza
comprometida? ¿Qué tan dañada? ¿En qué perder y que tan vital es?) son rastreables hasta
sensible es?) proporción?) llegar a un individuo?)
Totalidad de información Totalidad de información Totalidad de servicios Completamente anónimo.

Catastrófico 5
expuesta. totalmente dañada. interrumpidos.
Cantidad considerable de Cantidad considerable de Cantidad considerable de Posiblemente rastreable.
Crítico 4 información sensible información gravemente servicios primarios
expuesta. dañada. interrumpidos.
Cantidad considerable de Cantidad considerable de Cantidad considerable de -
Moderado 3 información no sensible información ligeramente servicios secundarios
Cantidad mínima de Cantidad mínima de Cantidad mínima de -
Menor 2 información sensible información gravemente servicios principales
Cantidad mínima de Cantidad mínima de Cantidad mínima de Completamente rastreable.
Inofensivo 1 información no sensible información ligeramente servicios secundarios
Nota. Fuente: Adaptación de OWASP Risk Rating Methodology

(https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology#Technical_Impact_Factors)
50
Tabla 10.
Impacto Empresarial
Impacto Empresarial
Daño Financiero Daño a la reputación Incumplimiento Violación de privacidad

Nivel Puntaje (¿Cuánto daño financiero (¿Un ataque exitoso (¿Cuánta exposición (¿Cuánta información
resultaría de un ataque resultaría en daños a la presenta el personal podría verse
exitoso?) reputación que dañaría el incumplimiento?) expuesta?)
negocio?)
Catastrófico 5 Bancarrota. Daño a la imagen corporativa. - Millones de personas.

Efecto significativo en el
Crítico 4 - Infracción escandalosa. Miles de personas.
balance anual.
Moderado 3 - Pérdida de buena voluntad. Infracción moderada. Cientos de personas.
Efecto mínimo en el balance

Menor 2 Pérdida de cuentas principales. Infracción menor. Un individuo.
anual.
Menos del costo para reparar
Inofensivo 1 Daño mínimo. - -
la vulnerabilidad.

51
4.5.2. Nivel de Posibilidad
Para el nivel de posibilidad, se tendrán en cuenta las definiciones de OWASP
(OWASP Risk Rating Methodology), en la cual los valores serán representados del 1 al 5
dependiendo del nivel en que la posibilidad se encuentre. Como parte de la determinación de
nivel de posibilidad, se hará un promediado y redondeo de cada tipo de posibilidad para
obtener el nivel de posibilidad final. Se determinarán tanto posibilidad del factor agente de
amenaza como posibilidad del factor vulnerabilidad.

52
Tabla 11.
Posibilidad – Factor Agente de Amenaza
Posibilidad – Factor Agente de Amenaza
Oportunidades
Motivación
Nivel de Habilidad (¿Qué recursos y Tamaño
Nivel Puntaje (¿Qué motiva a los agentes
(¿Qué tan habilidosos oportunidades se requieren (¿Qué tan grande es el
de amenaza a buscar y
técnicamente son los para que este grupo de agentes grupo de agentes de
explotar una
agentes de amenaza?) de amenazas encuentre y amenaza?)
vulnerabilidad?)
explote esta vulnerabilidad?)
Habilidades de
Usuarios anónimos de
Muy posible 5 penetración de Gran recompensa No requiere acceso o recursos.
internet.
seguridad.
Habilidades de
Requiere algunos accesos o Usuarios externos
Posible 4 networking y -
recursos. autenticados.
programación.
Poco Usuario avanzado de Requiere accesos o recursos Usuarios de intranet y

3 Recompensa posible.
posible computación. especiales. asociados.
Desarrolladores y/o
Muy poco Algunas habilidades
2 - - administradores de
posible técnicas.
sistemas.
Sin habilidades Requiere acceso total o recursos

Imposible 1 Baja o nula recompensa. -
técnicas. demasiado caros.

53
Tabla 12.
Posibilidad – Factor Vulnerabilidad
Posibilidad – Factor Vulnerabilidad
Facilidad de
Facilidad de explotación
descubrimiento Conocimiento Detección
Nivel Puntaje (¿Qué tan fácil es para este
(¿Qué tan fácil es para (¿Cuán conocida es esta ¿Cuán probable
grupo de agentes de
este grupo de agentes vulnerabilidad para el grupo es que se detecte
amenazas explotar esta
de amenazas descubrir de agentes de amenaza? un exploit?)
vulnerabilidad?)
esta vulnerabilidad?)
Herramientas
Herramientas automatizadas No se mantiene
Muy posible 5 automatizadas Conocimiento público.
disponibles. registro.
disponibles.
Se mantiene
Posible 4 Fácil. - Obvia. registro y no se
monitorea.
Poco
3 - Fácil Oculta. -
posible
Se mantiene un
Muy poco
2 Difícil. Difícil. - registro y se
posible
monitorea.
Prácticamente Detección activa
Imposible 1 Teórico. Desconocida.
imposible. en la aplicación.

54
4.5.3. Nivel de Riesgo
Para el nivel de riesgo, se tendrán en cuenta la metodología de OWASP (OWASP Risk
Rating Methodology), en la cual los valores serán representados del 1 al 25 obtenido de
multiplicar el nivel de impacto con el nivel de posibilidad.
Se utilizará la siguiente ecuación para obtener el nivel de riego:
Así mismo, nos basaremos en el siguiente cuadro para obtener el nivel de riesgo.
Figura 13. Nivel de Riesgo

Fuente: Elaboración Propia / Adaptación de OWASP Risk Rating Methodology, 2018.
De acuerdo al cuadro anterior, dependiendo del nivel de riesgo obtenido, se realizará lo
siguiente:
55
 Riesgo Bajo: Se acepta el nivel de riesgo.
 Riesgo Medio: Se acepta el nivel de riesgo.
 Riesgo Alto: Se requieren correcciones rápidas. Implementación no mayor a 1
mes.
 Riesgo Crítico: Se requieren correcciones inmediatas. Implementación no
mayor a 1 semana.
56
V. ANALISIS E INTERPRETACION DE RESULTADOS
5.1. Presentación de Resultados
Tal como se indicó, se realizó la estimación del nivel de riesgo antes y después de
proponer las recomendaciones técnicas, las cuales debido a la extensión de las mismas, el
detalle se encontrará en el anexo A. A continuación, presentaremos los niveles de riesgo
obtenidos:
Tabla 13.
Comparación de Niveles de Riesgo antes y después de aplicar las recomendaciones y
controles OWASP
Luego de aplicadas las
Previo a las recomendaciones /
recomendaciones / controles de % de
Ataque controles de OWASP
N° OWASP Reducci
realizado
Nivel de Nivel de Nivel de Nivel de Nivel de Nivel de ón
Impacto Posibilidad Riesgo Impacto Posibilidad Riesgo
WHID 2010-
203:
Confessed
1 3 5 15 3 2 6 60%
student
hacker
speaks
WHID 2011-
155: Hacker
2 4 5 20 4 2 8 60%
breaks into
MIT website
WHID 2011-
7: Hacker
Breaks Into
3 4 5 20 4 2 8 60%
UConn
Husky Store
Website
57
WHID 2011-
84:Hackers
access
4 personal info 4 5 20 4 2 8 60%
of Lancaster
County
students
WHID 2012-
377: Hackers
deface old
5 4 5 20 4 2 8 60%
UTS system,
dump user
database
WHID 2012-
382:
GhostShell
6 4 5 20 4 2 8 60%
university
hack: By the
numbers
WHID 2012-
63:
7 Singapore 3 4 12 3 2 6 50%
University
hacked
WHID 2014-
034: Hacker
attempts to
8 hold Johns 3 4 12 3 2 6 50%
Hopkins
hostage using
student data
WHID 2015-
008:
9 Universities 4 4 16 4 2 8 50%
hacked, data
dumped
WHID 2015-
013: U. of
Hawaii and
10 3 4 12 3 2 6 50%
Cornell
University
hacked
58
WHID 2015-
025: Hacker
breached
Metropolitan
11 4 5 20 4 2 8 60%
State
University
database with
personal info
WHID 2015-
030:
philsacra.ust.
12 4 4 16 4 2 8 50%
edu.ph
website
hacked
WHID 2015-
035: U.
13 4 4 16 4 2 8 50%
Chicago
hacked
WHID 2015-
041: Victor
Valley
14 College hit 3 4 12 3 2 6 50%
by computer
security
breach
WHID 2015-
042: Higher
Education
15 4 4 16 4 2 8 50%
Commission
Pakistan
Hacked
WHID 2011-
238: US uni
16 3 5 15 3 2 6 60%
warned, then
hacked
WHID 2012-
155: Hackers
17 Elect 3 5 15 3 2 6 60%
Futurama's
Bender to the
Washington
59
DC School
Board
WHID 2011-
94: High
school
hackers
18 expose 3 4 12 3 2 6 50%
security gap
in Seattle
Public
Schools
WHID 2012-
113: Students
busted for
19 hacking 3 4 12 3 2 6 50%
computers,
changing
grades
WHID 2012-
298:
Pennsylvania
mom
allegedly
20 3 4 12 3 2 6 50%
hacked
school
website to
change kids'
grades
WHID 2014-
028: U-Md.
computer
security
21 4 4 16 4 2 8 50%
attack
exposes
300,000
records
60
WHID 2014-
017: School
District Still
Using
Default
Login For
22 4 4 16 4 2 8 50%
Admin
Account
Surprised To
Learn Its Site
Has Been
Hacked
WHID 2010-
103: SEO
SPAM
23 network - 2 5 10 2 2 4 60%
Details of the
wp-includes
infection
WHID 2012-
257: UMass
website
hacked,
24 2 5 10 2 2 4 60%
Google
searchers get
offer to sell
Viagra
WHID 2011-
229: Yale
Social
Security
25 Numbers 4 4 16 4 2 8 50%
Exposed In
Latest Case
Of 'Google
Hacking'
WHID 2011-
20: Hackers
Get Access
26 4 5 20 4 2 8 60%
to New
Jersey School
Data System
61
WHID 2012-
299: Hackers
breached
password
27 security to 3 4 12 3 2 6 50%
steal UEA
climate
change
emails
Como vemos en la tabla 13, los niveles de riesgo que significaba la vulnerabilidad
encontrada en conjunto con el impacto del ataque, nos daba niveles de riesgo comprendidos
entre alto y crítico. Dichos niveles de riesgo pasaban a ser aceptables (nivel medio o bajo)
luego de ser aplicadas las recomendaciones y controles propuestos por OWASP. En la Figura
14, se observa la comparación de niveles de riesgo antes del ataque y después de implementar
las recomendaciones y controles.
Comparación de Niveles de Riesgos

25
20
15
10
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
N. Riesgo Previo N. Riesgo Posterior
Figura 14. Comparación de Niveles de Riesgos

Fuente: Elaboración Propia
62
Así mismo, se observa que el nivel de riesgo se ve reducido entre un 50% y 60% en
algunos casos. Revisando la clasificación OWASP en las que recaen los riesgos de los
ataques presentados, tenemos las siguientes cantidades identificadas:
Tabla 14.
Clasificación OWASP de los ataques estudiados
Cantidad de
Clasificación OWASP
Ataques
A1:2017 Inyección 17
A2:2017 Ruptura de autenticación 7
A3:2017 Exposición de información confidencial 17
A4:2017 Entidades Externas de XML 0
A5:2017 Ruptura de control de acceso 2
A6:2017 Errores en las configuraciones de seguridad 10
A7:2017 Cross-Site Scripting (XSS) 2
A8:2017 Deserialización insegura 0
A9:2017 Uso de componentes con vulnerabilidades
1
conocidas
A10:2017 Registro y monitoreo insuficientes 27
Nota. Fuente: Elaboración propia.
Como vemos en la tabla 14, notamos que un punto en el que todas las empresas
siempre deben mejorar y por las que un ataque puede hacer mucho daño es el “Registro y
monitoreo insuficientes”, el cual puede afectar el tiempo en que un atacante puede
permanecer en la aplicación o en el sistema.
Luego de ello, notamos que los siguientes riesgos más comunes son “Inyección” y
“Exposición de información confidencial”. Posteriormente, encontramos que “Errores en las
configuraciones de seguridad” también representan un gran riesgo para las aplicaciones.

63
Debido a lo anterior, presentaremos una compilación de recomendaciones y controles
OWASP, los cuales ayudarán a cualquier aplicación a mantener un nivel de riesgo tolerable.
 Realizar validaciones de entradas de datos en el servidor, utilizando "listas blancas".
De todos modos, esto no es una defensa completa ya que muchas aplicaciones
requieren el uso de caracteres especiales, como en campos de texto, APIs o
aplicaciones móviles.
 Uso de herramientas automatizadas de revisión de código y detección de fallas de
inyección, de manera que se identifiquen nuevas fallas antes de implementar un nuevo
aplicativo en producción.
 Configurar los permisos de la aplicación correctamente, basándonos en roles con
funciones y permisos bien definidos.
 Realizar auditorías a las configuraciones de las aplicaciones, servidores, etc. en todos
los ambientes de manera periódica, con el objetivo de encontrar cualquier
configuración insegura.
 Una arquitectura de aplicaciones segmentadas que proporciona una separación
efectiva y segura entre los componentes.
 Cada vez que se realice un cambio o actualización en el sistema, este debe ser
probado y escaneado en los ambientes de desarrollo y pruebas, de manera que se

64
puedan identificar errores en configuraciones antes de su implementación en
producción.
 Encriptar toda información sensible. Use una sal específica de credencial
criptográficamente fuerte.
 Garantizar que los algoritmos, protocolos y claves estén actualizados y se guíen de un
estándar potente.
 Almacenar contraseñas usando fuertes funciones de hash adaptativas y saladas con un
factor de trabajo (factor de retardo), como Argon2, scrypt, bcrypt o PBKDF2. Esto es
la segunda línea de defensa en caso los controles de acceso no funcionen
correctamente.
 No almacenar información sensible de no ser necesario. También, se puede descartar
la información ni bien se termine de utilizar. La información que no es retenida no
puede ser comprometida.
 Prevenir el uso de nombres de usuario y contraseñas por defecto, realizando
revisiones de código y escaneos de vulnerabilidades previos a desplegar en
producción.
 Implementar múltiples factores de autenticación para prevenir ataques automatizados.

65
 Implementar revisiones de debilidad de contraseñas, de manera que se determinen
longitud, complejidad y tipo de caracteres; así como también políticas de contraseñas.
Buenas medidas y políticas podrían ser:
 Longitud: Desde 8 hasta 64 caracteres.
 Tener una lista de contraseñas de diccionario e implicadas en brechas
anteriores, de manera que se verifique que las contraseñas no deberían estar en
esta lista.
Así mismo se propone algunas políticas adicionales:
 Contraseña debe cumplir con al menos 3 de 4 condiciones: 1 letra mayúscula,
minúscula, número y carácter especial (incluido el espacio).
 No más de dos caracteres idénticos seguidos.
 Identificar los dispositivos para autenticación, de manera que mediante aplicación de
reglas un correlacionador de eventos podría encontrar intentos fallidos de dispositivos
no conocidos o de lugares no usuales.
 Restringir la cantidad de intentos fallidos de autenticación, luego de los cuales la
cuenta debería ser bloqueada temporalmente. La cantidad de intentos puede ser
definida por cada equipo de TI. El tiempo de bloqueo no debería exceder los 15
minutos.
66
 Implementar una suficientemente fuerte política de recuperación de contraseñas. Un
buen ejemplo es el Forgot Password Cheat Sheet de OWASP (2018). En ella, se
indican algunas recomendaciones como:
 Como primer filtro, se deberían indicar preguntas de seguridad propuestas por
el usuario. Cabe decir que las respuestas deben ser escritas (no elegibles) en
html simple.
 Utilizar un canal aparte para enviar un token de recuperación. Cabe decir que
este token debe ser enviado a otro medio que no se/a un correo. Puede ser por
SMS, aplicación o cualquier otro medio.
 Se debe cerrar toda sesión activa de usuarios cuando se está recuperando la
contraseña.
 Permitir el cambio de contraseña una vez recuperada la contraseña.
 Mostrar mensajes de errores generales, no específicos. De esta manera se evita
enumeración de usuarios. Esto se debe realizar tanto para el registro, recuperación de
credenciales y APIs.
 Utilizar protocolos seguros (HTTPS), así como también el uso de autenticación de
cliente TLS.
67
 El control de acceso solo será efectivo si se aplica un código confiable del lado del
servidor o en una API sin servidor, en el cual el atacante no será capaz de modificar la
verificación o los metadatos del control de acceso.
 Configurando la excepción de los recursos públicos, los que deben denegarse de
manera predeterminada.
 Asignar propiedades a los registros, en lugar de aceptar que un usuario pueda crear,
leer, actualizar o eliminar cualquier registro. Así mismo, un usuario no debe acceder a
cualquier funcionalidad no autorizada simplemente solicitando el acceso directo a esa
página.
 Utilizar frameworks seguros que, por diseño, automáticamente codifican el contenido
para prevenir XSS, como en Ruby 3.0 o React JS.
 Habilitar una Política de Seguridad de Contenido (CSP) es una defensa profunda para
la mitigación de vulnerabilidades XSS, asumiendo que no hay otras vulnerabilidades
que permitan colocar código malicioso vía inclusión de archivos locales, bibliotecas
vulnerables en fuentes conocidas almacenadas en Redes de Distribución de
Contenidos (CDN) o localmente.
 Establecer el indicador HTTPOnly en el cookie de sesión y cualquier cookie
personalizada que no son accedidos por Javascript escritos por el programador.

68
 Use el encabezado de respuesta de protección X-XSS. Este encabezado de respuesta
HTTP habilita el filtro Cross-site scripting (XSS) integrado en algunos navegadores
web modernos. Este encabezado generalmente está habilitado de forma
predeterminada de todos modos, por lo que la función de este encabezado es volver a
habilitar el filtro para este sitio web en particular si el usuario lo inhabilitó.
 Deshabilitar el listado de directorios, asegurando que los metadatos y backups de los
archivos no están presentes en las raíces web.
 Deshabilitar toda configuración no necesaria para la operación de la aplicación web.
 Utilizar una herramienta para mantener un inventario de versiones de componentes
(por ej. frameworks o bibliotecas) tanto del cliente como del servidor.
 Monitorizar continuamente fuentes como CVE y NVD en búsqueda de
vulnerabilidades en los componentes utilizados. Utilizar herramientas de análisis
automatizados. Suscribirse a alertas de seguridad de los componentes utilizados.
 Supervisar bibliotecas y componentes que no poseen mantenimiento o no liberan
parches de seguridad para sus versiones obsoletas o sin soporte. Si el parcheo no es
posible, considere desplegar un parche virtual para monitorizar, detectar o protegerse
contra la debilidad detectada.
 Asegurar de que todos los errores de inicio de sesión, de control de acceso y de
validación de entradas de datos del lado del servidor se pueden registrar para
69
identificar cuentas sospechosas. Mantenerlo durante el tiempo suficiente para permitir
un eventual análisis forense.
 Asegurar de que las transacciones de alto impacto tengan una pista de auditoría con
controles de integridad para prevenir alteraciones o eliminaciones.
 Asegurar que todas las transacciones de alto valor poseen una traza de auditoría con
controles de integridad que permitan detectar su modificación o borrado, tales como
una base de datos con permisos de inserción únicamente u similar.
 Establezca una monitorización y alerta efectivos de tal manera que las actividades
sospechosas sean detectadas y respondidas dentro de períodos de tiempo aceptables.
5.2. Contrastación de Hipótesis
5.2.1. Hipótesis general
La hipótesis general indica: “Mediante la aplicación de recomendaciones técnicas de
OWASP sería posible mejorar la seguridad en las aplicaciones web de instituciones del sector
educativo”.
Al respecto, como se presentó en la Tabla 13, se observó que el nivel de riesgo luego
de aplicar las recomendaciones y controles OWASP reduce en gran medida el nivel de riesgo
de las aplicaciones web, llegando a un nivel de reducción del nivel de riesgo de hasta 60%,
por lo que se comprueba la hipótesis general.

70
5.2.2. Hipótesis específicas
Debido a que tenemos tres hipótesis específicas, contrastaremos cada una de ellas.
a. Primera Hipótesis Específica
La primera hipótesis específica indica: “Sería posible determinar los ataques más
comunes reportados hacia las instituciones del sector educativo”.
Al respecto, en la Tabla 6 queda expuesto que los ataques más comunes reportados
hacia las instituciones del sector educativo son los ataques de inyección SQL, comprobando
la hipótesis.
b. Segunda Hipótesis Específica
La segunda hipótesis específica indica: “Sería posible identificar las vulnerabilidades
que los atacantes más explotan para comprometer las aplicaciones web de las instituciones
del sector educativo”.
Al respecto, en la Tabla 7 queda expuesto que la vulnerabilidad que los atacantes más
explotan para comprometer las aplicaciones de las instituciones del sector educativo es el
manejo de entrada incorrecto, comprobando la hipótesis.

71
c. Tercera Hipótesis Específica
La tercera hipótesis específica indica: “Sería posible poner en práctica la metodología
de OWASP para identificar correctamente los riesgos a los que está expuesto una aplicación
web y tomar una decisión para su mitigación”.
Al respecto, luego de realizar los análisis de riesgos correspondientes, es posible la
correcta identificación de los riesgos a los que se está expuestos. El detalle del análisis se
encuentra en el anexo A.
5.3. Discusión de Resultados
Acorde con los resultados obtenidos, notamos que las recomendaciones y controles
son efectivos para mejorar la seguridad de las aplicaciones web de las instituciones
educativas, pudiendo demostrar además que se pueden aplicar y evaluar con la metodología
OWASP.
72
VI. CONCLUSIONES Y RECOMENDACIONES
6.1. Conclusiones
 Se demuestra que es posible evaluar los niveles de riesgo a los que está expuesto una
aplicación web de instituciones educativas.
 Es posible reducir el nivel de riesgo a los que se encuentran expuestos las aplicaciones
web de las instituciones educativas.
 Se demuestra que la reducción del nivel de riesgo es significativa, logrando hasta un
60% de disminución con respecto al nivel de riesgo obtenido del análisis previo a los
ataques.
 Se determinó los ataques más comunes reportados hacia las aplicaciones web de
instituciones educativas.
 Se determinó las vulnerabilidades más explotadas para lograr comprometer las
aplicaciones web de las instituciones educativas.
 Los niveles de riesgo catalogados como nivel de riesgo medio y bajo son aceptables.
73
 De haber sido implementadas las recomendaciones y controles propuestos por
OWASP, los ataques reportados habrían sido evitados.
 El uso de la metodología OWASP ayudó a la identificación y priorización de riesgos a
ser mitigados.
 Como trabajo a futuro, se propone mejorar los controles aplicados a la seguridad de
aplicaciones web de instituciones educativas, en la cual adicionalmente se usarán
recomendaciones y controles de otras organizaciones como NIST; así como también
integrar la metodología OWASP con CVSS, sistema utilizado para poder evaluar la
severidad de una vulnerabilidad basado en sus características, dando un nuevo
enfoque.
6.2. Recomendaciones
 Adaptar cada cuadro de nivel de impacto, posibilidad y riesgo a los requerimientos de
cada institución, ya que cada una tiene diferentes activos de información que
resguardar, así como también se manejan diferentes tecnologías.
 Realizar una evaluación de niveles de riesgo periódicamente, ya que las
vulnerabilidades y vectores de ataque se incrementa con el paso del tiempo.

74
 Actualizar los controles para mitigaciones de riesgo, así como también de las nuevas
vulnerabilidades publicadas. Se puede subscribir a boletines o revistas con esta
información.
 Se recomienda colaborar con instituciones u organismos investigadores como
OWASP, de manera que se pueden encontrar y compartir diferentes ideas.

75
REFERENCIAS BIBLIOGRÁFICAS
Banco Interamericano de Desarrollo (BID), Organización de los Estados Americanos. (Marzo
de 2016). Ciberseguridad ¿Estamos preparados en América Latina y el Caribe?
Obtenido de Banco Interamericano de Desarrollo:
https://publications.iadb.org/handle/11319/7449?locale-attribute=es&
Barnett, R. (OWASP) (2015). OWASP WASC Web Hacking Incidents Database Project.
Obtenido de OWASP:
https://www.owasp.org/index.php/OWASP_WASC_Web_Hacking_Incidents_Databas
e_Project
BBC (15 de Mayo de 2017). Ciberataque masivo: ¿quiénes fueron los países e instituciones
más afectados por el virus WannaCry?. Obtenido de BBC:
https://www.bbc.com/mundo/noticias-39929920
Calzavara, S., Bugliesi, M. & Focardi, R. (19 de Diciembre de 2016). Formal Methods for
Web Security. Obtenido de: http://www.dais.unive.it/~calzavara/papers/jlamp16.pdf
Christensson, P. (20 de Junio de 2016). API Definition. Obtenido de Techterms:
https://techterms.com/definition/api
Curtis, P. & Carey, M. (Deloitte & Touche LLP). (Octubre de 2012). Risk Assesment in
Practice. Obtenido de Deloitte:
https://www2.deloitte.com/content/dam/Deloitte/global/Documents/Governance-Risk-
Compliance/dttl-grc-riskassessmentinpractice.pdf
Dabirsiaghi, A. & Hsu, T. (OWASP) (Agosto de 2018). Deserialization Cheat Sheet.
Obtenido de OWASP: https://www.owasp.org/index.php/Deserialization_Cheat_Sheet
Erlingsson, U., Livshits, B. & Xie, Y. (Mayo de 2007). End-to-end web application security.
Actas del Workshop Hot Topics in Operating System (HotOS XI)

76
FireEye. (2015). REGIONAL ADVANCED THREAT REPORT: Latin America 1H 2015.
Obtenido de FireEye: https://www2.fireeye.com/WEB-Regional-Advanced-Threat-
Report-Latin-America-1H-2015.html
Flores, J. (Abril de 2018). Análisis, diseño e implementación de un sistema para el control de
la emisión y consumo de vales basado en una arquitectura de servicios. (Tesis inédita
de pregrado). Pontificia Universidad Católica del Perú, Lima, Perú.
Frieiro, R., Pérez, P. & Pascual, X. (Deloitte) (Junio de 2017). ¿Qué impacto ha tenido el
ciberincidente de WannaCry en nuestra economía?. Obtenido de Deloitte:
http://perspectivas.deloitte.com/hubfs/Campanas/WannaCry/Deloitte-ES-informe-
WannaCry.pdf
ISO / IEC (Febrero de 2018). ISO/IEC 27000 Information technology - Security techniques –
Information security management systems – Overview and vocabulary. Obtenido de
ISO:
http://standards.iso.org/ittf/PubliclyAvailableStandards/c073906_ISO_IEC_27000_201
8_E.zip
Keary, E., Manico, E., Goosen, T., Krawczyk, P., Neuhaus, S. & Aude, M. (OWASP). (Abril
de 2017). Authentication Cheat Sheet. Obtenido de OWASP:
https://www.owasp.org/index.php/Authentication_Cheat_Sheet
Laybats, C. & Tredinnick, L. (Junio de 2016). Information Security. Business Information
Review, 33(2), 76-80. doi: 10.1177/0266382116653061
MITRE. (Marzo de 2018). CWE-284: Improper Access Control. Obtenido de MITRE:
https://cwe.mitre.org/data/definitions/284.html
77
MITRE. (Marzo de 2018). CWE-502: Deserialization of Untrusted Data. Obtenido de
MITRE: https://cwe.mitre.org/data/definitions/502.html
Offut, J. (21 de Enero de 2002). Quality Attributes of Web Software Applications. Obtenido
de:
https://pdfs.semanticscholar.org/ea5f/224ba8f122ee6e8bfe0d732c55c1c5280cd4.pdf
Ordaya, R. (Noviembre de 2015). Implementación de un Sistema de información para una
Mype comercial con componentes de libros y facturación electrónica. (Tesis inédita de
pregrado). Pontificia Universidad Católica del Perú, Lima, Perú.
OWASP. (Octubre de 2017). OWASP Top 10 – 2017. The Ten Most Critical Web Application
Security Risks. Obtenido de OWASP:
https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf
OWASP. (Junio de 2018). Cross-site Scripting (XSS). Obtenido de OWASP:
https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
OWASP. (Agosto de 2018). OWASP Presentation. Obtenido de OWASP:
https://www.owasp.org/index.php/Main_Page
OWASP. (Agosto de 2018). OWASP Risk Rating Methodology. Obtenido de OWASP:
https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology
Positive Technologies (20 de Marzo de 2018). Cybersecurity threatscape 2017: trends and
forecasts. Obtenido de Positive Technologies:
https://www.ptsecurity.com/upload/corporate/ww-en/analytics/Cybersecurity-
threatscape-2017-eng.pdf
78
Positive Technologies (17 de Julio de 2018). Cybersecurity threatscape: Q1 2018. Obtenido
de Positive Technologies: https://www.ptsecurity.com/upload/corporate/ww-
en/analytics/Cybersecurity-threatscape-2018-Q1-eng.pdf
Rafique, S., Humayun, M., Hamid, B., Abbas, A., Akhtar, M. & Iqbal, K. (Junio de 2015).
Web application security vulnerabilities detection approaches: A systematic mapping
study. 2015 IEEE/ACIS 16th Conferencia Internacional de Ingeniería de Software de
Redes de Inteligencia Artificial y Computación Distribuida / Paralela (SNPD) (pp. 1-6)
Rapid7 Labs. (2017). National Exposure Index. Obtenido de Rapid7:
https://www.rapid7.com/data/national-exposure/2017.html#
Sangoluisa, D. (Setiembre de 2015). Definición de las políticas de seguridad de la
información para la red convergente de la Presidencia de la República del Ecuador
basado en las normas ISO 27000. (Tesis inédita de pregrado). Escuela Politécnica
Nacional, Quito, Ecuador.
Trustwave. (2018). 2018 TRUSTWAVE GLOBAL SECURITY REPORT. Obtenido de
Trustwave: https://www2.trustwave.com/GlobalSecurityReport.html
Valdivia, J. & De la Barra, L. (18 de Agosto de 2015). Subsistema de seguridad. (Tesis
inédita de pregrado). Universidad Peruana de Ciencias Aplicadas, Lima, Perú.
Watson, C. & Zaw, T. (OWASP) (15 de Febrero de 2018). OWASP Automated Threat
Handbook – Web Applications Version 1.2. Obtenido de OWASP:
https://www.owasp.org/images/3/33/Automated-threat-handbook.pdf
Wichers, D., Dabirsiaghi, A., Di Paolo, S., Heiderich, M., Vela, E. & Williams, J. (OWASP).
(Marzo de 2017). Types of Cross-Site Scripting. Obtenido de OWASP:
https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting
79
Williams, J., Manico, J. & Mattatall, N. (OWASP). (Agosto de 2018). XSS (Cross Site
Scripting) Prevention Cheat Sheet. Obtenido de OWASP:
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_She
et#XSS_Prevention_Rules
Yergeau, F., Sperberg-McQueen, C.M., Maler, E., Paoli, J. & Bray, T. (W3C
Recommendation). (26 de Noviembre de 2008). Extensible Markup Language (XML)
1.0. Obtenido de W3C: https://www.w3.org/TR/REC-xml/

80
ANEXOS
ANEXO A
1. Ataques que explotaron la vulnerabilidad de Manejo de entrada incorrecto
1.1. Ataques de inyección SQL
a) Impacto: Fuga de información
b) Clasificación OWASP:
 A1:2017 Inyección
 A3:2017 Exposición de información confidencial
 A10:2017 Registro y monitoreo insuficientes
c) Recomendaciones técnicas y controles propuestos:
81
estándar potente.
la segunda línea de defensa en caso los controles de acceso fallasen.
d) Escenario 1: WHID 2010-203: Confessed student hacker speaks. Estudiante de un
colegio en Londres (Ontario) utilizó la inyección SQL para lograr ingresar a la
aplicación de su universidad con privilegios de administrador. Al respecto, el
estudiante indicó que pudo obtener archivos de servidores, contraseñas, y nombres de
usuario, indicando además que el departamento de TI no los había cifrado /
resguardado correctamente.
82
d.1) Nivel de Impacto – Previo al ataque
Impacto Técnico
Clasificación Justificación Puntaje
Debido a que no cifraron la información
Confidencialidad correctamente, la totalidad de la información 5
pudo ser expuesta.
No hubo modificación de información, solo
Integridad 1
hurto.
Disponibilidad No hubo pérdida de servicios. 1
Debido a que se mantiene un registro, es

Rastreabilidad 4
posible que se rastree.
Nivel de Impacto Técnico: 3
Impacto Empresarial
Causo que se mejoraran los controles, y se
Daño Financiero 4
paguen reparaciones a los afectados.
Daño a la
Daño a la imagen corporativa. 5
reputación
Infracción escandalosa, ya que no se tenía el
Incumplimiento 4
cuidado debido.
Violación a la Los datos de cientos de personas fueron
3
privacidad comprometidos.
Nivel de Impacto Empresarial: 4
Nivel de Impacto del riesgo: 3
d.2) Nivel de Posibilidad – Previo al ataque
Posibilidad - Factor Agente de Amenaza

Los agentes de amenaza tienen habilidades de
Nivel de Habilidad 5
penetración de seguridad.
Al comprometer credenciales y archivos
Motivación confidenciales, puede obtener grandes 5
ganancias.
Oportunidades No requiere accesos. 5
83
Tamaño Puede ser un usuario externo no autenticado. 5
Nivel de Posibilidad - Factor Agente de Amenaza: 5
Posibilidad - Factor Vulnerabilidad

Facilidad de Existen herramientas automatizadas para
5
descubrimiento detectar la presencia de la vulnerabilidad.
5
explotación explotar la presencia de la vulnerabilidad.
Conocimiento La vulnerabilidad está oculta en la aplicación. 3
Se mantiene registro de los ingresos, pero no
Detección 4
se monitorea.
Nivel de Posibilidad - Factor Vulnerabilidad: 4
Nivel de Posibilidad del riesgo: 5
d.3) Nivel de Riesgo – previo al ataque: Como se mencionó, se usará la
siguiente fórmula:
Riesgo (previo_al_ataque)= 15 (Alto)
d.4) Nivel de Impacto – controles y recomendaciones aplicados: Debido a
que el impacto de realizarse el ataque se mantiene, el nivel de impacto
también se mantiene. De esa manera, el nivel de impacto es 3.
d.5) Nivel de Posibilidad – controles y recomendaciones aplicados:

84
Al no poder acceder por inyección, no podrá

sustraer la información. Aun accediera y
Motivación 1
sustrajera la información por otros medios, no
podrá desencriptarse.
Para poder sustraer la información, debe
Oportunidades 1
contar con acceso total al sistema.
Deben ser desarrolladores y/o
Tamaño 2
administradores del sistema.

Facilidad de
No hay manera de descubrir una inyección. 1
descubrimiento
Facilidad de Al no haber la vulnerabilidad de inyección ni
1
explotación falta de encriptación, no podrá explotarse.
Conocimiento No se conoce una vulnerabilidad conocida. 1
Detección Se mantiene un registro y se monitorea. 2
d.6) Nivel de Riesgo – controles y recomendaciones aplicados: Como se
mencionó, se usará la siguiente fórmula:
Riesgo (controles_implementados)= 6 (Medio)
e) Escenario 2: WHID 2011-155: Hacker breaks into MIT website. A pesar de su vasta
experiencia tecnológica, incluso el Massachussetts Institute of Technology (MIT) no
se libró de los piratas informáticos que irrumpieron en su sitio web y publicaron los
datos robados en línea. El hacker llamado Cyber_Owner irrumpió en el sitio del
Programa de Enlace Internacional del MIT (ilp.mit.edu), informó The Hacker News.
85
Una captura de pantalla del sitio pirateado mostró los nombres, números de teléfono e
inicios de sesión de aquellos en el programa.
e.1) Nivel de Impacto – Previo al ataque
Impacto Técnico
Se publicaron nombres, números de teléfono
Confidencialidad 4
e inicios de sesión.
No hubo modificación de información, solo
Integridad 1
hurto.
Publicaron la información confidencial en su
Disponibilidad 3
portal.
Debido a que se mantiene un registro, es
Rastreabilidad 4
posible que se rastree.
Impacto Empresarial
Daño Financiero 4
Daño a la
reputación
Incumplimiento 4
cuidado debido.
Violación a la Los datos de miles de personas fueron
4
e.2) Nivel de Posibilidad – Previo al ataque

86
Al comprometer nombres y números de

Motivación 5
contacto, puede obtener grandes ganancias.

5
5
Detección 4
se monitorea.
e.3) Nivel de Riesgo – previo al ataque: Como se mencionó, se usará la
siguiente fórmula:
Riesgo (previo_al_ataque)= 20 (Crítico)
e.4) Nivel de Impacto – controles y recomendaciones aplicados: Debido a
e.5) Nivel de Posibilidad – controles y recomendaciones aplicados:

87

Motivación 1
Oportunidades 1
Tamaño 2

Facilidad de
descubrimiento
1
e.6) Nivel de Riesgo – controles y recomendaciones aplicados: Como se
f) Escenario 3: WHID 2011-7: Hacker Breaks Into UConn Husky Store Website. Un
atacante logró acceder a la base de datos de la tienda web del equipo de fútbol
americano Ucon Husky, de la Universidad de Connecticut. La base de datos contenía
nombres de clientes, direcciones, correos electrónicos, números de teléfono e

88
información de tarjetas de crédito, incluyendo fechas de expiración y códigos de
seguridad. Los clientes que compraron presencialmente no fueron afectados.
f.1) Nivel de Impacto – Previo al ataque
Impacto Técnico
Cantidad considerable de información
Confidencialidad 4
sensible expuesta.
Integridad No se dañó información de los clientes. 1
Luego de detectada la brecha, se
Disponibilidad 5
interrumpieron los servicios de la aplicación.
Fue ejecutado por un usuario anónimo de
Rastreabilidad 5
internet.
Impacto Empresarial
Efecto significativo en el balance anual, por
Daño Financiero reparaciones financieras a clientes, multas 4
que hubiese y controles adicionales.
Daño a la
reputación
Incumplimiento 4
cuidado debido.
Violación a la .Aproximadamente 18000 registros de
4
privacidad clientes fueron afectados.
f.2) Nivel de Posibilidad – Previo al ataque

Requirió habilidades de penetración de
seguridad.
89
Gran recompensa, ya que la información es

Motivación 5
muy valiosa.
Oportunidades No requiere acceso o recursos. 5
El usuario puede ser un usuario anónimo de
Tamaño 5
internet.

Facilidad de Existen herramientas automatizadas
5
descubrimiento disponibles.
5
explotación disponibles.
Conocimiento La vulnerabilidad se encontraba oculta. 3
Se mantiene registro de acceso a la base de
Detección 4
datos, pero no se monitorea.
f.3) Nivel de Riesgo – previo al ataque: Como se mencionó, se usará la
siguiente fórmula:
f.4) Nivel de Impacto – controles y recomendaciones aplicados: Debido a
f.5) Nivel de Posibilidad – controles y recomendaciones aplicados:

90

Requiere habilidades de penetración de
seguridad.
Luego de aplicados los controles, la
Motivación 1
recompensa será baja o nula.
Oportunidades Requiere acceso total o recursos caros. 1
Atacante deben ser desarrolladores o
Tamaño 2
administradores de sistemas.

Al haber sido mitigada la vulnerabilidad, es
Facilidad de
prácticamente imposible descubrir la 1
descubrimiento
vulnerabilidad.
Facilidad de Al haber sido mitigada la vulnerabilidad, es
1
explotación teórica la explotación de la vulnerabilidad.
Conocimiento La vulnerabilidad es desconocida. 1
La aplicación detecta y bloquea activamente
Detección 1
los ataques de inyección SQL.
f.6) Nivel de Riesgo – controles y recomendaciones aplicados: Como se
g) Escenario 4: WHID 2011-84: Hackers access personal info of Lancaster County
students. Atacantes hurtaron 25000 registros de estudiantes del distrito escolar del
condado de Lancaster. La información almacenada en la base de datos data de hace 10
años.
91
g.1) Nivel de Impacto – Previo al ataque
Impacto Técnico
Confidencialidad 4
sensible expuesta.
Integridad No se dañó información de los estudiantes. 1
No se vieron afectados los servicios de la
Disponibilidad 1
aplicación.
Rastreabilidad 5
internet.
Impacto Empresarial
Efecto significativo en el balance anual, por
Daño Financiero 4
multas que hubiese y controles adicionales.
Daño a la
reputación
Incumplimiento 4
cuidado debido.
Violación a la .Aproximadamente 25000 registros de
4
privacidad estudiantes fueron afectados.
g.2) Nivel de Posibilidad – Previo al ataque

seguridad.
Gran recompensa, ya que la información es
Motivación 5
muy valiosa.
El usuario puede ser un usuario anónimo de
Tamaño 5
internet.
92

5
descubrimiento disponibles.
5
explotación disponibles.
Conocimiento La vulnerabilidad se encontraba oculta. 3
Se mantiene registro de acceso a la base de
Detección 4
datos, pero no se monitorea.
g.3) Nivel de Riesgo – previo al ataque: Como se mencionó, se usará la
siguiente fórmula:
g.4) Nivel de Impacto – controles y recomendaciones aplicados: Debido a
g.5) Nivel de Posibilidad – controles y recomendaciones aplicados:

Requiere habilidades de penetración de
seguridad.
Luego de aplicados los controles, la
Motivación 1
recompensa será baja o nula.
93
Oportunidades Requiere acceso total o recursos caros. 1

Atacante deben ser desarrolladores o
Tamaño 2
administradores de sistemas.

Al haber sido mitigada la vulnerabilidad, es
Facilidad de
prácticamente imposible descubrir la 1
descubrimiento
vulnerabilidad.
Facilidad de Al haber sido mitigada la vulnerabilidad, es
1
explotación teórica la explotación de la vulnerabilidad.
Conocimiento La vulnerabilidad es desconocida. 1
La aplicación detecta y bloquea activamente
Detección 1
los ataques de inyección SQL.
g.6) Nivel de Riesgo – controles y recomendaciones aplicados: Como se
h) Escenario 5: WHID 2012-377: Hackers deface old UTS system, dump user database.
La Universidad de Tecnología de Sídney fue víctima de un ataque, en el que se
desfiguró uno de sus subdominios y al mismo tiempo, una base de datos antigua fue
descargada y modificada. El ataque fue realizado mediante una inyección SQL. La
base de datos contenía nombres, correos, cuentas de usuario y contraseñas en texto
plano.
h.1) Nivel de Impacto – Previo al ataque

94
Impacto Técnico
pudo ser expuesta.
Hubo modificación de la información de una
Integridad base de datos, cuando pudieron haber sido 5
más.
El subdominio se vio afectado, mas no a
Disponibilidad 3
totalidad de la aplicación.
Rastreabilidad Completamente anónimo. 5

Impacto Empresarial
Causó que se mejoraran los controles, y se
Daño Financiero 4
Daño a la
reputación
Incumplimiento 4
cuidado debido.
3
h.2) Nivel de Posibilidad – Previo al ataque

Al comprometer credenciales y archivos
Motivación confidenciales, puede obtener grandes 5
ganancias.

95

5
5
Detección 4
se monitorea.
h.3) Nivel de Riesgo – previo al ataque: Como se mencionó, se usará la
siguiente fórmula:
h.4) Nivel de Impacto – controles y recomendaciones aplicados: Debido a
h.5) Nivel de Posibilidad – controles y recomendaciones aplicados:

96

Motivación 1
Oportunidades 1
Tamaño 2

Facilidad de
descubrimiento
1
h.6) Nivel de Riesgo – controles y recomendaciones aplicados: Como se
i) Escenario 6: WHID 2012-382: GhostShell university hack: By the numbers. El grupo
hacktivista GhostShell publicó 120000 registros obtenidos de bases de datos de
diversas universidades, como la Universidad de Michigan, la Universidad de Nueva
York entre otros. Los registros contenían nombres, direcciones, contraseñas, fechas de
nacimiento, condición socioeconómica y sólo un número de cuenta. No se

97
encontraron números de seguro social ni números de tarjeta de crédito. El medio de
ataque fue mediante inyección SQL.
i.1) Nivel de Impacto – Previo al ataque
Impacto Técnico
pudo ser expuesta.
Integridad No hubo modificación de información. 1
Disponibilidad No hubo corte de servicios. 1

Impacto Empresarial
Daño Financiero 4
Daño a la
reputación
Incumplimiento 4
cuidado debido.
4
i.2) Nivel de Posibilidad – Previo al ataque

98
Al comprometer credenciales e información

Motivación sensible, se desprestigió a las universidades. 5
El grupo era de hacktivista.

5
5
Detección 4
se monitorea.
i.3) Nivel de Riesgo – previo al ataque: Como se mencionó, se usará la
siguiente fórmula:
i.4) Nivel de Impacto – controles y recomendaciones aplicados: Debido a
i.5) Nivel de Posibilidad – controles y recomendaciones aplicados:

99

Motivación 1
Oportunidades 1
Tamaño 2

Facilidad de
descubrimiento
1
i.6) Nivel de Riesgo – controles y recomendaciones aplicados: Como se
j) Escenario 7: WHID 2012-63: Singapore University hacked. Un grupo de atacantes
aprovechó una vulnerabilidad en los requerimientos SQL para obtener credenciales y

100
nombres de dominio de usuarios de la Universidad de Singapur. De acuerdo a la
universidad, las credenciales no accedían a servidores críticos sino a servidores que
contenían información pública.
j.1) Nivel de Impacto – Previo al ataque
Impacto Técnico
Confidencialidad La información sustraída no era confidencial. 3

Impacto Empresarial
Daño Financiero 4
Daño a la
reputación
Incumplimiento Infracción escandalosa. 4

4
j.2) Nivel de Posibilidad – Previo al ataque

101

Motivación Probable recompensa. 3

5
5
Detección 4
se monitorea.
j.3) Nivel de Riesgo – previo al ataque: Como se mencionó, se usará la
siguiente fórmula:
j.4) Nivel de Impacto – controles y recomendaciones aplicados: Debido a
j.5) Nivel de Posibilidad – controles y recomendaciones aplicados:

102

Motivación 1
Oportunidades 1
Tamaño 2

Facilidad de
descubrimiento
1
j.6) Nivel de Riesgo – controles y recomendaciones aplicados: Como se
k) Escenario 8: WHID 2014-034: Hacker attempts to hold Johns Hopkins hostage using
student data. Un grupo de atacantes aprovechó una vulnerabilidad en los

103
requerimientos SQL para obtener nombres, correos y números de contacto de 850
alumnos de ingeniería biomédica de la Universidad Johns Hopkins.
k.1) Nivel de Impacto – Previo al ataque
Impacto Técnico
Cantidad considerable de información no

Confidencialidad 3
sensible expuesta.

Impacto Empresarial
Daño Financiero 4
Daño a la
reputación

3
k.2) Nivel de Posibilidad – Previo al ataque

104

5
5
Detección 4
se monitorea.
k.3) Nivel de Riesgo – previo al ataque: Como se mencionó, se usará la
siguiente fórmula:
k.4) Nivel de Impacto – controles y recomendaciones aplicados: Debido a
k.5) Nivel de Posibilidad – controles y recomendaciones aplicados:

105

Motivación 1
Oportunidades 1
Tamaño 2

Facilidad de
descubrimiento
1
k.6) Nivel de Riesgo – controles y recomendaciones aplicados: Como se

106
l) Escenario 9: WHID 2015-008: Universities hacked, data dumped. En un post de
Pastebin, un atacante reclamó varios ataques hacia universidades, los cuales
aprovecharon las vulnerabilidades de SQL. .
l.1) Nivel de Impacto – Previo al ataque
Impacto Técnico

Confidencialidad 4
sensible expuesta.

Integridad 4
gravemente dañada.

Impacto Empresarial
Daño Financiero 4
Daño a la
reputación

4
l.2) Nivel de Posibilidad – Previo al ataque

107


5
5
Detección 4
se monitorea.
l.3) Nivel de Riesgo – previo al ataque: Como se mencionó, se usará la
siguiente fórmula:
l.4) Nivel de Impacto – controles y recomendaciones aplicados: Debido a
l.5) Nivel de Posibilidad – controles y recomendaciones aplicados:

108

Motivación Baja o nula recompensa. 1
Oportunidades Requiere acceso total. 1
Atacante debe ser desarrollador o

Tamaño 2
administrador.

Facilidad de
descubrimiento
1
l.6) Nivel de Riesgo – controles y recomendaciones aplicados: Como se

109
m) Escenario 10: WHID 2015-013: U. of Hawaii and Cornell University hacked. La
universidad de Hawaii fue víctima de una sustracción de información, en la que se
obtuvo el usuario root, las direcciones mac, etiquetas de servicio.
m.1) Nivel de Impacto – Previo al ataque
Impacto Técnico
Cantidad considerable de información no

Confidencialidad 3
sensible expuesta.
Integridad No hubo información modificada. 1

Impacto Empresarial
Daño Financiero 4
Daño a la
reputación

4
m.2) Nivel de Posibilidad – Previo al ataque

110


5
5
Detección 4
se monitorea.
m.3) Nivel de Riesgo – previo al ataque: Como se mencionó, se usará la
siguiente fórmula:
m.4) Nivel de Impacto – controles y recomendaciones aplicados: Debido a
m.5) Nivel de Posibilidad – controles y recomendaciones aplicados:

111


Tamaño 2
administrador.

Facilidad de
descubrimiento
1
m.6) Nivel de Riesgo – controles y recomendaciones aplicados: Como se
n) Escenario 11: WHID 2015-025: Hacker breached Metropolitan State University
database with personal info. La universidad metropolitana estatal fue víctima de un
acceso no autorizado a una de las bases de datos, logrando sustraer información.

112
Dentro de lo obtenido, se encuentran algunos números de seguro social, pero ningún
registro referente a tarjetas de crédito o débito.
n.1) Nivel de Impacto – Previo al ataque
Impacto Técnico

Confidencialidad 4
sensible expuesta.

Impacto Empresarial
Daño Financiero 4
Daño a la
reputación

4
n.2) Nivel de Posibilidad – Previo al ataque

113
Alta recompensa, ya que puede suplantar la

Motivación 5
identidad de los usuarios.

5
5
Detección 4
se monitorea.
n.3) Nivel de Riesgo – previo al ataque: Como se mencionó, se usará la
siguiente fórmula:
n.4) Nivel de Impacto – controles y recomendaciones aplicados: Debido a
n.5) Nivel de Posibilidad – controles y recomendaciones aplicados:

114


Tamaño 2
administrador.

Facilidad de
descubrimiento
1
n.6) Nivel de Riesgo – controles y recomendaciones aplicados: Como se
o) Escenario 12: WHID 2015-030: philsacra.ust.edu.ph website hacked. La universidad
Philippiniana Sacra fue víctima de un robo de una base de datos, la cual se encuentra
115
expuesta en internet. Dicha base de datos contiene numerosos registros de sus
usuarios, entre los que están: nombre, usuario, fecha de nacimiento, entre otros.
o.1) Nivel de Impacto – Previo al ataque
Impacto Técnico
Cantidad considerable de información si

Confidencialidad 4
sensible expuesta.

Impacto Empresarial
Daño Financiero 4
Daño a la
reputación

4
o.2) Nivel de Posibilidad – Previo al ataque

116

5
5
Detección 4
se monitorea.
o.3) Nivel de Riesgo – previo al ataque: Como se mencionó, se usará la
siguiente fórmula:
o.4) Nivel de Impacto – controles y recomendaciones aplicados: Debido a
o.5) Nivel de Posibilidad – controles y recomendaciones aplicados:

117


Tamaño 2
administrador.

Facilidad de
descubrimiento
1
o.6) Nivel de Riesgo – controles y recomendaciones aplicados: Como se
p) Escenario 13: WHID 2015-035: U. Chicago hacked. La universidad de Chicago fue
atacada por el grupo Carbonic, publicando una base de datos de miembros del
118
departamento de ciencias biológicas. Dentro de los datos que contiene la base de
datos, hay nombres, correos electrónicos y estado salarial.
p.1) Nivel de Impacto – Previo al ataque
Impacto Técnico

Confidencialidad 4
sensible expuesta.

Impacto Empresarial
Daño Financiero 4
Daño a la
reputación

4
p.2) Nivel de Posibilidad – Previo al ataque

119

5
5
Detección 4
se monitorea.
p.3) Nivel de Riesgo – previo al ataque: Como se mencionó, se usará la
siguiente fórmula:
p.4) Nivel de Impacto – controles y recomendaciones aplicados: Debido a
p.5) Nivel de Posibilidad – controles y recomendaciones aplicados:

120


Tamaño 2
administrador.

Facilidad de
descubrimiento
1
p.6) Nivel de Riesgo – controles y recomendaciones aplicados: Como se
q) Escenario 14: WHID 2015-041: Victor Valley College hit by computer security
breach. El departamento de tecnologías de la información de la universidad Victor
Valley llevó una investigación debido a que, en ese momento, detectó una brecha de
121
seguridad, la cual fue perpetrada por un usuario interno. No hubo fuga de
información.
q.1) Nivel de Impacto – Previo al ataque
Impacto Técnico
Gran cantidad de información sensible

Confidencialidad 5
potencialmente comprometida.

Impacto Empresarial
Daño Financiero Causó que se mejoraran los controles. 2
Daño a la
reputación
Incumplimiento Infracción moderada. 3
Violación a la
No hubo violación a la privacidad. 1
privacidad
q.2) Nivel de Posibilidad – Previo al ataque

122

5
5
Detección 4
se monitorea.
q.3) Nivel de Riesgo – previo al ataque: Como se mencionó, se usará la
siguiente fórmula:
q.4) Nivel de Impacto – controles y recomendaciones aplicados: Debido a
q.5) Nivel de Posibilidad – controles y recomendaciones aplicados:

123


Tamaño 2
administrador.

Facilidad de
descubrimiento
1
q.6) Nivel de Riesgo – controles y recomendaciones aplicados: Como se
r) Escenario 15: WHID 2015-042: Higher Education Commission Pakistan Hacked. La
comisión de educación superior de Pakistán fue víctima de un ataque, en el cual
sustrajeron información de la base de datos. Dicha información se encuentra expuesta

124
en internet. En ella, se muestran nombres de usuario de sistema y contraseñas, así
como también información personal de los estudiantes. El ataque fue perpetrado por el
grupo Anonsec.
r.1) Nivel de Impacto – Previo al ataque
Impacto Técnico
Confidencialidad Totalidad de información expuesta. 5

Impacto Empresarial
Daño Financiero 4
Daño a la
reputación

4
r.2) Nivel de Posibilidad – Previo al ataque

125


5
5
Detección 4
se monitorea.
r.3) Nivel de Riesgo – previo al ataque: Como se mencionó, se usará la
siguiente fórmula:
r.4) Nivel de Impacto – controles y recomendaciones aplicados: Debido a
r.5) Nivel de Posibilidad – controles y recomendaciones aplicados:

126


Tamaño 2
administrador.

Facilidad de
descubrimiento
1
r.6) Nivel de Riesgo – controles y recomendaciones aplicados: Como se
1.2. Ataques de inyección XSS
a) Impacto: Desfiguración
127
 A6:2017 Errores en las configuraciones de seguridad
 A7:2017 Cross-Site Scripting (XSS)
 Cada vez que se realice un cambio o actualización en el sistema, este debe ser
probado y escaneado en los ambientes de desarrollo y pruebas, de manera que se

128
puedan identificar errores en configuraciones antes de su implementación en
producción.

129
d) Escenario 16: WHID 2011-238: US uni warned, then hacked. Un atacante desfiguró
el sitio web de la Universidad de Vermont luego que se divulgaran varias
vulnerabilidades relacionadas con cross-site scripting (XSS), inyección SQL y
ejecución remota de códigos. Estas vulnerabilidades fueron publicadas un mes antes
del ataque y aparentemente no fueron tomadas en cuenta.
Impacto Técnico
Confidencialidad No se expuso información. 1
Integridad No se dañó información de la universidad. 1
Se interrumpieron la totalidad de los servicios
Disponibilidad 5
de la aplicación web.
Rastreabilidad 5
internet.
Impacto Empresarial
Causa un efecto mínimo en el balance anual
Daño Financiero 2
al tener que aplicar controles y medidas.
Daño a la
reputación
Incumplimiento 4
cuidado debido.
Violación a la
No hay violación a la privacidad. 1
privacidad
130

seguridad.
La desfiguración disminuye la reputación de
Motivación la universidad, teniendo como recompensa 3
posible un pago por realizar esto.
Tamaño Usuarios anónimos de internet. 5

Facilidad de
Herramientas automatizadas disponibles. 5
descubrimiento
Facilidad de
explotación
Las vulnerabilidades fueron publicadas un
Conocimiento 5
mes antes.
Detección Se mantienen registros. 4
siguiente fórmula:

131

seguridad.
Luego de aplicar los controles, la recompensa
Motivación 1
es muy baja.
Oportunidades Para realizar el ataque, requiere acceso total. 1
Requiere que el atacante sea desarrollador o
Tamaño 2
administrador del sistema.

Luego de aplicar los controles, es
Facilidad de
prácticamente imposible encontrar la 1
descubrimiento
vulnerabilidad.
Facilidad de Luego de aplicar los controles, la explotación
1
explotación de la vulnerabilidad es teórica.
Las vulnerabilidades fueron publicadas un
Conocimiento 5
mes antes.
Se detecta activamente en la aplicación y se
Detección 1
bloquea.

132
1.3. Ataques de inyección de código
a) Impacto: Fraude
 A9:2017 Uso de componentes con vulnerabilidades conocidas
 Deshabilitar el listado de directorios.

133
 Utilizar una herramienta para mantener un inventario de versiones de componentes
(por ej. frameworks o bibliotecas) tanto del cliente como del servidor.
 Monitorizar continuamente fuentes como CVE y NVD en búsqueda de
vulnerabilidades en los componentes utilizados. Utilizar herramientas de análisis
automatizados. Suscribirse a alertas de seguridad de los componentes utilizados.
 Supervisar bibliotecas y componentes que no poseen mantenimiento o no liberan
parches de seguridad para sus versiones obsoletas o sin soporte. Si el parcheo no es
posible, considere desplegar un parche virtual para monitorizar, detectar o protegerse
contra la debilidad detectada.

134
d) Escenario 17: WHID 2012-155: Hackers Elect Futurama's Bender to the Washington
DC School Board. Un grupo de atacantes de la Universidad de Michigan aprovechó
una vulnerabilidad para ejecutar una inyección de Shell script en el sistema de voto
electrónico para elegir al consejo escolar en un colegio público de Washington DC
(framework Ruby on Rails), de manera que lograron acceder y realizar cambios. Con
esto, lograron que un personaje de la serie Futurama (Bender) ganara la elección. Así
mismo, se detectó que el sistema mantenía credenciales de administrador por defecto
(user: admin, password: admin) y también se detectó que cierto archivo pdf contenía
códigos de autenticación de electores, el cual se encontraba en el directorio /tmp/.
Impacto Técnico
Confidencialidad No hubo filtración de información. 1
Integridad Se dañaron los votos de los electores. 4
Se modificó la pantalla de inicio del sistema,
Disponibilidad 5
así como también modificó las votaciones.
Rastreabilidad Posiblemente rastreable. 4
Impacto Empresarial
Daño Financiero Efecto mínimo en el balance anual. 2
135
Daño a la Pérdida de buena voluntad, debido a

3
reputación desconfianza.
Violación a la No hubo violación a la privacidad de

1
privacidad personas.

Nivel de Habilidad Habilidades de penetración de seguridad. 5

Motivación Recompensa baja o nula. 1

Facilidad de
descubrimiento
Facilidad de
explotación
Conocimiento Conocida vulnerabilidad del framework. 5
Detección No se mantiene registro. 5
siguiente fórmula:
136


Tamaño Desarrolladores o administradores de sistema. 2

Facilidad de
Difícil. 2
descubrimiento
Facilidad de
Difícil. 2
explotación
Conocimiento Oculta. 3

137
2. Ataques que explotaron la vulnerabilidad de Autenticación insuficiente
2.1. Ataques de Robo de Credenciales
a) Impacto: Desinformación, fraude, fuga de información
 A2:2017 Ruptura de autenticación
producción.

138
esta lista.
minutos.

139
d) Escenario 18: WHID 2011-94: High school hackers expose security gap in Seattle
Public Schools. De acuerdo con el departamento de TI de la escuela pública de
Seattle, se sospecha el robo de credenciales de profesores de la escuela por parte de
algunos estudiantes con el objetivo de cambiar las notas. El método para sustraer las
credenciales fue mediante el uso de un keylogger instalado en la pc de la escuela.
Impacto Técnico
Se vieron involucrados no solo credenciales
Confidencialidad de profesores, sino también de alumnos o 4
cualquier otro usuario de dicha PC.
Se pudieron haber modificado la totalidad de
Integridad información referente a alumnos y 4
profesores.
Disponibilidad 1
aplicación.

Impacto Empresarial
140

3
Violación a la Pudieron haber sido afectados los registros de

4
privacidad miles de personas.

El ataque es realizado por un usuario
avanzado de computación.
Posible recompensa, ya que al acceder con
Motivación estos permisos se pudo haber realizado otras 3
acciones.
Oportunidades Requiere algunos accesos o recursos. 4
Tamaño Usuarios anónimos. 5

Facilidad de
Fácil. 4
descubrimiento
Facilidad de Se usó un keylogger para obtener las
5
explotación credenciales.
Conocimiento Desconocida. 1
Se mantiene un registro, pero no se
Detección 4
monitorea.

141
siguiente fórmula:

Requerirían ser usuarios de intranet y
Tamaño 3
asociados.

Facilidad de
Difícil. 2
descubrimiento
En caso de obtener las credenciales con un
Facilidad de keylogger, con el segundo factor de
1
explotación autenticación no se explotará la
vulnerabilidad, por lo que sería teórica.
Detección Detección activa en la aplicación. 1

142
e) Escenario 19: WHID 2012-113: Students busted for hacking computers, changing
grades. Estudiantes obtuvieron credenciales de profesores, logrando cambiar sus notas
y así mismo, obtener exámenes para venderlos. Se usó un keylogger para obtener las
credenciales.
e.1) Nivel de Impacto – Previo al ataque
Impacto Técnico
Se vieron involucrados credenciales de
Confidencialidad profesores, pudiendo acceder a las notas de 3
los demás alumnos.
profesores.
Disponibilidad 1
aplicación.

Impacto Empresarial
3

4
143
e.2) Nivel de Posibilidad – Previo al ataque

Alta recompensa debido a que se
Motivación beneficiarían los alumnos y obtendría dinero 5
por los exámenes.

Facilidad de
Fácil. 4
descubrimiento
Facilidad de Se usó un keylogger para obtener las
5
explotación credenciales.
Detección 4
monitorea.
e.3) Nivel de Riesgo – previo al ataque: Como se mencionó, se usará la
siguiente fórmula:

144
e.4) Nivel de Impacto – controles y recomendaciones aplicados: Debido a
e.5) Nivel de Posibilidad – controles y recomendaciones aplicados:

Tamaño 3
asociados.

Facilidad de
Difícil. 2
descubrimiento
En caso de obtener las credenciales con un
Facilidad de keylogger, con el segundo factor de
1
explotación autenticación no se explotará la
vulnerabilidad, por lo que sería teórica.
e.6) Nivel de Riesgo – controles y recomendaciones aplicados: Como se

145
f) Escenario 20: WHID 2012-298: Pennsylvania mom allegedly hacked school website
to change kids' grades. Una mujer de Pensilvania supuestamente cambió las
calificaciones de sus hijos después de iniciar sesión con las credenciales del
superintendente del distrito escolar, luego de haberlas sustraído cuando trabajaba para
el distrito.
f.1) Nivel de Impacto – Previo al ataque
Impacto Técnico
Al obtener las credenciales del
superintendente del distrito, se hubiera
Confidencialidad 3
podido acceder a las notas de los demás
alumnos.
profesores.
Disponibilidad 1
aplicación.

Impacto Empresarial
3

4

146
f.2) Nivel de Posibilidad – Previo al ataque

Alta recompensa debido a que se

Motivación 5
beneficiarían los alumnos.


Facilidad de
Fácil. 4
descubrimiento
Facilidad de Obtuvo las credenciales al trabajar en el
5
explotación distrito.
Detección 4
monitorea.
f.3) Nivel de Riesgo – previo al ataque: Como se mencionó, se usará la
siguiente fórmula:

147
f.4) Nivel de Impacto – controles y recomendaciones aplicados: Debido a
f.5) Nivel de Posibilidad – controles y recomendaciones aplicados:

Tamaño 3
asociados.

Facilidad de
Difícil. 2
descubrimiento
En caso de obtener las credenciales, con el
Facilidad de segundo factor de autenticación no se
1
explotación explotará la vulnerabilidad, por lo que sería
teórica.
f.6) Nivel de Riesgo – controles y recomendaciones aplicados: Como se

148
g) Escenario 21: WHID 2014-028: U-Md. computer security attack exposes 300,000
records. Un grupo de atacantes robaron información personal que asciende al número
de 300000, los que incluyen nombres, números de seguro social, fechas de nacimiento
y números de identificación universitaria de la aplicación web de la Universidad de
Maryland. De acuerdo a la investigación, la brecha se debió a que los atacantes
lograron robar credenciales, con las que pudieron acceder a la plataforma y escalar
hasta obtener la información. Luego de la brecha, algunos de los afectados reportaron
intentos de fraude con tarjetas de crédito.
g.1) Nivel de Impacto – Previo al ataque
Impacto Técnico

Confidencialidad 4
sensible expuesta.

Integridad 4
información.
Disponibilidad No se vio afectada la aplicación web. 5

Impacto Empresarial
Efecto significativo en el balance anual,
debido a que la universidad dispondrá de
Daño Financiero 4
apoyo económico en investigación y en caso
de fraude a los afectados.
Daño a la
reputación

149
Violación a la Se vieron afectados cientos de miles de

5
g.2) Nivel de Posibilidad – Previo al ataque

El ataque es realizado por usuarios con
habilidades de penetración de seguridad.
Alta recompensa debido a que pueden

Motivación 5
suplantar identidades y cometer fraudes.
Oportunidades No requiere de acceso. 5


Facilidad de
Difícil. 2
descubrimiento
Facilidad de
Difícil. 2
explotación
Detección 4
monitorea.
g.3) Nivel de Riesgo – previo al ataque: Como se mencionó, se usará la
siguiente fórmula:

150
g.4) Nivel de Impacto – controles y recomendaciones aplicados: Debido a
g.5) Nivel de Posibilidad – controles y recomendaciones aplicados:

El ataque es realizado por usuarios con
habilidades de penetración de seguridad.
Motivación Alta recompensa. 5
Requerirían ser usuarios desarrolladores o
Tamaño 2
administradores de aplicación.

Facilidad de
Difícil. 2
descubrimiento
1
teórica.
g.6) Nivel de Riesgo – controles y recomendaciones aplicados: Como se

151
2.2. Ataques de Fuerza Bruta
a) Impacto: Desfiguración
producción.
esta lista.
152
minutos.

153
d) Escenario 22: WHID 2014-017: School District Still Using Default Login For Admin
Account Surprised To Learn Its Site Has Been Hacked. Atacantes realizaron un
ataque de fuerza bruta a la aplicación web del Distrito Escolar Independiente de
Round Rock en Austin. Desfiguraron la página principal indicando el método que
utilizaron para acceder con privilegios de administrador: usuario admin y contraseña
admin1.
Impacto Técnico
Al obtener las credenciales de administrador,
Confidencialidad se hubiera podido acceder a otro tipo de 4
información clasificada.
Integridad 4
información.
Se vio afectada la aplicación web del distrito
Disponibilidad 5
escolar.

Impacto Empresarial
3
154

4

Alta recompensa debido a que se podrían
Motivación haber beneficiado de información más 5
sensible.
Oportunidades No requiere de acceso. 5

Facilidad de
descubrimiento
Facilidad de
explotación
Detección 4
monitorea.
siguiente fórmula:
155

Tamaño 3
asociados.

Facilidad de
Difícil. 2
descubrimiento
1
teórica.

156
3. Ataques que explotaron la vulnerabilidad de Configuración incorrecta de la
aplicación
3.1. Ataques de Spoofing de contenido
a) Impacto: Perdida de reputación por enlace spam
 A5:2017 Ruptura de control de acceso
leer, actualizar o eliminar cualquier registro. Así mismo, un usuario no debe acceder a
cualquier funcionalidad no autorizada simplemente solicitando el acceso directo a esa
página.
157
d) Escenario 23: WHID 2010-103: SEO SPAM network - Details of the wp-includes
infection. Una red SEO SPAM que utilizó miles de sitios para aumentar su
clasificación y propagar malware, el cual estuvo enfocado en sitios web de
Wordpress. Todos los sitios infectados utilizaron la última versión de Wordpress, los
cuales tuvieron un script PHP inyectado dentro de su directorio wp-includes. El
nombre del script era aleatorio y realizaba dos funciones: Para motores de búsqueda,
mostraba diferentes palabras clave; y en cuanto a usuarios que provenían de Google,
redirigía a un sitio web con malware.
Impacto Técnico
158
Debido a que no se vieron expuestos datos

Confidencialidad 1
sensibles / no sensibles.
Debido a que no la información no fue
Integridad 1
modificada.
Debido a que los servicios primarios /
Disponibilidad 1
secundarios no fueron interrumpidos.
Al ser redirigidos a un dominio, el dominio
Rastreabilidad 1
era completamente rastreable.
Impacto Empresarial
Causa un efecto mínimo en el balance anual
Daño Financiero 2
al tener que depurar el script.
Daño a la Debido a que el dominio redirigía a otros
5
reputación malicioso, la imagen se veía dañada.
Incumplimiento Es una infracción menor. 2
Violación a la
No hubo violación a la privacidad. 1
privacidad

Los agentes de amenaza tuvieron habilidades
de penetración de seguridad.
La recompensa por realizar el ataque fue
Motivación obtener más visitas, generando grandes 5
ingresos.
Para poder ingresar el script, requirieron
Oportunidades 4
ingresar como usuarios externos.
Tamaño Usuarios externos autenticados. 4

159

Facilidad de
Herramientas automáticas disponibles. 5
descubrimiento
Facilidad de
Herramientas automáticas disponibles. 5
explotación
Vulnerabilidad de conocimiento público para
Conocimiento los agentes de amenaza, debido a que usaban 5
Wordpress.
Se mantuvo registro de usuario que accedió y
Detección 4
colocó el script pero no se monitoreó.
siguiente fórmula:

La recompensa por realizar el ataque será
Motivación 3
obtener más visitas.
160
Oportunidades Requiere acceso total a la aplicación. 1

Tamaño 2
administradores de la aplicación.

Facilidad de Prácticamente imposible descubrir la
1
descubrimiento vulnerabilidad que ayude a realizar el ataque.
Facilidad de Al no haber la vulnerabilidad, no se podrá
1
explotación explotar.
Al haber suprimido la vulnerabilidad de
Conocimiento Wordpress, no se conoce una vulnerabilidad 1
para la aplicación actual.
Se mantiene una detección activa con las
Detección 1
recomendaciones aplicadas.
Riesgo (controles_implementados)= 4 (Bajo)
4. Ataques que explotaron la vulnerabilidad de Manejo de salida incorrecto
4.1. Ataques de Envenenamiento de motor de búsqueda
a) Impacto: Spam
161
 A7:2017 Cross-Site Scripting (XSS)

162
d) Escenario 24: WHID 2012-257: UMass website hacked, Google searchers get offer
to sell Viagra. Al buscar en Google sobre la Universidad de Massachusetts, brindaba
una página de viagra con la descripción de la universidad.
Impacto Técnico
Confidencialidad No hubo filtración de información. 1
La página no fue accesible por motores de
Disponibilidad búsqueda, siendo redireccionado a una tienda 3
de viagra.
Impacto Empresarial
3
Violación a la No hubo violación a la privacidad de

1
163


Motivación Recompensa posible. 3
Tamaño Usuarios anónimos de internet-. 5

Facilidad de
Herramientas automatizadas. 5
descubrimiento
Facilidad de
Herramientas automatizadas. 5
explotación
Conocimiento Obvia. 4
Detección No se mantiene un registro. 5
siguiente fórmula:

164


Tamaño Usuarios de intranet. 3

Facilidad de
Difícil. 2
descubrimiento
Facilidad de
Difícil. 2
explotación
Riesgo (controles_implementados)= 4 (Bajo)

165
5. Ataques que explotaron la vulnerabilidad de Indexación insegura
5.1. Ataques de Abuso de funcionalidad
a) Impacto: Fuga de información
 No almacenar información sensible de no ser necesario. También, se puede descartar
la información ni bien se termine de utilizar. La información que no es retenida no
puede ser comprometida.
estándar potente.
 Deshabilitar el listado de directorios.

166
d) Escenario 25: WHID 2011-229: Yale Social Security Numbers Exposed In Latest
Case Of 'Google Hacking'. Una violación de datos en la Universidad de Yale marcó
un ejemplo de una falla de seguridad expuesta por el "Google Hacking", que implica
consultar al popular motor de búsqueda por vulnerabilidades del sitio web. Mediante
este método, se logró obtener archivos que contienen números de seguro social
167
pertenecientes a trabajadores de esa universidad del año 1999, los cuales ya no debían
ser almacenados.
Impacto Técnico
Se pudo obtener una cantidad considerable de
Confidencialidad 4
números de seguro social.
Integridad No se dañó información de la universidad. 1
No se vieron interrumpidos los servicios de la
Disponibilidad 1
universidad.
Al ser accedido por el motor de búsqueda de
Rastreabilidad Google, cualquier usuario externo podía 5
usarlo y no podían ser rastreados.
Impacto Empresarial
Daño Financiero 4
Daño a la
reputación
Incumplimiento 4
cuidado debido.
4

Los archivos podían ser accedidos por
Nivel de Habilidad usuarios con un conocimiento avanzado en 3
computación.
168
El uso de la información de números de

Motivación seguro social, es posible obtener 3
recompensas.
Oportunidades No requiere acceso al sistema. 5
Al ser accedido por el motor de búsqueda de
Tamaño Google, cualquier usuario externo podía 5
usarlo.

Facilidad de El motor de búsqueda de google descubrió y
5
descubrimiento explotó la vulnerabilidad.
Facilidad de El motor de búsqueda de google descubrió y
5
explotación explotó la vulnerabilidad.
Conocimiento La vulnerabilidad era desconocida. 1
No se mantenían registros acerca de quien
Detección 5
accedía a estos archivos.
siguiente fórmula:

169

Para lograr acceder a los archivos,
Nivel de Habilidad necesitaban tener conocimientos avanzados 5
en computación.
Al no ser capaces de acceder a los archivos,
Motivación 1
la recompensa era muy baja.
Oportunidades Requiere acceso total al sistema. 1
Deben ser desarrolladores o administradores
Tamaño 2
de sistema.

Facilidad de
No se puede encontrar la vulnerabilidad. 1
descubrimiento
Facilidad de Al no poder ser descubierta, no podía ser
1
explotación explotado.
Conocimiento La vulnerabilidad era desconocida. 1
Se mantienen registros y se monitorea los
Detección 2
accesos.
6. Ataques que explotaron la vulnerabilidad de Insuficiente Anti-automatización
6.1. Ataques de Fuerza Bruta

170
a) Impacto: Secuestro de sesión
minutos.
producción.
Según Grassi et al. (2017), buenas medidas y políticas podrían ser:

171
esta lista.
Así mismo, OWASP (2017), propone algunas políticas adicionales:
estándar potente.

172
d) Escenario 26: WHID 2011-20: Hackers Get Access to New Jersey School Data
System. Los usuarios de 4chan lograron acceder al sistema de información en línea
utilizado por un distrito escolar de Nueva Jersey después de que la cuenta de
administrador de la escuela se envió a 4chan (usuario: admin / contraseña:
poopnugget).
Impacto Técnico
Al obtener la cuenta de administrador, se
Confidencialidad pudo obtener una gran cantidad de 4
información sensible.
Integridad 4
gravemente dañada.
Cantidad considerable de servicios primarios
Disponibilidad 4
interrumpidos.
Completamente anónimo, al ser publicado en
Rastreabilidad 5
un foro.
Impacto Empresarial
Daño Financiero 4
Daño a la
reputación
173

Incumplimiento 4
cuidado debido.
4

networking y programación.
Al comprometer la contraseña de
Motivación administrador, se pueden modificar precios y 5
obtener grandes ganancias.

5
5
Detección 4
se monitorea.
siguiente fórmula:
174

networking y programación.
Al comprometer la contraseña de
Motivación administrador, se pueden modificar precios y 5
obtener grandes ganancias.
Oportunidades Requieren acceso total al sistema. 1
Deben ser desarrolladores o administradores
Tamaño 2
de sistema.

Facilidad de No hay forma de realizar ataques fuerza
1
descubrimiento bruta.
Facilidad de No hay forma de realizar ataques fuerza
1
explotación bruta.
No hay forma de realizar ataques fuerza
Conocimiento 1
bruta.
Hay una detección activa al bloquear al
Detección 1
usuario luego de intentos fallidos.

175
7. Ataques que explotaron la vulnerabilidad de Recuperación de contraseña
insuficiente
7.1. Ataques de Abuso de funcionalidad
a) Impacto: Adquisición de cuenta
 A5:2017 Ruptura de control de acceso
 Implementar una suficientemente fuerte política de recuperación de contraseñas. Un
buen ejemplo es el Forgot Password Cheat Sheet de OWASP (2018). En ella, se
indican algunas recomendaciones como:
 Como primer filtro, se deberían indicar preguntas de seguridad propuestas por
el usuario. Cabe decir que las respuestas deben ser escritas (no elegibles) en
html simple.
176
 Utilizar un canal aparte para enviar un token de recuperación. Cabe decir que
este token debe ser enviado a otro medio que no se/a un correo. Puede ser por
SMS, aplicación o cualquier otro medio.
 Se debe cerrar toda sesión activa de usuarios cuando se está recuperando la
contraseña.
 Permitir el cambio de contraseña una vez recuperada la contraseña.
 Mostrar mensajes de errores generales, no específicos. De esta manera se evita
enumeración de usuarios. Esto se debe realizar tanto para el registro, recuperación de
credenciales y APIs.
 Utilizar protocolos seguros (HTTPS), así como también el uso de autenticación de
cliente TLS.
 El control de acceso solo será efectivo si se aplica un código confiable del lado del
servidor o en una API sin servidor, en el cual el atacante no será capaz de modificar la
verificación o los metadatos del control de acceso.
 Configurando la excepción de los recursos públicos, los que deben denegarse de
manera predeterminada.
leer, actualizar o eliminar cualquier registro.

177
 Deshabilitar la lista del directorio del servidor web, asegurando que los metadatos y
backups de los archivos no están presentes en las raíces web.
d) Escenario 27: WHID 2012-299: Hackers breached password security to steal UEA
climate change emails. Se informó de un ataque en el que se aprovechó el deficiente
proceso de recuperación de contraseña para poder acceder al sistema de la
Universidad de Anglia Este. Luego de ello, se logró acceder a documentos
privilegiados, así como también a correos electrónicos de un investigador de alto
rango, sustrayendo no sólo los correos, sino también la investigación realizada por él.
178
Luego de ello, los correos fueron publicados desprestigiando la investigación del
afectado. La investigación fue valuada en £ 85000 (aproximadamente $112000).
Impacto Técnico
Confidencialidad 4
sensible expuesta.
No se vio afectada la funcionalidad de la
Disponibilidad 1
aplicación.
Impacto Empresarial
Efecto significativo en el balance anual, ya
Daño Financiero que el monto de la investigación robada fue 4
valuada en $112000
3

Hubo violación a la privacidad del
Violación a la
investigador para desprestigiar su 2
privacidad
investigación.


Motivación Recompensa posible. 3
179


Facilidad de
Difícil. 2
descubrimiento
Facilidad de
Fácil. 3
explotación
Detección Se mantiene registro pero no se monitorea. 4
siguiente fórmula:


180

Tamaño Desarrolladores o administradores de sistema. 2

Facilidad de
Difícil. 2
descubrimiento
Facilidad de
Teórico. 1
explotación

TESINA - Ricardo Torres Final

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TESINA - Ricardo Torres Final

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS

FACULTAD DE INGENIERÍA ELECTRÓNICA Y ELÉCTRICA

EVALUACIÓN DEL USO DE LA METODOLOGÍA OWASP PARA EL

El presente trabajo evalúa el uso de la metodología propuesta por la organización

Open Web Application Security Project - OWASP para el mejoramiento de la seguridad de

errores que se visualizan en los aplicativos web de diversas universidades.

Dado que siempre se quiere obtener un punto de partida o unas recomendaciones

riesgos a los que se encuentran expuestos las aplicaciones web.

Así mismo, la metodología de calificación de riesgo de OWASP es un documento muy

realizados se basaron en esta metodología.

Finalmente, se observó una mejora significativa en la seguridad de las aplicaciones

web luego de implementadas las recomendaciones y controles, llegando a un porcentaje de

instituciones educativas peruanas a cómo aprovechar la metodología OWASP para mejorar la

seguridad de sus aplicaciones web.

Project - OWASP methodology for the improvement of educational institutions’ web

applications security. This investigation is based on educational institutions due to the

For every developer is always difficult to have a starting point or implement

a large number of risks.

implementing the recommendations and controls, reaching a reduction percentage of up to

Peruvian educational institutions how to take advantage of the OWASP methodology to

improve the security of their web applications.

4.3.1. Población ......................................................................................................................43

Tabla 1. Ranking de países amenazados / países satisfactoriamente atacados. ......................... 4

Figura 1. Exposición de Perú ..................................................................................................... 3

En los últimos años se ha visto que lo concerniente a ciberseguridad y cibercrímenes

un malware del mismo nombre para impedir el arranque de las computadoras.

continua búsqueda de controles, vulnerabilidades y tipos de ataques.

publicada varios meses atrás por organizaciones de seguridad, ha comprometido varias

cantidad de dinero involucrado. Un mecanismo de seguridad que ayude a proteger a estas

instituciones educativas basadas en recomendaciones permitiría proteger los activos de

información de estas instituciones.

1.1. Descripción de la realidad del problema.

relación a los demás países?

Según el informe del Banco Interamericano de Desarrollo, Ciberseguridad ¿Estamos

preparados en América Latina y el Caribe? (BID, 2016):

La ausencia de una estrategia y una cadena de mando clara continúan impidiendo el

fortalecimiento de la seguridad cibernética del país. Las fuerzas armadas también

limitada capacidad técnica para el manejo de evidencia electrónica en los tribunales y

servicios de gobierno electrónico y comercio electrónico continúan expandiéndose en

el Perú, la conciencia social de la seguridad cibernética es generalmente baja. (BID,

Revisando el último informe National Exposure Index (Rapid7, 2017), el Perú se

encuentra en el puesto 29 en nivel de exposición a nivel mundial.

Figura 1. Exposición de Perú

A su vez, un informe realizado por la empresa FireEye, Regional Advanced Threat

comprometido satisfactoriamente y que las prácticas de seguridad de Chile puede ser

más efectivas de lo que aparentan. (FireEye, 2015, p. 4)

Adicionalmente tenemos que tomar en cuenta los diferentes objetivos de los

(Trustwave, 2018), indica:

Los atacantes apuntan a la información confidencial de tarjetas de pago en la mayoría

de los incidentes, comprometiendo la seguridad de las bandas magnéticas de las

tarjetas en un 23% de incidentes, y comprometiendo la información de tarjetas no

presentes (Card not present, CNP), que es mayormente usado en transacciones de

comercio electrónico, en el 20%. Esto es un declive significativo en comparación con

el 2016, cuando los atacantes apuntaron a información de tarjetas en 2 de cada 3

incidentes. Sin embargo, al mismo tiempo, ha habido un aumento en los incidentes

que involucran dinero (11%), principalmente debido a brechas existentes en las

transacciones realizadas en cajeros automáticos fraudulentos, los que están presentes

debido a sistemas vulnerables de gestión de cuentas en las entidades financieras.

(Trustwave, 2018, p. 30)

están causando en las organizaciones.

Figura 2. Compromisos por tipo de dato objetivo.

Figura 3. Métodos de compromiso

ataques más comunes hacia estas aplicaciones web.