Caso Practico Desarrollo Seguro PDF

Caso Práctico Desarrollo Seguro
CASO PRACTICO DESARROLLO

SEGURO IMF
MASTER EN CIBERSEGURIDAD
YEYSON MOYA – DESARROLLO SEGURO
1
Desarrollo Seguro IMF -Yeyson
Moya
Tabla de Contenido
1. INTRODUCCIÓN ............................................................................................................ 3
2. ENUNCIADO ................................................................................................................... 4
3. REQUISITOS ................................................................................................................... 4
4. IDENTIFICACIÓN DE VULNERABILIDADES CON OWASP ZAP ....................... 5
4.1 Preparación de entorno de trabajo ............................................................... 5
4.2 Ejecución de Owasp Zap ............................................................................... 7
4.3 Cantidad de Ocurrencias Identificadas ........................................................ 7
4.4 Clasificación de Vulnerabilidades ................................................................ 7
4.4.1 Nivel de Criticidad............................................................................................... 8
4.4.2 Tipología de Incidencia ..................................................................................... 9
5. EXPLOTACIÓN DE VULNERABILIDADES ............................................................ 14
5.1 Cross-site Scripting: no persistentes, persistentes ............................... 14
5.1.1 Medidas de Prevención Cross - Site ........................................................ 15
5.1.2 Recomendaciones de Seguridad Cross site Scripting ....................... 20
5.2 SQL injection ......................................................................................................... 21
5.2.1 Medidas de Prevención SQL Injection ........................................................ 24
5.2.2 Recomendaciones de Seguridad SQL Injection ....................................... 28
5.3 Exploración de directorios (Directory Browsing) ........................................ 28
5.3.1 Medidas de Prevención Directory Browsing ............................................. 30
5.3.2 Recomendaciones de Seguridad Directory Browsing ............................ 32
5.4 Inyección remota de comandos. ...................................................................... 32
5.4.1 Medidas de Prevención Inyección remota ................................................. 33
5.4.2 Recomendaciones de Seguridad Inyección remota ................................ 35
1. CONCLUSIONES ......................................................................................................... 42
2
Moya
1. INTRODUCCIÓN
Durante las última dos décadas en el entorno empresarial ha tomado fuerza una
locomotora llamada transformación digital que ha llevado a que las empresas
trabajen de manera ágil (a través de metodologías agiles,) con el objetivo de
desarrollar productos o servicios que generen valor no solo para la organización si
no también a sus clientes, estos productos deben ser desarrollados en tiempos
cortos, tener factores de innovación digital, que optimicen procesos y sobre todo
que brinden una experiencia agradable para el usuario final, algunas de estas
soluciones ha sido el desarrollo de aplicaciones de software convirtiéndose en
herramientas potenciales para las empresas y personas, generando la
transformación de datos en cantidades incontables, permitiendo millones de
transacciones a cualquier hora y desde cualquier sitio conectado a internet,
almacenando información de diferentes categorías en materia de sensibilidad,
convirtiéndolas en un objetivo exquisito para los ciberdelincuentes, por lo cual ya en
el ciclo de vida del desarrollo no solo es importante validar el cumplimiento de los
requisitos funcionales , si no también dar importancia a requisitos no funcionales e
integrar la seguridad desde las fases de diseño de las aplicaciones, empleando
referencias de desarrollo seguro, ejecutando modelado de amenazas a los
componentes de arquitectura ejecutando análisis de vulnerabilidades tanto de
componentes web como de arquitectura.
A continuación, se detalla un caso práctico de la identificación de vulnerabilidades de

una aplicación, la manera de realizar una explotación de las mismas y las
recomendaciones que se pueden emplear a nivel de desarrollo y buenas prácticas
de seguridad.
3
Moya
2. ENUNCIADO
Para poder realizar el ejercicio, se utilizará la aplicación Wackopicko.
Puedes encontrar esta aplicación en la máquina virtual de Vulnerable Web

Apps.
3. REQUISITOS
• Identificar todas las vulnerabilidades que tiene la aplicación utilizando una

herramienta semiautomática como Vega u OWASP Zap.
• Como resultado de este ejercicio, se mostrará, por una parte, la cantidad
de ocurrencias identificadas y clasificadas según su nivel y, por otra, la
clasificación de todas estas ocurrencias en tipologías de vulnerabilidades.
• Explotar las vulnerabilidades e indicar cómo se ha explotado cada

vulnerabilidad y cuál ha sido el resultado (adjuntando capturas de
pantalla).
• Proponer, al menos, una medida de prevención para cada vulnerabilidad

