DEFINIR LAS POLÍTICAS DE SEGURIDAD

David Fernando Torres Burgos

Deyby Waldy Martínez Sanabria
Camila Sanchez Amaya

Septiembre 2019

Fundación Universitaria Del Área Andina

Ingeniería de Sistemas
Modelos de Programación II
Grupo 43
 INTRODUCCIÓN

El presente trabajo se realizó teniendo en cuenta la problemática presentada en el trabajo a

entregar, a continuación exponemos en el siguiente documento las estrategias principales para
disminuir los riesgos de seguridad en el desarrollo de las aplicaciones web, considerando las
buenas prácticas y estándares deducidos por los entes de control o comunidades que se dedican a
la investigación de las diversas vulnerabilidades o estrategias de ataques a las que están
expuestas dichas aplicaciones actualmente, con el fin de dar un buen manejo al flujo de
información y mitigar los riesgos de las mismas.
 OBJETIVO

Exponer las vulnerabilidades comunes y apropiar conocimientos de defensa siguiendo patrones

de programación seguros y estándares de seguridad para disminuir el riesgo de pérdida de
información confidencial de nuestras aplicaciones web.

Identificar la buenas prácticas para desarrollar aplicaciones web seguras.

Definir la estrategia para brindar las técnicas, herramientas, políticas y protocolos que le
garanticen la seguridad necesaria de una aplicación web .
 DESARROLLO

Una cooperativa desea crear una aplicación web para que sus usuarios puedan realizar sus
transacciones on line (consultas, aportes, retiros, actualizaciones, descarga de certificados,
extractos, etc.). Usted ha sido la persona seleccionada para crear una estrategia que
pueda brindar las técnicas, herramientas, políticas y protocolos que le garanticen la seguridad
necesaria para su buen funcionamiento.

A continuación se muestran las estrategias seleccionadas para realizar pruebas de seguridad a

nuestras aplicaciones web para así entender los métodos comunes de intrusión y tratar de buscar
fuentes de prevención contra estos :

Buenas prácticas para desarrollar aplicaciones web seguras.

Primer paso es establecer requerimientos y controles de seguridad para el ciclo de vida de

desarrollo de software, los cuales deben ser medibles.

Fase requerimientos:

- Control de autenticación.
- Control de roles y privilegios.
- Requerimientos orientados al riesgo.
- Aprobación de privilegios.

Fase análisis y diseño:

- Acceso a componentes y administración del sistema.

- Pistas de auditoría.
- Gestión de sesiones.
- Datos históricos.
- Manejo apropiado de errores.
- Separación de funciones.

Fase de implementación y codificación:

- Aseguramiento del ambiente de desarrollo.

- Elaboración de documentación técnica.
- Codificación segura.
- Seguridad en las comunicaciones.
 - Seguridad en promoción de ambientes de producción.

Codificación Segura, Buenas prácticas:

- Validación de entradas.
- Codificación de Salidas.
- Estilo de Programación.
- Manejo de Log de cambios.
- Prácticas Criptográficas.
- Manejo de errores y Logs.
- Manejo de archivos.
- Manejo de memoria.
- Estandarización y reutilización.
- Funciones de Seguridad.

Fase de Pruebas:

- Control de calidad en controles de seguridad.

- Inspección de código por fases.
- Comprobación de gestión de configuraciones.
- Caja negra (Top Ten de OWASP).
- Fase de Mantenimiento.

Aseguramiento basado en Riesgos

- Pruebas de seguridad(caja blanca y caja negra) después de los cambios.

Verificación de protección de datos

- Verificar que se haya desactivado el almacenamiento de caché en el cliente incluyendo

las funciones de autocompletar.
- Verificar que la lista de datos sensibles procesados por la aplicación se encuentre
identificada y que existe una política explícita de cómo debe controlarse el acceso a estos
datos, deben cifrarse y reforzarse bajo las directivas de protección de datos pertinentes.
- Verificar que toda la información sensible se envíe al servidor en el cuerpo o cabeceras
de mensaje HTTP(por ejemplo, los parámetros de la URL no se deben usar para enviar
datos sensibles).
- Verificar que en el servidor todas las copias almacenadas en caché o temporales de datos
sensibles estén protegidos de accesos no deseados o son purgados/invalidados después
del acceso de un usuario con autorización.
 - Verificar que existe un mecanismo para eliminar de la aplicación todo tipo de dato
