Módulo II: Diseño de software seguro, aplicaciones y vulnerabilidad
Unidad 2. Diseño de software seguro, aplicaciones y vulnerabilidad
2.1. Aplicaciones y vulnerabilidades
2.1.1. Tipos de vulnerabilidades
2.1.2. Mercado de vulnerabilidades
2.1.3. Reporte y divulgación de vulnerabilidades
2.1.4. Bases de datos de vulnerabilidades
2.2. Diseño de software seguro
2.2.1. Procesos de diseño seguro
2.2.2. Consideraciones de diseño
2.2.3. Arquitectura de aplicación
2.2.4. Tecnologías disponibles
APLICACIONES Y VULNERABILIDADES
El software lo podemos definir según (Aguilera, 2010) como el conjunto aplicaciones o
programas que realizan tareas asignadas en un ordenador, la aplicación quizás más
importante es el sistema operativo, se encarga de administrar todos los recursos del
computador, adicionalmente integra una serie de utilidades que proveen al ordenador de
servicios importantes como la recuperación automática de fallos del sistema operativo, la
actualización automática para corregir parches de seguridad o la actualización de software
de los dispositivos instalados.
A que se debe que una aplicación o un sistema operativo sea vulnerable, muchas veces se
da de una instalación o configuración incorrecta por parte de los administradores, aunque
las fallas más frecuentes se dan por errores de programación que son aprovechados por
los atacantes.
Los errores de instalación o una incorrecta configuración pueden ser, de una
documentación insuficiente del software, o características técnicas que no cumplen para
su funcionamiento, o también de negligencia de los instaladores que no lo configuran
adecuadamente.
Los errores de programación también conocidos como bugs, para la construcción de una
aplicación es necesario un diseño que este bien definido y aun así presentar
vulnerabilidades en el software, una aplicación correctamente funcional que guarde los
datos de usuario y contraseña sin cifrar presenta un error de programación, facilitando a
los atacantes ver la información para ingresar al sistema y tomar el control. El siguiente
código muestra una conexión típica de una aplicación a una base de datos con los datos
usuario y contraseña sin cifrar.
…
if(!($conexion=mysql_connect(“localhost”, “usuario”, “contraseña”);))
{
echo “No es posible establecer la conexión”;
exit();
}
if(!(mysql_select_db(“Conectar”,$conexión);))
{
echo “Error al de la fuente de conexión”;
exit();
}
…
VULNERABILIDAD
Es software es construido por humanos, lo que implica que puede presentar errores que
no fueron detectados durante la programación. Pueden ser leves como un mensaje mal
traducido o pueden ser graves como corrupción de datos o críticos que presenten una
vulnerabilidad y permita el acceso libre a información confidencial. Una vulnerabilidad en
el software es una falla que facilita el acceso indebido al sistema y esta es aprovechada
por un atacante cuando la descubre. El atacante hace uso de varias aplicaciones entre
ellas el malware aprovecha la vulnerabilidad para tener el control del sistema exploit o
realizar operaciones no autorizadas.
NORMAS DE SEGURIDAD PARA LA GESTIÓN DE VULNERABILIDADES
Es necesario definir una gestión de vulnerabilidades técnicas que estén dirigidas al análisis
de los problemas de seguridad o vulnerabilidades que se presentan en el software, las
cuales han sido publicadas por diferentes proveedores y organismos especializados como
CVE, OWASP o que han sido detectados por los usuarios recomendando las medidas de
para mitigar el riesgo. Es necesario definir un plan de actualización para el software
desarrollado o el utilizado por la entidad, logrando la actualización a las últimas versiones
mediante la instalación de parches lo antes posibles evitando algún ataque por alguna
vulnerabilidad presentada.
TIPOS DE VULNERABILIDADES
Los tipos de vulnerabilidades se pueden clasificar en: Reconocidas, No Reconocidas,
Lógicas y Física.
● Reconocidas que se dividen en dos grupos.
o Cuando el fabricante de la aplicación tiene un parche que debemos instalar
inmediatamente y este que corrige la vulnerabilidad.
o Cuando el fabricante de la aplicación no tiene un parche y se proporciona
una solución temporal continua la vulnerabilidad, lo recomendable es
desactivar el servicio hasta que se aplique un parche apropiado.
● No Reconocidas cuando el fabricante no tiene la solución, lo que facilita la
exposición del software a ataques por un periodo de tiempo y sin darnos cuenta.
● Físicas: afectan la infraestructura de la organización de manera física entre las que
están los desastres naturales que generan una negación de servicio, perdida de los
controles de acceso a la infraestructura, un usuario podría dejar el sistema
vulnerable, cualquiera podría ingresar con una USB y copiar la información
infectando el sistema.
● Lógicas: afectan directamente al sistema y a las operaciones pueden ser de:
o Configuración
o Actualización
o Desarrollo
A continuación se lista el Top 10 de vulnerabilidades de aplicaciones que presenta OWASP.
INYECCIÓN
Las fallas de inyección derivadas de SQL, NoSQL, OS o LDAP se presenta al enviar datos no
confiables a un intérprete, que se incluye en una sentencia de consulta. La información
alterada por el atacante logra confundir al interprete con la intención de que ejecute
comandos involuntarios o acceda a los datos sin la debida autorización. (OWASP, 2017)
La aplicación puede presentar debilidades de autenticación cuando.
● Los datos no confiables en las sentencias vulnerables SQL.
String query = "SELECT * FROM cuenta WHERE ctID='" + [Link]("id") +
"'";
● Confiar en un framework sin estudiarlo pueden presentar vulnerabilidad a inyección.
Query HQLQuery = [Link]("FROM cuenta WHERE ctID='" +
[Link]("id") + "'");
● La modificación del parámetro “id” en su navegador para enviar un dato.
[Link] or '1'='1
PERDIDA DE AUTENTICACIÓN
Cuando la autenticación y el inicio de sesión no están implementadas correctamente,
exponiendo a los usuarios, contraseñas y token de sesiones a ataques con la intención de
asumir la identidad de otros usuarios. (OWASP, 2017)
La aplicación puede presentar debilidades de autenticación cuando.
● Admite ataques automatizados con la generación de credenciales conocidas, los
atacantes contienen listas de credenciales válidos.
● Facilita los ataques de fuerza bruta o automatizados
● Establece contraseñas por defecto, contraseñas débiles o conocidas por ejemplo
“123”, “admin”.
● Las credenciales se almacenan en texto legible o cifrado con algoritmos hash
débiles.
EXPOSICION DE DATOS SENSIBLES
Muchas aplicaciones no protegen correctamente los datos sensibles, como la información
financiera, personal identificable, los datos protegidos incorrectamente pueden ser
robados o alterados por los atacantes, para cometer delitos con tarjetas de crédito,
suplantar una identidad, es necesario otros métodos adicionales de seguridad para
proteger los datos. (OWASP, 2017)
La aplicación presenta esta vulnerabilidad cuando:
● Cuando se envían datos en texto plano, a través de protocolos http, smtp, telnet,
ftp. Internet expone muchos riesgos, aunque internamente el tráfico es necesario
revisarlo en los servidores web y desde las aplicaciones en el backend.
● La utilización de algoritmos débiles y comunes como son MD5 y HAS1.
● Se desarrollan funciones criptografías débiles, no hay una política de rotación de
claves.
● Se aplica un cifrado por defecto.
ENTIDADES EXTERNAS (XML)
La mala configuración o procesadores antiguos XML que hacen referencia a entidades
externas a través de documentos XML. Se facilita para que las entidades externas
muestren nombre de archivos desde la URL e incluso archivos del servidor, exposición de
puertos, la ejecución de comandos de forma remota denegando servicios (DoS). (OWASP,
2017)
La aplicación presenta esta vulnerabilidad cuando:
● La aceptación directa de archivos externos XML no confiables, insertando
información sospechosa en la aplicación.
● El uso del lenguaje de marcado de aserción de seguridad (SAML) utilizando XML
que garantiza la identidad de los usuarios y puede ser vulnerable.
● El uso de SOAP en versiones muy antiguas es propenso a vulnerabilidades.
PERDIDA DE CONTROL DE ACCESO
No se aplican correctamente las políticas de roles y las restricciones sobre las acciones en
la aplicación que deben realizar los usuarios no se ejecutan correctamente, facilitando a
los atacantes estas vulnerabilidades para acceder de forma no autorizada. (OWASP, 2017)
La aplicación presenta esta vulnerabilidad cuando:
● No se implementan comprobaciones de control de acceso facilitando la
modificación de URL, el cambio de estado de la aplicación haciendo uso de
herramientas de ataque o conexión vía API.
● Facilita la visualización y edición de cuentas de otros usuarios.
● Violación de privilegios actuando como usuario sin iniciar sesión, lograr privilegios
de administrados siendo un usuario normal.
CONFIGURACIÓN DE SEGURIDAD INCORRECTA
La configuración manual de la seguridad es un problema común, la falta de configuración,
la omisión de parámetros en cabeceras HTTP, exposición de mensajes de error con
contenido sensible, la implementación framework sin conocer la documentación, la
dependencia entre componentes desactualizados. (OWASP, 2017)
La aplicación presenta esta vulnerabilidad cuando:
● Mala configuración de permisos del stack.
● Falta de algún componente o instalación adicional innecesaria.
● Los datos predeterminados de cuentas duran largos periodos de tiempo.
● Mansajes de error demasiado informativos revelando flujos de la aplicación.
● La correcta configuración o activación de las funciones de seguridad los sistemas
actualizados están deshabilitadas.
SECUENCIA DE COMANDOS EN SITIOS CRUZADOS (XSS)
Los XSS se presentan en las aplicaciones que no validan los datos y son enviados al
navegador, ejecuta comandos desde el navegador de la víctima, haciendo uso de la sesión
y dirigiendo el usuario hacia otro sitio malicioso. (OWASP, 2017)
La aplicación presenta esta vulnerabilidad cuando:
● XSS Reflejado: La aplicación utiliza datos sin validar, ingresados por los usuarios y
procesados con HTML y JavaScript de salida. El atacante ejecuta comandos
inmersos en HTML y JavaScript en el navegador del cliente dando al usuario la
interacción desde un enlace controlado por el atacante.
● XSS Almacenado: La aplicación almacena los datos ingresados por el usuario sin
aplicar una validación, y luego son utilizados por otros usuarios como información
del sistema.
● XSS Basados en DOM: incluyen datos dinámicos en páginas o frameworks en
JavaScript que son controlados por los atacantes en APIs inseguras.
DESERIALIZACIÓN INSEGURA
Esta vulnerabilidad se presenta en una aplicación que recibe objetos serializados dañinos
que luego son usados por los atacantes para inyección de código, modificar sus privilegios,
o la ejecución remota de la aplicación desde el sitio del atacante. (OWASP, 2017)
La aplicación presenta esta vulnerabilidad cuando:
● La deserialización se presenta cuando el atacante ejecuta remotamente código
que puede alterar la lógica y el funcionamiento de la aplicación.
● Manipulación del control de acceso, modificando el contenido de las estructuras
de datos existentes en la aplicación.
COMPONENTES CON VULNERABILIDADES CONOCIDAS
La mayoría de los componentes, frameworks se ejecutan bajo los mismos privilegios que
la aplicación. Si un componente presenta una vulnerabilidad el atacante puede tomar
control del servidor. (OWASP, 2017)
La aplicación presenta esta vulnerabilidad cuando:
● El software es vulnerable, la plataforma operativa, el servidor web se encuentran
desactualizados.
● No se cuenta con una política de revisión periódica de los componentes utilizados.
● No se instalan las actualizaciones de la plataforma.
REGISTRO Y MONITOREO INSUFICIENTE
La falta de respuesta inmediata ante incidentes presentados facilita a los atacantes
mantener un ataque por largos periodos de tiempo, con consecuencias en el sistema de
manipulación, extracción o destrucción de datos. (OWASP, 2017)
La aplicación presenta esta vulnerabilidad cuando:
● El registro de eventos auditables, los fallos presentados al iniciar sesión e incluso
transacciones de alto valor no quedan registradas en el sistema.
● Los mensajes de advertencia y errores del sistema no son claros o no se genera
ningún mensaje.
● No se monitorean los registros de aplicaciones, Apis para detectar actividades
sospechosas.
● Se almacenan los registros solo de forma local.
MERCADO DE VULNERABILIDADES
El mercado de vulnerabilidades consiste en hallar fallos en el software que construyen las
empresas, plantear una solución y presentarla a la compañía de forma discreta y recibir
una remuneración económica.
Grandes empresas como Google, Amazon, Apple, Samsung, Twitter, Facebook, entre otras
recompensan a quienes encuentran fallos, ya que el descubrir una falla de alguna
aplicación, lo recomendable es informarlo a la empresa y establecer una comunicación
para demostrar la falla y una posible solución, para que los desarrolladores se pongan
inmediatamente a corregirlo.
EL comercio de fallas en el software está enfocado en vulnerabilidades de seguridad o
exploits, errores que se pasan en la programación, descuidos que pueden facilitar el
acceso al software, hardware y permita la ejecución de algún software malicioso.
BASES DE DATOS DE VULNERABILIDADES
La consulta de fuentes que proporcionen información de vulnerabilidades de software
como páginas web que publican errores y defectos de las aplicaciones, divulgan
vulnerabilidades de aplicaciones conocidas que deben de tenerse en cuenta al realizar un
análisis de vulnerabilidades algunos referentes son:
● National Vulnetability Database (NVD). Consiste en un repositorio de datos de
gestión de vulnerabilidades a cargo del gobierno de los Estados Unidos bajo
estándares de protocolo de automatización de contenido de seguridad (SCAP).
Permitiendo la gestión de las vulnerabilidades, contiene bases de datos con listas
de verificación de seguridad, fallas de seguridad del software, productos
configuraciones inadecuadas y análisis de impactos. (Tecnology, 2022), link de
acceso NVD - Home ([Link]).
Ejemplo de reporte de vulnerabilidad “CVE-2021-38003 La implementación
inapropiada en V8 en Google Chrome antes de 95.0.4638.69 permitió a un
atacante remoto explotar potencialmente la corrupción del montón a través de
una página HTML diseñada”. (Tecnology, 2022)
● Security-Database proporciona información de bases de datos de vulnerabilidad
precisa de muchas fuentes, más de 70.000 alertas en primer grado, Monitoreo en
tiempo real, sujeta a estándares abiertos como:
- Enumeración de vulnerabilidades comunes CWE
- Enumeración de debilidad común CVE
- Enumeración y clasificación de patrones de ataque comunes CAPEC
- Lenguaje abierto de vulnerabilidad y evaluación OVAL
- Sistemas de puntuación de vulnerabilidades comunes CVSS
para la clasificación basados en algoritmos privados y públicos operado por uno de
los mejores equipos europeos de expertos en seguridad. (Picura, 2020) Link de
acceso Security Database ([Link]).
● Common Vulnerabilities and Exposures (CVE) tiene como misión la identificación,
definir y catalogar vulnerabilidades de ciberseguridad divulgadas públicamente.
Cada vulnerabilidad descubierta es catalogada, asignada y publicada con las
organizaciones afiliadas al programa CVE. (CVE, 2021) Link de acceso CVE - CVE
([Link])
● SANS provee una base de datos de vulnerabilidades, ofrece un portafolio de
capacitaciones para profesionales de la seguridad cibernética, Certificaciones,
comparte una serie de documentos de investigación de diversas temáticas
enfocadas con la seguridad informática. (SANS, 202) Link de acceso
[Link]
La búsqueda de vulnerabilidades en estas fuentes de datos puede realizar de forma
manual o a través de un registro, todas ofrecen bases de datos de vulnerabilidades
que están en constante actualización de fuentes públicas.
DISEÑO DE SOFTWARE SEGURO
Es difícil integrar la seguridad al sistema después de su implementación. Es necesario
contemplar los riesgos de seguridad en las etapas del diseño del sistema.
En el diseño se puede presentar conflictos generales, que son independientes de la
aplicación e importantes para el diseño seguro como lo menciona (Sommerville, 2011) en
los siguientes puntos.
● El Diseño arquitectónico: ¿Cómo pueden afectar las decisiones de diseño
arquitectónico la seguridad de un sistema?
● Buena práctica: ¿En qué consisten las buenas prácticas al diseñar sistemas
seguros?
● Diseño para implementación: ¿Cuáles soportes debe contener el diseño para evitar
proteger el sistema y evitar las vulnerabilidades cuando el sistema está en
producción?
Toda aplicación es única y diferente igual su diseño debe estar definido para su propósito,
el entrono en el que se va a ejecutar la aplicación. Como por ejemplo. Diseñar una
aplicación para entidades militares, es necesario integrar un modelo seguridad secreto y
riguroso. Mientras que una aplicación que maneja información personal se debe tener en
cuenta la legislación de cada país para la protección de datos que define restricciones de
cómo se administra la información.
La confiabilidad y a seguridad están muy relacionadas, la redundancia y diversidad es
importante para alcanzar la confiablidad, un sistema puede resistir y recuperarse ante
ataques dirigidos a ciertas características o al diseño implementado, como lo menciona
(Sommerville, 2011) ciertos mecanismos de apoyo a alto nivel de disponibilidad permiten
que el sistema se recupere a los intenciones de ataques de negación de servicio, donde lo
que buscan los atacantes es tumbar o bloquear el funcionamiento correcto del sistema. Es
posible implementar variadas medidas de seguridad al sistema que permitan reducir las
probabilidades de ataque e ingresen a la aplicación sin autorización, sin embargo las
medidas de seguridad en un sistema requieren una labor computacional adicional que se
refleja en su funcionamiento lo que afecta el rendimiento de la aplicación. Como lo es la
información confidencial que no se debe mostrar y debe ser encriptada, obligando a los
usuarios esperar que se desencripte para su visualización, lo que sería más lento el
proceso.
DISEÑO ARQUITECTONICO
El diseño de la arquitectura de software puede presentar defectos sobre las propiedades
emergentes de un sistema. Al utilizar una arquitectura inadecuada, dificultaría mantener
la confidencialidad e integridad de los datos o la disponibilidad de algún modulo del
sistema.
Para definir una arquitectura que conserve la seguridad, se deben tener en cuanta dos
puntos importantes:
● Protección: La organización del sistema debe permitir proteger los activos críticos
contra ataques externos.
● Distribución: La distribución de los activos del sistema de manera que se minimicen
los efectos de un ataque.
Se debe como lo menciona (Sommerville, 2011) construir un solo sistema de protección,
muchas capas de protección son costoso y a pesar de todo puede llegar a fallar y la
información estaría expuesta, entre más capas de protección afectan el rendimiento, y
hace más difícil cumplir los requerimientos de usabilidad y rendimiento del sistema.
Un sistema de registro de pacientes puede tener una arquitectura de base de datos
centralizada y la protección puede estar definida en una arquitectura en capas con la
información protegida en el nivel más bajo y varias capas de protección en los siguientes
niveles de la arquitectura del sistema, en la figura 1 muestra la protección por capas de un
sistema de registro de pacientes donde la información a proteger es los registros de cada
paciente.
Fuente: Sommerville, I. (2011). Ingeniería de Software
● Protección a nivel de plataforma: Este nivel protege el acceso al sistema para el
registro de pacientes. incluye el acceso del usuario desde equipos externos, la
plataforma debe incluir el soporte para garantizar la integridad de los archivos al
igual que backus de respaldo.
● Protección a nivel de aplicación: Esta se desarrolla en la aplicación, consiste en
controlar el acceso de los usuarios a través de la autenticación y la asignación de
roles previamente para realizar acciones en el sistema.
● Protección a nivel de registro: Permite el control cuando se accede a registros
específicos, valida que el usuario este autorizado para realizar las acciones sobre el
registro, el nivel de protección podría implicar métodos de encriptación sobre los
datos.
CONSIDERACIONES DE DISEÑO SEGURO
La seguridad depende del tipo de sistema a desarrollar, lo que deriva en distintas técnicas
para cada sistema que permita lograr un nivel de seguridad aceptable para el cliente. La
diversidad de requerimientos proveniente de varios grupos de trabajo interfiere
significativamente en lo que es y no es aceptable. Por ejemplo una entidad bancaria es
aceptable que los usuarios estén muy familiarizados con los altos niveles de seguridad a
diferencia de una universidad.
A continuación se listan algunos lineamientos que han sido aplicados en el diseño de
soluciones de seguridad de un sistema, integrando buenas prácticas de diseño, estos
lineamientos tienen dos usos principales.
● Permite que el equipo de ingeniería de software tenga conciencia de la seguridad
integrada en el diseño. Muchos proyectos de ingeniería se piensan a corto plazo
con la intención de desarrollar un software operativo y cumplirle al cliente, lo que
muchas veces la seguridad no se tiene en cuenta. La importancia de conocer los
lineamientos logra que la seguridad sea tenida en cuenta en las decisiones al
momento del diseño de software.
● Sirven como una guía para la verificación y validación del sistema.
Lineamientos de seguridad definidos por (Sommerville, 2011)
● Decisiones de seguridad con base en una plantilla explícita de seguridad
● Evite un solo punto de falla
● Seguridad en caso de falla
● Equilibrio entre seguridad y usabilidad
● Registre las acciones del usuario
● Use redundancia y diversidad para reducir el riesgo
● Valide todas las entradas
● Compartimente sus activos
● Diseñe para implementar
● Diseñe para facilitar la recuperabilidad
La siguiente lista de lineamientos es tomada de varias fuentes como lo indica
(Sommerville, 2011). “resultaron de varias fuentes, aquí el enfoque es sobre los
lineamientos que son aplicables en particular a los procesos de especificación y diseño del
software. Principios más generales, como “Asegura el vínculo más débil del sistema”,
“Hazlo simple” y “Evita seguridad mediante oscuridad” también son importantes, pero
menos relevantes directamente para la toma de decisiones de ingeniería”.
ARQUITECTURA SEGURA DE SISTEMA
La gestión del riesgo de seguridad requiere diseñar una arquitectura segura de sistema,
aplicar buenas prácticas que permitan diseñar sistemas seguros, integrando la
funcionalidad y reduciendo la posibilidad de permitir vulnerabilidades al momento de
implementar el software. El factor importante al momento de diseñar una arquitectura
segura de sistema, debe partir de la organización de la estructura del sistema que proteja
los activos claves y permita la distribución de los activos del sistema para reducir las
pérdidas que se podrían presentar al momento de un ataque.
[Link]