analizada (se entienden como medidas de prevención las modificaciones
en el código donde se encuentra el problema). Asimismo, se podrán
indicar medidas adicionales sobre buenas prácticas de seguridad relativas
a la tipología de la vulnerabilidad.
4
Moya
4. IDENTIFICACIÓN DE VULNERABILIDADES CON OWASP ZAP

4.1 Preparación de entorno de trabajo
Para la identificación de vulnerabilidades se utilizó la maquina virtual
renombrada como vulnerable Web Apps, descargada del sitio relacionado en
el caso práctico, adicional una maquina virtual de Kali Linux, donde se
encuentra instalada la herramienta semiautomática OWASP ZAP.
Ilustración 1. Máquina Virtual Vulnerable Web Apps
Ilustración 2. Dirección IP máquina Virtual - Vulnerable web apps
5
Moya
Ilustración 3. Redes Máquina virtual
Ilustración 4. Acceso a Wacko Picko desde Kali
6
Moya
4.2 Ejecución de Owasp Zap
Ilustración 5.Ejecución de análisis sobre la url
4.3 Cantidad de Ocurrencias Identificadas

Según el resultado del análisis se encontraron 15 Alertas
Tabla 1. Alertas encontradas
4.4 Clasificación de Vulnerabilidades
Al realizar el análisis se encontraron diferentes vulnerabilidades las cuales están

clasificadas de la siguiente manera:
7
Moya
4.4.1 Nivel de Criticidad
HIGH - 5
Tabla 2.Vulnerabilidades High
MEDIUM – 3
Tabla 3. Vulnerabilidades Medium
LOW - 6
Tabla 4. Vulnerabilidades Low
INFORMATIONAL 1
Tabla 5. Vulnerabilidad Informational
8
Moya
4.4.2 Tipología de Incidencia
Tipo de Incidencia Detalle
Cross-site Scripting: no persistentes, Cross-site Scripting (XSS) es una

persistentes y basados en DOM. técnica de ataque que consiste en hacer
eco del código proporcionado por el
atacante en la instancia del navegador
de un usuario.
Comprometen la relación de confianza
entre un usuario y el sitio web.
Los ataques no persistentes y los
ataques basados en DOM requieren que
un usuario visite un enlace
especialmente diseñado con código
malicioso o visite una página web
maliciosa que contenga un formulario
web, que cuando se publique en el sitio
vulnerable, montará el ataque.
Los ataques persistentes ocurren
cuando el código malicioso se envía a
un sitio web donde se almacena durante
un período de tiempo.
Tabla 6. Cross - Site

Inyección remota de comandos del Técnica de ataque utilizada para la
sistema operativo. ejecución no autorizada de comandos del
sistema operativo. Este ataque es posible
cuando una aplicación acepta entradas
que no son de confianza para crear
comandos del sistema operativo de
manera insegura, lo que implica una
desinfección de datos inadecuada y/o
una llamada incorrecta de programas
externos.
Tabla 7. Remote OS Comand injection
9
Moya

SQL Injection Permite al atacante enviar o “inyectar”
instrucciones SQL de forma maliciosa y
malintencionada dentro del código SQL
programado para la manipulación de
bases de datos.
Tabla 8. Sql Injection

Exploración de directorios La lista de directorios puede revelar
secuencias de comandos ocultas, incluir
archivos, archivos fuente de copia de
seguridad, etc., a los que se puede
acceder para leer información
confidencial.
Tabla 9. Directory Browsing

Manipulación de parámetros La manipulación de parámetros provocó
que se mostrara una página de error o un
seguimiento de pila de Java. Esto indicó
la falta de manejo de excepciones y
áreas potenciales para una mayor
explotación.
Tabla 10. Parameter Tampering
10
Moya

X-Frame-Options Header Not Set El encabezado X-Frame-Options no
está incluido en la respuesta HTTP
para proteger contra los ataques de
'ClickJacking'.
Tabla 11. X Frame

Absence of Anti-CSRF Tokens No se encontraron tokens Anti-CSRF
en un formulario de envío HTML.
Una falsificación de solicitud entre sitios
es un ataque que implica obligar a una
víctima a enviar una solicitud HTTP a
un destino objetivo sin su conocimiento
o intención para realizar una acción
como víctima
Tabla 12. Absence Of Anti CSRF

Cookie No HttpOnly Flag Se ha configurado una cookie sin el
indicador HttpOnly, lo que significa que
JavaScript puede acceder a la cookie.
11
Moya
Si se puede ejecutar un script