sensible luego de transcurrido el tiempo definido por la política de retención.
- Verificar que la aplicación reduzca al mínimo el número de parámetros en una solicitud,
como campos ocultos variables de Ajax, cookies y valores en encabezados.
- Verificar que la aplicación tenga la capacidad para detectar y alertar sobre un número
anormal de solicitudes para recolección de datos por medio de extracción de pantalla.
- Verificar que los datos almacenados en el cliente(como almacenamiento local de
HTML5, almacenamiento de la sesión, indexedDB, cookies normales o las cookies de
flash) no contengan información sensible o información personal identificable.
- Verificar que el acceso a datos sensibles es registrado en bitácora, los datos son
registrados acorde a las directivas de protección de datos o cuando el registro de los
accesos es requerido.
- Verificar que la información sensible mantenida en memoria es sobre escrita con ceros
tan pronto como no es requerida, para mitigar ataques de volcado de memoria.

Verificación de seguridad de las comunicaciones

- Utilizar TLS donde se transmite información sensible.

- Utilizar algoritmos y cifradores fuertes en todo momento.
- Verificar que puede construirse la cadena de confianza desde una CA(Autoridad de
certificación) para cada certificado TLS (Transport Layer Security) del servidor y que
cada certificado del servidor sea válido.
- Verificar que se utiliza TLS para todas las conexiones (Incluyendo conexiones back-end
y externas) autenticadas o que involucran funciones o información sensible y no recaigan
en protocolos inseguros o sin cifrado.
- Verificar que se registran los fallos de conexiones TLS en el backend.
- Verificar que se construyen las cadenas de confianza para todos los certificados de.
clientes mediante anclajes de confianza e información de revocación de certificados.
- Verificar que todas las conexiones a sistemas externos que involucran acciones o
información sensible sean autenticadas.
- Verificar que haya una sola implementación estándar de TLS utilizada por la aplicación
la cual esté configurada para operar en un modo aprobado de operación.
- Asegurar que foward secrecy se esté utilizando para mitigar que atacantes pasivos puedan
grabar el tráfico.
- Verificar una adecuada revocación de certificados, tal como el protocolo de estatus de
certificado en línea (OSCP) está habilitado y configurado para determinar el estado de
vigencia del certificado.
 - Verificar que se utilicen únicamente algoritmos, cifradores y protocolos fuertes, a través
de toda la cadena de confianza, incluyendo certificados raíz y certificados intermediarios
de la autoridad certificadora seleccionada.
- Verificar que la configuración esté en línea con las mejores prácticas actuales,
particularmente debido a que configuraciones comunes se convierten en inseguras a
medida que transcurre el tiempo.

Verificación de configuración de seguridad HTTP

- Verificar que la aplicación acepte solo un conjunto definido de métodos de solicitud

HTTP y que son necesario, como GET y POST, y métodos no utilizados (por ejemplo:
TRACE, PUT y DELETE) se encuentran explícitamente bloqueados.
- Verificar que cada respuesta HTTP contenga una cabecera content-type en la que se
especifique un conjunto de caracteres seguros(ejemplo: UTF-8,ISO 8859-1).
- Verificar que los encabezados HTTP agregados por un proxy confiable o dispositivos
SSO, tales como un token de portador (bearer), son autenticados por la aplicación.
- Verificar que el cabezal X-FRAME-OPTIONS se encuentra especificado para los sitios
que no deben ser embebidos en X-Frame en sitios de terceros.
- Verificar que los encabezados HTTP o cualquier parte de la respuesta HTTP no
expongan información detallada de la versión de los componentes del sistema.
- Verificar que todas las respuestas del API contienen opciones X-Content-Type: nosniff y
Content-Disposition: attachment; filename= “api.json”(u otro nombre de archivo
apropiado para el tipo de contenido).
- Verificar que la política de seguridad de contenido (CSPv2) está en uso de tal manera que
ayude a mitigar vulnerabilidades de inyección comunes de DOM, XSS, JSON y
Javascript.
- Verificar que el encabezado “X-XSS-Protection:1, mode=block” esté presente para
habilitar navegadores a filtrar XSS reflejados

​Verificación para controles malicioso

- La actividad maliciosa se debe manejar con seguridad y adecuadamente para no afectar el

resto de la aplicación
- Verificar que no posea bombas de tiempo no otros ataques basados en tiempo.
- Verificar que no realice “phone home” a destinos malintencionados o no autorizados.
- verificar que la aplicación no posea puertas traseras, huevos de pascua, ataques salami o
fallos de lógica que pueden ser controlados por un atacante.
- La revisión manual línea por línea del código puede ayudar a encontrar bombas lógicas,
pero hay que esforzarse para encontrar código malicioso.
 - Verificar que toda actividad maliciosa sea adecuadamente aislada o encajonada para
retrasar y disuadir a los atacantes de atacar otras aplicaciones.
- Revisar que el código fuente de la aplicación y bibliotecas de terceros como sean
posibles con el fin de asegurarse que no tengan puertas traseras, huevos de pascua o fallas
de lógica en la autenticación, control de acceso, validaciones de entrada y lógica de
negocio en transacciones de alto valor.

Verificación de archivos y recursos

- Verificar que los archivos obtenidos de fuentes no confiables se almacenen fuera del
webroot, con permisos limitados, preferiblemente con una fuerte validación.
- Verificar que el servidor web o de aplicación se encuentre configurado por defecto para
negar acceso a recursos remotos o sistemas fuera del servidor web o de aplicación.
- Verificar que el código de la aplicación no ejecute datos cargados obtenidos de fuente no
confiables.
- Verificar que no utiliza FLash, Active-X, Silverlight, NACL, Java del lado del cliente u
otras tecnologías del lado del cliente que no sean soportadas de forma nativa a través de
los estándares de navegador W3C.
- Verificar que archivos no confiables enviados a la aplicación no sean utilizados
directamente por comandos de entrada/salida de archivos, especialmente para proteger
contra manipulaciones de rutas, archivo local incluido, manipulación de tipo mime y
vulnerabilidades de inyección de comandos de sistema operativo.

También podemos realizar pruebas de seguridad, a continuación exponemos las pruebas

comunes que es recomendable hacer a nuestras aplicaciones web.

1. Recopilacion de Informacion
Se centra en recoger tanta información como sea posible, es un paso necesario en una
prueba de intrusión, esta se puede llevar a cabo de muchas formas:
● Spiders, Robots y Crawlers
● Reconocimiento mediante motores de Búsqueda
● Identificación de puntos de entrada de la aplicación
● Pruebas para encontrar firmas de Aplicaciones Web
● Descubrimiento de aplicaciones
● Análisis de códigos de error

2. Pruebas de gestión de la configuración

La arquitectura de la aplicación web puede suministrar al atacante información valiosa,
por ejemplo: Los protocolos utilizados, las funcionalidades administrativas, los métodos
 de cifrado de información utilizados, también podemos tener inconvenientes de seguridad
al no utilizar algoritmos de cifrado ya que la información confidencial puede ser extraída
en texto plano y darle una ventaja exponencial al atacante.

3. Pruebas de la lógica de negocio

● Verificar que la aplicación solo procese flujos lógicos de negocios en orden
secuencial con todos los pasos procesados en tiempo real y no procesados fuera
de orden, con pasos salteados, con pasos del proceso de otro usuario o de
transiciones muy rápidas enviadas.
● Verificar que la aplicación tiene límites de negocio y los aplique correctamente
para cada usuario, con alertas configurables y reacciones automatizadas ante
ataques inusuales o automáticos.

4. Pruebas de autenticación
Los atacantes usualmente buscan dañar los mecanismos de autenticación con el fin de
tener acceso a la información que les interese, las vulnerabilidades que los atacantes
usualmente explotan son por ejemplo: la falta de canales de cifrado para intercambiar
información desde el cliente - servidor, contraseñas débiles las cuales son propensas a ser
descifradas con herramientas como las conocidas diccionario de contraseñas o por fuerza
bruta, falta de definición de permisos en la aplicación.

5. Pruebas de autorización
Permite el acceso a recursos solamente a los usuarios que tienen permiso para
modificarlos, estas pruebas consisten en comprender detalladamente como funciona el
mecanismo de autorización y con esta información saltarse el mismo.

6. Prueba de gestión de sesiones