malicioso en esta página, se podrá
acceder a la cookie y se podrá
transmitir a otro sitio. Si se trata de una
cookie de sesión, es posible que se
produzca un secuestro de sesión.
Tabla 13.Cookie No HttpOnly Flag

Cookie without SameSite Attribute Se ha configurado una cookie sin el
atributo SameSite, lo que significa que
la cookie se puede enviar como
resultado de una solicitud de 'entre
sitios'. El atributo SameSite es una
contramedida eficaz para la
falsificación de solicitudes entre sitios,
la inclusión de secuencias de
comandos entre sitios y los ataques de
tiempo.
Tabla 14. Cookie Without SameSite

Server Leaks Information via "X-Powered- El servidor web/de aplicaciones está
By" HTTP Response Header Field(s) filtrando información a través de uno o
más encabezados de respuesta HTTP
"X-Powered-By". El acceso a dicha
información puede facilitar a los
atacantes la identificación de otros
marcos/componentes de los que
depende su aplicación web y las
vulnerabilidades a las que dichos
componentes pueden estar sujetos.
Tabla 15. Server Leaks Information

Timestamp Disclosure – Unix Una marca de tiempo fue revelada por
la aplicación/servidor web - Unix
12
Moya
Tabla 16. Timestamp Disclosure – Unix

X-Content-Type-Options Header Missing El encabezado Anti-MIME-Sniffing X-
Content-Type-Options no se configuró
en 'nosniff'. Esto permite que las
versiones anteriores de Internet
Explorer y Chrome realicen un rastreo
MIME en el cuerpo de la respuesta, lo
que podría causar que el cuerpo de la
respuesta se interprete y muestre
como un tipo de contenido diferente al
tipo de contenido declarado. Las
versiones actuales (principios de 2014)
y heredadas de Firefox utilizarán el
tipo de contenido declarado (si se ha
configurado uno), en lugar de realizar
un análisis MIME.
Tabla 17 X -Content Type

Information Disclosure - Sensitive Information in La solicitud parecía contener
URL información confidencial filtrada en la
URL. Esto puede violar PCI y la
mayoría de las políticas de
cumplimiento de la organización.
Puede configurar la lista de cadenas
para esta verificación para agregar o
eliminar valores específicos de su
entorno.
Tabla 18. Information Disclosure
13
Moya
5. EXPLOTACIÓN DE VULNERABILIDADES
Tras la identificación y clasificación de vulnerabilidades, se procede a realizar la
explotación de las vulnerabilidades, así mismo se establecen medidas de
prevención y recomendaciones de seguridad.
5.1 Cross-site Scripting: no persistentes, persistentes

http://192.168.243.129:81/guestbook.php
Al ingresar a la Url http://192.168.243.129:81/guestbook.php. se llama a una

página php y se obtiene la siguiente alerta:
Tabla 19. Guestbook.php

El script permanece oculto tras un comentario y se ejecuta cada vez que se accede
a esta ventana, este escenario daría paso al robo de cookies a través de un script
que consulte a una página alojada en un servidor interno pasando la cookie
14
Moya
Un comportamiento similar se presenta al realizar la búsqueda de la siguiente url:

http://192.168.243.129:81/pictures/search.php?query=%22%3E%3CscrIpt%3Eal
ert%281%29%3B%3C%2FscRipt%3
El parámetro de consulta no se sanea antes de enviarlo al usuario, por lo cual en la

Url se procede a introducir el siguiente código:
<script>alert("Prueba")</script>, en el cual se envia una alerta con el texto
“Prueba”, en el campo search, ejecutándose si de manera correcta obteniendo el
siguiendo resultado.
Ilustración 6. Ejecución de Código en el search
Al ejecutarse la cadena de código, se muestra un mensaje de alerta para el usuario,

para un atacante, la aprovecharía para realizar alguna actividad maliciosa en lugar
de alertar a la víctima.
5.1.1 Medidas de Prevención Cross - Site

Como se pudo observar, la mayoría de campos en los que el usuario puede
introducir texto, existe la ausencia de filtros en las entradas de datos, por lo cual se
15
Moya
evidencia la vulnerabilidad, dando paso a ataques XSS los cuales podrán

modificar el comportamiento normal de la aplicación ya sea mediante la inyección de
código conduciendo a redirecciones transparentes y robo de sesión.
A continuación, se relacionan las medidas de prevención que aplican para los
escenarios identificados:
✓ Introducir la cabecera de seguridad: “Header set X-XSS-Protection”1;
mode=block”.
Esta medida de prevención habilita el filtrado XSS (generalmente predeterminado en
los navegadores). Si se detecta un ataque de secuencias de comandos entre sitios,
el navegador desinfectará la página (eliminará las partes inseguras).
Para este caso, el valor 1; mode=block en lugar de desinfectar la página, el
navegador evitará la representación de la página si se detecta un ataque.
Para introducir la cabecera se editó el contenido del archivo de configuración de

Apache ingresando a la máquina virtual Vulnerable Web Apps en el directorio
etc/apache2/apache2
Activación del mod_headers haciendo uso de a2enmod headers
Ilustración 7.a2enmod Headers
Luego se procede a insertar la cabecera Header set X-XSS-Protection”1;

mode=block” modificando el archivo de configuración: /conf-
enabled/security.conf
Ilustración 8. Ajuste security.conf
16
Moya
Así mismo se activa las cabeceras existentes (Comentariadas) en el archivo: X-

Content-Type-Options: “nosniff1” la cual bloquea la detección de contenido que
podría transformar los tipos MIME no ejecutables en tipos MIME ejecutables y X-
Frame-Options SAMEORIGIN que previene los ataques de clickjacking.
Tras realizar el ajuste en el archivo, se consulta en el navegador a través del inspect

el headers con el fin de validar la habilitación de las cabeceras.
Ilustración 9.header search.php
Según las validaciones se puede observar que en la nueva cabecera están

habilitados los filtros X-Content-Type-Options, X-Frame-Options y X-XSS-Protection.
✓ Sanear y Escapar datos
Posterior a la habilitación de la cabecera se recomienda eliminar las Tags html que
puedan ingresar en los cuadros de texto, a través del uso de de strip_tags(retira las
etiquetas HTML y PHP de un string)
17
Moya
Código search.php original
Ilustración 10. Search.php
Código editado $query=$_GET['query']; $query=strip_tags($query);
Ilustración 11. Strip_tags
18
Moya
Tras el ajuste realizado se procede a realizar la prueba en el campo search, según