La gestión de sesiones cubre ampliamente todos los controles que se realizan sobre el
usuario, desde la autenticación hasta la salida de la aplicación. HTTP es un protocolo sin
estados, lo que significa que los servidores web responden a las peticiones de clientes sin
enlazarlas entre sí. Es importante que la seguridad de la aplicación sea considerada en el
contexto de los requisitos y expectativas del proveedor.

7. Prueba de validación de datos

La debilidad más común en la seguridad de aplicaciones web, es la falta de una
validación adecuada de las entradas procedentes del cliente o del entorno de la aplicación.
Se realiza recolección de pruebas para evaluar si las funciones que reciben datos, ya sean
originarios del usuario, de otros servicios, o de la base de datos, validan estos de forma
 correcta y si los datos son limpiados de tal manera que no puedan afectar a los
intérpretes que los vayan a utilizar.

8. Prueba de denegación de servicio

El objetivo de este ataque es saturar el servidor de la aplicación con tráfico de red, que a
pesar de las buenas prácticas de desarrollo no tienen mucho alcance en la tarea de evitarlo
es de suma importancia construir la aplicación con una arquitectura de software robusta.

9. Pruebas de servicios web

Los clientes de servicios web generalmente no son frontales web, sino otros servidores.
Los servicios web están expuestos a la red como cualquier otro servicio, pero pueden ser
utilizados en HTTP, FTP, SMTP o acompañados de cualquier otro protocolo de
transporte. Las pruebas se centran en evaluar lo que se conoce como `web services´ y que
se pueden definir como servicios más o menos específicos a los cuales otras aplicaciones
hacen peticiones. Una prueba que se podría realizar, es ver si permite el acceso sin
validar, si el usuario está autorizado a realizar dicho proceso.

10. Pruebas de AJAX

Desde el punto de vista de la seguridad, las aplicaciones AJAX tiene una superficie de
ataque mayor que las aplicaciones web convencionales, a veces son desarrolladas
centrándose más en que se puede hacer que en que se debería hacer. Además, las
aplicaciones AJAX son más complicadas porque el procesamiento se realiza tanto en el
lado del cliente como en el lado del servidor.

Por último hay que tener en cuenta herramientas para hacer análisis de seguridad en nuestras
aplicaciones por ejemplo las que explicamos a continuación:

Aplicaciones para Pruebas de Seguridad Web

1. WebScarab
Aplicación para pruebas de seguridad web cuyo desarrollo está inactivo, debido al
lanzamiento de OWASP ZAP. Se solía utilizar como un proxy que intercepta y permite al
usuario alterar las peticiones HTTP y HTTPS en el navegador web y la respuesta del
servidor web.

2. Dir Buster
DirBuster es una aplicación Java multi hilo diseñada para obtener por fuerza bruta los
nombres de directorios y archivos en servidores Web/de aplicación. A menudo ocurre
 que lo que ahora parece un servidor Web en una fase de instalación por omisión no lo es,
y tiene páginas y aplicaciones ocultas. DirBuster trata de encontrar estos.

¿Cómo ayuda esta aplicación a crear aplicaciones seguras?

- Encontrando contenido en el servidor Web o dentro de la aplicación que no es requerido.
- Ayudando a los desarrolladores a entender que por no ligar una página no quiere decir
que no puede ser accesada.
 CONCLUSIÓN

Se puede entender que no tenemos una solución completa a los riesgos que se presentan en el uso
de las aplicaciones desarrolladas, pero con estas pruebas de seguridad y empleando buenas
prácticas a la hora de desarrollarlas podemos mitigar exponencialmente estos riesgos por ello es
esencial estar informados sobre estos estándares de seguridad y mantener un orden en nuestros
proyectos para brindar un producto de excelente calidad al cliente y que la circulación de la
información tenga un nivel de confidencialidad muy alto para así evitar su exposición a terceros.
Para que la seguridad sea eficiente debe ser un conjunto de procesos, tecnologías y personas.
 BIBLIOGRAFÍA

https://www.owasp.org/images/5/5e/OWASP-Top-10-2017-es.pdf

https://www.owasp.org/images/8/80/Gu%C3%ADa_de_pruebas_de_OWASP_ver_3.0.pdf

https://www.owasp.org/images/2/2f/OWASP_SUSCERTE.pdf

Ortega Candel, José Manuel (2018). ​Seguridad en aplicaciones Web Java, pág 92,93. Madrid
España. RA-MA Editorial