datos ingresados.
Para finalizar se realizó otro ajuste al código fuente para escapar los datos(evitar
mostrar los caracteres extraños en la respuesta de la página, a través del uso de la
función Htmlentities($_GET[‘query’]) la cual es idéntica a htmlspecialchars() en
todos los aspectos, excepto que con htmlentities(), todos los caracteres que tienen
su equivalente HTML son convertidos a estas entidades.
Código Original search.php
Ilustración 12. $Get['query´^]
Código editado htmlentities
Ilustración 13.Hmlentities
Tras los ajustes realizados se procede a realizar las pruebas se insertando en el

campo search el scritp de prueba para el robo de sesión , tambien la cadena
inyección “Prueba”, la cuales no se ejecutan
19
Moya
Ilustración 14. prueba Script
Ilustración 15 . Cadena ¨Prueba)
Cabe resaltar que las modificaciones se realizaron en /pictures/search.php que, las

medidas de prevención aplicadas, se pueden ejecutar para los casos en los que el
usuario introduzca texto.
5.1.2 Recomendaciones de Seguridad Cross site Scripting
.
• Nunca utilizar directamente los datos proporcionados por el navegador ($_GET,
$_POST). Siempre purifique estos datos antes de procesarlos.
• Validar todas las entradas de formulario.

• Filtrar los caracteres especiales.
• Limitar los caracteres de entrada.
• Programar filtrando determinados comandos.
• Envío de mensajes disuasorios de alerta, cuando se detecte un ataque
20
Moya
5.2 SQL injection
Ilustración 16.SQL injection
La aplicación contiene una vulnerabilidad de inyección SQL en el formulario de

inicio de sesión, para lo cual se Ingresa un caracter de escape en el nombre de
usuario con el fin de evidenciar el comportamiento
Para este caso se utiliza '
Ilustración 17. Carácter rompedor
La cual arroja el siguiente error:
Ilustración 18. Error
Lo que indica que el carácter se puede introducir, según el error, las entradas que
se digiten en el campo del usuario se pasan sin ningún tipo de saneamiento y la
contraseña (pass) se modifica con SAL y se encripta con SHA1.
Según el análisis del error se puede deducir que la consulta que se realiza a la base
de datos es select * from users where (username=’ $user ’ and password=’ $pass ’);
Por otra parte, realizando la prueba de añadir el caracter comilla simple al final de la
cadena, estableciendo una condición con el último carácter limpio la respuesta es la
siguiente:
21
Moya
Ilustración 19. user' and '1'='1
select * from users where (username=’user’ and ‘1’=’1’ and password=’ $pass ’);
El usuario ha ingresado con la consulta completa, pero la validación de contraseña
sigue ejecutándose, para evitar este comportamiento se utiliza el comentario
Antes de modificar la consulta, se ingresa a la siguiente url:
192.168.243.129: 81/users/sample.php?userid=
Con el fin de identificar usuarios creados, lo cual lo podemos consultar con valores
numéricos como se muestra en las siguientes imágenes:
Ilustración 20. userid=1
22
Moya
Tabla 20. Consulta Perfiles
Posterior a la consulta de usuarios creados, la sentencia será

select * from users where (username=’scanner1’ -- ’ and password=’$pass’);
De esta manera se omite la parte de la consulta en la que se requiere una
contraseña para ingresar en la aplicación, entonces se puede iniciar sesión a través
de uno de los usuarios consultados
Ilustración 21. Acceso scanner 1
23
Moya
5.2.1 Medidas de Prevención SQL Injection

En la validación del código en el archivo user.php .se evidencia que la primera
solicitud es vulnerable a inyección SQL, ya que solo desinfecta la contraseña.
Tabla 22/include/users.php.
Según el script /user/login. Php , las entradas del usuario se pasan a la función, sin
ningún tipo de sanamiento.
Tabla 23.login.php
Para corregir este escenario se da paso a utilizar la función

mysql_real_escape_string() para “username”
Tabla 24.user.php
24
Moya
Tabla 25. Código Original
Tabla 26. Ajuste
También se puede evitar escapar los caracteres extraños usando el htmlentities que
se utilizó anteriormente
25
Moya
Después de los ajustes, cuando se realiza la prueba de introducir un carácter de

escape en la página de login, se observa un comportamiento diferente y no se
puede acceder solo con el usuario como se hacia antes.
Tabla 27. Ingreso de Caracter de escape
26
Moya
Tabla 28. Comportamiento después del ajuste
Ilustración 21. Validación Ajustes
27
Moya
5.2.2 Recomendaciones de Seguridad SQL Injection
• Filtrar los datos de entrada, rechazar las peticiones con caracteres

especiales
• Utilizar funciones como mysql_escape_string() o addslashes().
• Convertir siempre el valor a su tipo correspondiente
• Parametrizar las consultas SQL
• No mostrar al usuario la información de error generada por la base de datos
•
5.3 Exploración de directorios (Directory Browsing)
Según el resultado del scanner de Owas Zap, se evidencian diferentes directorios

(11) que al consultarlos permite visualizar su contenido, si este contenido no es
controlado podría afectarse la confidencialidad de la información que allí se
almacena.
28
Moya
Ilustración 22, directorios encontrados
Para el ejercicio se navego en cada uno de los directorios y en uno de ellos se

encontró información relacionada a la base de datos
29
Moya
Ilustración 23. Directorio Include
Ilustración 24.ourdb.php
5.3.1 Medidas de Prevención Directory Browsing

Para corregir este escenario se puede deshabilitar la funcionalidad que permite ver
los directorios cuando no hay un archivo de tipo Index, esto a través de la
modificación del archivo de configuración de Apache.
Ilustración 25. Ruta del archivo a modificar
30
Moya
Ilustración 26, Ajuste archivo de configuración
Ilustración 27. Restart Service
Tras realizar el ajuste se procede a realizar la prueba accediendo a los directorios
Ilustración 28. /cart
31
Moya
Ilustración 29./css
5.3.2 Recomendaciones de Seguridad Directory Browsing
• Crear un archivo index.html en blanco dentro del directorio del cual no

queremos que se visualice el contenido.
• Modificar el archivo .htaccess de la raíz (Options -Indexes) consiguiendo que

no se liste ningún directorio.
• También se puede evitar que se listen unos determinados archivos en

concreto según su extensión (IndexIgnore *.php *.html).
5.4 Inyección remota de comandos.
Ilustración 30. Remote Os Command Injection
La aplicación ofrece la funcionalidad de validar la contraseña, haciendo uso del

comando grep y compara con el archivo /etc/dictionaries-common/words.
Ilustración 31.Password to check
32
Moya
Ilustración 32. Password to check
Esto indica que se pueden ejecutar comandos, al realizar la prueba de esta

vulnerabilidad, se ejecuta el siguiente comando: qazwsx|mkdir
./upload/oscommandinjection#, al realizar la validación en el servidor se evidencia
el llamado al directorio oscommandinjection#
Ilustración 33. oscommandinjection#
Tras la prueba anterior, se procede a realizar una nueva prueba enviando el

comando sleep 20, para inhabilitar el servidor durante 20 segundos obteniendo
resultados exitosos.
5.4.1 Medidas de Prevención Inyección remota

Para evitar esta vulnerabilidad se debe realizar una correcta validación de los
parámetros introducidos por el usuario, evitando utilizar llamadas a comandos del
sistema directamente ya sea empleando funciones como system(), y escapar los
caracteres especiales con escapeshellcmd().
33
Moya
Teniendo en cuenta lo anterior se procede a editar el archivo passcheck.php de la

siguiente manera:
Ilustración 34. Archivo Original
Ilustración 35 Ajuste realizado.
Tras el ajuste realizado, se procede a ejecutar el comando utilizado anteriormente
34
Moya
qazwsx|mkdir ./upload/oscommandinjection#, al realizar la validación se puede

evidenciar que el directorio no fue creado.
Ilustración 36. Ejecución del comando
Otra acción que se puede realizar es deshabilitar el uso de funciones categorizadas

como peligrosas en el archivo php.ini a través de la funcionalidad: Disable
functions
Ejemplo:
disable_functions=exec,passthru,shell_exec,system,proc_open,popen,curl_ex
ec,curl_multi_exec,parse_ini_file,show_source
Ilustración 37. Disable functions
5.4.2 Recomendaciones de Seguridad Inyección remota
• Controlar y filtrar la entrada de datos del usuario

• Evita a toda costa las llamadas al sistema, la mayoría de las veces es posible
no utilizarlas
• No ejecutar la aplicación como administrador ,los comandos siempre se
ejecutan con los permisos del usuario que inició la aplicación. Así, si un
atacante logra ejecutar comandos, lo hará como un usuario de menores
privilegios y podrás reducir considerablemente sus ataques.
35
Moya
5.5 Manipulación de parámetros

La manipulación de parámetros provocó que se mostrara una página de error o un
seguimiento de la pila de Java. Esto indica la falta de manejo de excepciones y
áreas potenciales para una mayor explotación.
Para validar la explotación de la vulnerabilidad, se procede a utilizar la url utilizada

anteriormente en el caso de SQL injection
192.168.243.129: 81/users/sample.php?userid=
Userid al tener un valor de numero entero, permitirá identificar los nombres de los
perfiles de los usuarios. Con esta información un cibercriminal podría a travésde
técnicas de fuerza bruta obtener la contraseña.
User id Nombre Evidencia

10 calvinwatters
11 bryce
9 wanda
8 scanner5
7 scanner4
36
Moya
6 scanner3
5 scanner2
4 scanner1
2 bob
1 Sample User
Tabla 29 . User id Consutados
5.5.1 Medidas de Prevención Manipulación de parámetros

Para esta vulnerabilidad se debe evitar que los parámetros se puedan incluir en una
consulta / en formularios ocultos, los parámetros que deban ser enviados desde el
cliente al servidor deberán ser acompañados por un validador, que se pueden
almacenar en la cookie de sesión del usuario.
Adicional se puede establecer mecanismos de encriptación(MD5) para que los
parámetros a pesar de que se puedan ver , no sean legibles, ósea que el valor no
sea leído o reemplazado.
5.5.2 Recomendaciones de Seguridad Modificación de parámetros
• Impedir la navegación por páginas que estén bajo la raíz de la página Web
• Deshabilitar la visualización de los archivos de un directorio que no contiene
un archivo índice
• Eliminar directorios y archivos inservibles (incluso los ocultos)
• Asegurarse de que el servidor proteja el acceso a directorios que contienen
datos importantes
• Eliminar las opciones de configuración innecesarias
37
Moya
• Asegurarse de que el servidor interprete las páginas dinámicas con precisión,

incluso archivos de copias de seguridad (.bak);
• Eliminar los intérpretes de secuencias de comandos innecesarios;
• Impedir la visualización HTTP en páginas HTTPS accesibles
5.6 Cookie No HttpOnly Flag.
Se ha configurado una cookie sin el indicador HttpOnly, lo que significa que
JavaScript puede acceder a la cookie.
Ilustración 38. Cookie No HttpOnly Flag
Tabla 30.
Para aprovechar esta vulnerabilidad se podría ejecutar un script malicioso para

acceder a la cookie y transmitirlo a otro sitio.
5.6.1 Medidas de prevención Cookie No httpOnly Flag
Para evitar la materialización de esta vulnerabilidad se procede a modificar el
archivo /etc/apache2/confenabled/ security.conf, agregando la siguiente línea de
código: Header always set Set-Cookie HtppOnly.
Set-Cookie: La cabecera de respuesta HTTP Set-Cookie se usa para enviar
cookies desde el servidor al agente de usuario, así el agente de usuario puede
enviarlos de vuelta al servidor.
HttpOnly: Impide que el código JavaScript acceda a la cookie.
38
Moya
Ilustración 39. Header always set Set-Cookie HtppOnly.
5.6.2 Recomendaciones de Seguridad Cookie HttpOnly Flag
• Asegurarse de que el indicador HttpOnly esté configurado para todas las

cookies.
• Probar navegadores web para compatibilidad con HttpOnly, el uso de la
marca HttpOnly al generar una cookie ayuda a mitigar el riesgo de que el
script del lado del cliente acceda a la cookie protegida (si el navegador lo
admite).
5.7 Cookie without SameSite Attribut
Ilustración 40. Cookie without SameSite Attribut
Se ha configurado una cookie sin el atributo SameSite, lo que significa que la cookie
se puede enviar como resultado de una solicitud de 'entre sitios'.
39
Moya
5.7.1 Medidas de prevención Cookie without SameSite Attribut

Para corregir esta vulnerabilidad se procede a modificar el archivo
/etc/apache2/confenabled/ security.conf, agregando la siguiente línea de código:
Header always set Set-Cookie SameSite
Ilustración 41.Header always set Set-Cookie SameSite
5.7.2 Recomendaciones de seguridad Cookie without SameSite Attribut
• Asegurarse de que el atributo SameSite esté configurado como 'lax' o,

idealmente, 'estrict' para todas las cookies
Same-site: strict, no envía ninguna cookie en las peticiones que se realizan

desde sitios diferentes a donde se originaron.
Same-site: lax, similar al modo strict, pero las cookies si que se envían cuando
es el usuario el que realiza la petición externa de manera consciente, por
ejemplo al pinchar en un enlace o enviar un formulario que use el método GET
de HTTP.
40
Moya
5.8 Server Leaks Information via "X-Powered-By" HTTP Response Header Field(s))
Ilustración 42. X Powered By
El servidor web/de aplicaciones está filtrando información a través de uno o más

encabezados de respuesta HTTP "X-Powered-By" lo que puede facilitar a un
cibercriminal identificar otros marcos/componentes de los que depende la aplicación
web y las vulnerabilidades a las que dichos componentes pueden estar sujetos.
• 5.8.1 Medidades de prevención Server Leaks Information via "X-Powered-

By" HTTP Response Header Field(s))
Para corregir esta vulnerabilidad se procede a modificar el archivo php.ini para
deshabilitar la directiva de exposición expose.php la cual de forma predeterminada
está habilitada (expose_php = On)Con la directiva de exposición_php deshabilitada,
PHP no enviará el encabezado X-Powered-By.
Ilustración 43.php.ini original
41
Moya
Ilustración 44.expose_php ajuste
Ilustración 45.header después del ajuste
5.8.2 Recomendaciones de Seguridad Server Leaks Information via "X-Powered-

By" HTTP Response Header Field(s))
• Asegurarse de que el servidor web, servidor de aplicaciones, equilibrador

de carga, etc. esté configurado para suprimir los encabezados "X-
Powered-By"
6. CONCLUSIONES
Actualmente en Internet encontramos millones de sitios web que nos ofrecen
productos o servicios, así mismo las organizaciones tienen sistemas de información
aplicaciones móviles, aplicaciones locales, para manejar sus procesos de gestión
humana, operaciones financieras, ventas, procesos operacionales etc., las
entidades del gobierno manejan software de infraestructuras críticas, servicios
públicos procesos electorales, registro de identidades, procesos judiciales etc.,
convirtiendo estas aplicaciones imprescindibles, albergando información esencial y
relevante para su operación.
Al ser tan importante estas aplicaciones los profesionales que se desempeñan en
áreas de operaciones (TI) ,Desarrolladores, especialistas de seguridad deben
42
Moya
enfocarse en implementar procesos de SSDCL (Security Software Development

Life Cycle), en las organizaciones, adecuar metodologías agiles y adquirir la cultura
del DevSecOps para que se empiece a revisar los controles de seguridad desde las
fases de diseño y no solo antes de pasar a producción, utilizando herramientas de
análisis de código estático y dinámico , estableciendo controles en la gestión de
secretos, directorios y configuraciones en los pipelines , ejecutando análisis de
vulnerabilidades tanto de componentes web como de infraestructura de red, así
mismo implementar controles en cada una de las capas del modelo OSI para tener
un enfoque de defensa en profundidad y reducir la superficie de ataque de estas
aplicaciones.
Adicional a lo mencionado es importante gestionar que los desarrolladores, reciban
capacitaciones de buenas prácticas de seguridad, de herramientas para el análisis
de código, que conozca las políticas de desarrollo de software establecidas por la
organización y que los roles y perfiles establecidos sean analizados por las áreas de
gestión del riesgo para evitar fraudes y accesos no autorizados.
Las medidas mencionadas anteriormente pueden reducir el riego de tener
aplicaciones en ambientes productivos expuestas a la explotación de
vulnerabilidades.
43
Moya

Caso Practico Desarrollo Seguro PDF

Cargado por

Copyright:

Formatos disponibles

Caso Practico Desarrollo Seguro PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Caso Practico Desarrollo Seguro PDF

Cargado por

Copyright:

Formatos disponibles

Caso Práctico Desarrollo Seguro

CASO PRACTICO DESARROLLO

A continuación, se detalla un caso práctico de la identificación de vulnerabilidades de

Para poder realizar el ejercicio, se utilizará la aplicación Wackopicko.

Puedes encontrar esta aplicación en la máquina virtual de Vulnerable Web

• Identificar todas las vulnerabilidades que tiene la aplicación utilizando una

• Explotar las vulnerabilidades e indicar cómo se ha explotado cada

• Proponer, al menos, una medida de prevención para cada vulnerabilidad

4. IDENTIFICACIÓN DE VULNERABILIDADES CON OWASP ZAP

Ilustración 1. Máquina Virtual Vulnerable Web Apps

Ilustración 2. Dirección IP máquina Virtual - Vulnerable web apps

Ilustración 3. Redes Máquina virtual

Ilustración 4. Acceso a Wacko Picko desde Kali

4.2 Ejecución de Owasp Zap

Ilustración 5.Ejecución de análisis sobre la url

4.3 Cantidad de Ocurrencias Identificadas

Tabla 1. Alertas encontradas

4.4 Clasificación de Vulnerabilidades

Al realizar el análisis se encontraron diferentes vulnerabilidades las cuales están

4.4.1 Nivel de Criticidad

Tabla 2.Vulnerabilidades High

Tabla 3. Vulnerabilidades Medium

Tabla 4. Vulnerabilidades Low

Tabla 5. Vulnerabilidad Informational

4.4.2 Tipología de Incidencia

Tipo de Incidencia Detalle

Cross-site Scripting: no persistentes, Cross-site Scripting (XSS) es una

Tipo de Incidencia Detalle

Tipo de Incidencia Detalle

Tipo de Incidencia Detalle

Tabla 9. Directory Browsing

Tipo de Incidencia Detalle

Tabla 10. Parameter Tampering

Tipo de Incidencia Detalle

Tabla 11. X Frame

Tipo de Incidencia Detalle

Tabla 12. Absence Of Anti CSRF

Tipo de Incidencia Detalle

Si se puede ejecutar un script

Tipo de Incidencia Detalle

Tipo de Incidencia Detalle

Tabla 15. Server Leaks Information

Tipo de Incidencia Detalle

Tabla 16. Timestamp Disclosure – Unix

Tipo de Incidencia Detalle

Tipo de Incidencia Detalle

5.1 Cross-site Scripting: no persistentes, persistentes

Al ingresar a la Url http://192.168.243.129:81/guestbook.php. se llama a una

Tabla 19. Guestbook.php

Un comportamiento similar se presenta al realizar la búsqueda de la siguiente url:

El parámetro de consulta no se sanea antes de enviarlo al usuario, por lo cual en la

Ilustración 6. Ejecución de Código en el search

Al ejecutarse la cadena de código, se muestra un mensaje de alerta para el usuario,

5.1.1 Medidas de Prevención Cross - Site

evidencia la vulnerabilidad, dando paso a ataques XSS los cuales podrán

Para introducir la cabecera se editó el contenido del archivo de configuración de

Ilustración 7.a2enmod Headers

Luego se procede a insertar la cabecera Header set X-XSS-Protection”1;

Ilustración 8. Ajuste security.conf