PPS01- Prueba de apps web y xa dispositivos móviles.

o Desarrollado sobre distintos Lenguajes de Programación

 Se pueden clasificar según su ejecución
 Interpretrados: Python, Ruby
 Compilados: C++, C, Golang
 Intermedios: Java, Scala
 En forma de Código Fuente
 Tiene distintos elementos como...
 Importaciones
 Librerias
 Funciones
 Sentencias
 Podremos evaluar mediante Pruebas de software
que permiten Detectar fallos en nuestro código de
manera automática:
 Aceptación - Integración
 Unidad - Funcionales
 Rendimiento - Regresión
 Estrés - Usabilidad

1.- Fundamentos de Programación.

2.- Modelos de Ejecución Software.
2.1.- Aplicaciones web y móviles.
3.- Elementos básicos.
3.1.- Entornos de desarrollo.
4.- Pruebas de software.
4.1.- Las pruebas de seguridad.
4.2.- Recomendaciones a la hora de realizar las pruebas.
5.- Evaluación de lenguajes de programación.

Los requisitos del proyecto pueden condicionar el lenguaje elegido

(necesidad de velocidad en entrega, rendimiento, requisitos técnicos
marcados por otras piezas del softw/hardw.).
 Rdto: compilado  mayor rdto que interpretado, pero sólo para plataforma en que se compila.
 Facilidad: los interpretados, generalm., más sencillos de programar x mayor nivel de abstracción.
1º distinción entre hardware y software
 Hardware: todos los componentes físicos de un ordenador
 Software: programas e instrucciones para ejecutar tareas en un ordenador
Definiríamos programa como: Secuencia de instrucciones entendible por el ordenador que tienen un
objetivo o tarea concreta
1.- Fundamentos de Programación.
Los ordenadores son máquinas eléctricas que sólo entienden de 0 (no corriente) y 1 (si), lenguaje binario.
Un programa es un cjto instrucciones creado para realizar una tarea y escritas en un leng. Progr. que se
traducen a lenguaje que la computadora puede entender y ejecutar. Al principio se programaba directamente
en código máquina (complicado, difícil entenderlos y mantenerlos), después se fueron desarrollando
herramientas para facilitar el trabajo y aparecieron los lenguajes prog., que podemos dividir en dos grupos:
 Lenguajes de bajo nivel: son los más cercanos al binario, pero son difíciles de programar (lenguaje
máquina)
 Lenguajes de alto nivel: necesitan ser traducidos, fáciles de programar x cercano a lenguaje natural.
(C, C++, Java, PHP, Python, Go, Rust, Ruby)
Programar es el proceso de crear un software fiable mediante la escritura en un lenguaje (code en inglés),
prueba (test), depuración (debug), compilación o interpretación, y mantenimiento (maintenance) del código
fuente de dicho programa informático.
CODIFICAR ⇒ PROBAR ⇒ DEPURAR ⇒ COMPILAR/INTERPRETAR ⇒ MANTENER (y vuelta a
empezar)
Algoritmo: [Link] de pasos para resolver problema o realizar una tarea de forma eficiente, precisa y
en tiempo razonable. Son independientes de [Link].. Se usan para diseñar la lógica subyacente antes de
implementarla en código. Son como planes que describen el proceso paso a paso para alcanzar un objetivo y
se representan como diagramas de flujo, seudocódigo o x descripción en lenguaje natural.
Programa: Implementación concreta del algoritmo en un lenguaje de programación.
2.- Modelos de Ejecución Software.
Lenguaje compilado: El código fuente se transforma en binario mediante compilación, El ordenador ejecuta
el binario, No necesitamos ningún programa adicional. Un compilador es un software que se transforma
código fuente en lenguaje binario, al compilar un programa elegimos la plataforma y arquitectura donde el
binario funcionará. Hay lenguajes como Golang que permiten compilado multiplataforma.
Lenguaje interpretado: El código fuente es leído en tiempo real por un programa (intérprete) que lo traduce
a código máquina (objeto binario), El ordenador ejecuta ese binario, Necesita programa adicional (intérprete).
Lenguaje intermedio: El código fuente se compila a un lenguaje intermedio, Este lenguaje intermedio se
ejecuta en una máquina virtual.
2.1.- Aplicaciones web y móviles.
Habitualmente, en estas aplicaciones, existe una parte que se ejecuta en el cliente (frontend) y otra en el
servidor (backend). Cada parte tiene lenguajes específicos y, en relación con la seguridad, su problemática.
Aplicaciones web: El cliente es la interfaz de usuario (navegador web), que solicita info (html, css, javascript,
datos…) al servidor y presenta info. al usuario. La parte servidora es una app que almacena, procesa y
entrega datos al cliente. La comunicación mediante diferentes protocolos (mas habitual HTTP)
 El navegador web es software que intérpreta protocolos web y lenguajes de marcado (HTML, CSS y
JavaScript). Solicita, recibe y procesa recursos en línea, interpretando y renderizando páginas web y
otros contenidos. Gestionan cookies, ses. usuario y almac. en caché recursos para acelerar carga.
 La parte servidora almacena lógica de aplicación, BBDD y recursos. Recibe solicitudes del cliente,
gestiona la sesión, procesa datos, ops sobre BBDD y envía respuestas al cliente. Pueden usar otros
Ss ubicados en otros servers. Lenguajes más utilizados PHP, Java, C#, Python, NodeJS, Ruby…
Aplicaciones móviles ("app"): Software diseñado para ser ejecutado en disp.móviles (smartphones,
tabletas), están optimizadas para funcionar en las limitaciones de hardware y pantalla de éstos.
 La parte que se ejecuta en dispositivo en lenguajes de programación para las plataformas móviles,
como iOS (utilizando Swift o Objective-C) o Android (utilizando Java o Kotlin).
 La parte servidora es similar a cualquier aplicación web.
Actualmente muy habitual construir apps web y móviles con APIs: (Interfaz de Programación de Aplicaciones)
Son cjto de reglas y protocolos xa comunicación e interacción entre [Link] software a través de Internet (una
aplicación solicita y accede a datos o Ss de otra aplicación/sist. a través de solicitudes HTTP, los datos se
transmiten en JSON (JavaScript Object Notation) o XML (eXtensible Markup Language), permitiendo que
apps y Ss se comuniquen estructurada y segura).
A nivel de seguridad al desarrollar apps web y móviles serie de desafíos y problemáticas:
 Diversidad de dispositivos/SO introduce vulnerabilidades potenciales, necesario garantizar
compatibilidad y seg. en cada plataforma.
 Creciente dependencia de Ss en la nube y comunic. entre dispositivos x de redes públicas aumenta
exposición a amenazas (ataques de interceptación de datos, robo de identidad y malware).
 Rápida evolución tecnológica y [Link] apps presentan desafíos para mantener seguridad en
un entorno en constante cambio.
Tanto apps móviles como web comparten similitudes y diferencias en términos de Ciberseguridad:
Similitudes: Ambas pueden ser vulnerables a amenazas comunes, como ataques de inyección (ej, SQL
injection), ataques de denegación de servicio (DDoS), y vulnerabilidades en gestión de sesiones. Ambas
requieren [Link], como autenticación y autorización, para proteger datos y funciones críticas.
Diferencias: Las apps móviles, al estar instaladas desafíos específicos, como ingeniería inversa de la
aplicación para descubrir vulnerabilidades o robo de datos almacenados en el dispositivo. Las web se
ejecutan en servidores remotos  vulnerables a amenazas como ataques de Cross-Site Scripting (XSS) y
Cross-Site Request Forgery (CSRF).
3.- Elementos básicos.
Elementos esenciales en lenguajes de prog: léxico del lenguaje (palabras reservadas con funciones
específicas dentro del lenguaje), las reglas sintácticas y semánticas, comentarios en el código (frases o
sin funcionalidad en el programa, descartados por compiladores/intérpretes, y diseñados para ser leídos por
humanos xa facilitar la comprensión del código. Muy importante que en comentarios no info sensible,
direcciones servidores, códigos de usuario, contraseñas…)
código fuente  cjto instrucciones escritas por un programador en [Link]. específico comprensibles para
humanos y son la base para crear programas. Dentro del código fuente  componentes:
 Comandos de pre-procesamiento: importación de módulos/librerías.
 Sentencias y Expresiones: [Link]. xa ejecutar en orden (cálculos, decisiones y manip. datos).
 Declaración de variables: (contenedores que almacenan datos: num, text, bool,…). Los datos
pueden ser modificados y utilizados en el programa.
 Estructuras de Control: como bucles y condicionales  permiten toma decisiones y repetir acciones.
 Funciones y métodos: bloques de código con tareas específicas. modularidad y reutilización código.
 [Link]: arreglos (array), pilas, listas y dicc.., permiten organizar/manipular datos eficientemente.
 Orientación a Objetos (OOP): paradigma de programación que se basa en "objetos"  instancias de
clases reutilizables (plantillas que definen estructura y comportamiento de objetos).
 Comentarios: notas explicativas en el código que ayudan a otros programadores.
el control de errores o excepciones. Permite detectar, informar y mitigar situaciones inesperadas o vuln.
que pueden ser explotadas por atacantes para comprometer [Link]., robar datos o ataques. El control de
errores adecuado permite identificar y responder proactivamente a estas amenazas, se pueden prevenir
brechas de seguridad, minimizar impacto de ataques y garantizar la integridad de la infraestructura.
3.1.- Entornos de desarrollo integrados IDE (Integrated Development Environment).
Herramientas que programadores utilizan para escribir, depurar y compilar su código. Incluyen:
 Editor Código: Resaltado sintaxis, sugerencias autocompletado y otras para mejorar eficienciA.
 Depuración: [Link]ón xa detectar y corregir errores en su código de manera eficiente.
 Gestión Proyectos: organizar proyectos, gestionar bibliotecas y dependencias, y trabajo en equipo.
 Integración con Herr: [Link] versiones, compiladores, analizadores estáticos y otros recursos.
 Personalización: suelen ser altamente personalizables  adaptarse a preferencias del programador.
 Soporte Multiplataforma: Muchos IDEs en SO como Windows, macOS y Linux.
IDE Descripción Características Destacadas
Un editor de código fuente gratuito y altamente Extensiones, depuración integrada,
Visual Studio Code
personalizable desarrollado por Microsoft. control de versión
Desarrollado por GitHub, Atom es un editor de código fuente Paquetes, integración con Git,
Atom
de código abierto y altamente personalizable. interfaz moderna
Un IDE específicamente diseñado para el desarrollo web y Autocompletado inteligente,
WebStorm
JavaScript, desarrollado por JetBrains. depuración, prueba
Un editor de código fuente moderno y ligero, enfocado en el Vista en vivo, preprocesadores,
Brackets diseño web. extensible
Un entorno de desarrollo de código abierto ampliamente Extensibilidad, comunidad grande,
Eclipse
utilizado que admite varios lenguajes, incluido Java. soporte multiplataforma
Un IDE desarrollado por JetBrains que ofrece un excelente Refactorización, análisis estático,
IntelliJ IDEA
soporte para Java y otras tecnologías. integración con frameworks
Un IDE de código abierto que soporta múltiples lenguajes y
NetBeans
es especialmente popular para el desarrollo Java. Integración con Maven
El uso de IDEs simplifica tareas. Poder analizar el código  mejora calidad, seguridad y eficiencia del
desarrollo software, ayuda a prevenir errores, cumplimiento estándares y mantener integridad del código a lo
largo del ciclo de desarrollo. Visual Studio Code (popular y versátil. Microsoft, de código abierto y soporta
muchos [Link]. y extensiones. Alto rdto, personaliz. y comunidad activa desarrolladores  extensiones).
Para acelerar desarrollo de aplicación (no partir de cero) es habitual utilizar librerías y/o frameworks (en
Ciberseguridad la revisión y gestión de las librería y frameworks es fundamental para [Link]):
  Librería: Cjto funciones o rutinas reutilizables que se usan en una aplicación para tareas específicas.
Generalm. archivos independientes que se vinculan durante compilación/[Link]ón.
 Framework: Cjto más amplio de herr, componentes y librerías  Permiten centrarse en lógica
aplicación xq parte de infraestructura y funcionalidad común ya implementadas.
4.- Pruebas de software.
Son elemento crítico para garantizar calidad de software. En fn de cómo las ejecutamos:
1. Pruebas manuales - Pruebas automáticas
En fn visibilidad del código:
 Pruebas de caja blanca: evaluadores tienen acceso al código fuente y conocimiento de arquitectura.
 Pruebas de caja gris: conocimiento parcial código fuente y la arquitectura del sistema..
 Pruebas de caja negra: no acceso código, evaluadores desde perspectiva usuario externo.
En fn de lo que estamos midiendo y probando, hay muchos tipos distintos. las más comunes son:
 Examen de la unidad o pruebas unitarias: valida cada unidad de software. Una unidad es el
componente comprobable más pequeño de una aplicación (función, método). Durante el desarrollo.
 Pruebas de integración: verifican que módulos funcionen de manera conjunta. De integración
horizontal (componentes similares) o de integración vertical (entre capas de aplicación).
 Pruebas funcionales: verificar si software cumple con especificaciones funcionales. Evalúan las
funciones y características del software para garantizar que funcionen como se espera.
 Pruebas de aceptación: verifican si cjto se comporta según lo esperado. Pueden ser de aceptación
del usuario (UAT, realizadas por cliente) o de aceptación del negocio (BAT, x analistas de negocio).
 Pruebas de usabilidad: confirman eficacia y facilidad de manejo x usuario en una/s tarea/s
específica/s. Para garantizar que software sea intuitivo y satisfaga necesidades del usuario.
 Pruebas de rendimiento: prueban el rendimiento del software con diferentes cargas de trabajo.
 Pruebas de regresión: verifican si el código introducido degrada funcionalidad del soft. original ante
cambios en un programa.
 Pruebas de Seguridad: evalúan robustez del sistema ante posibles amenazas y vulnerabilidades.
Garantizan que software resistente a posibles ataques y cumpla con estándares de seguridad.
4.1.- Las pruebas de seguridad.
Esenciales para identificar y mitigar riesgos seg., y parte fundamental de la [Link] prot. datos y activos:
 Pruebas de Análisis Estático (Static Analysis Testing): Analizan código fuente/binario en busca de
vuln. potenciales sin ejecutar el programa. (problemas seg. a nivel de código). IDEs suelen incluir
extensiones para estas pruebas mientras se crea el código.
 Pruebas de Análisis Dinámico (Dynamic Analysis Testing): Evalúan el software en tiempo de
ejecución para detectar posibles amenazas y vulnerabilidades mientras interactúa con el sistema.
 Pruebas de Penetración (Penetration Testing/pen test): Simular ataques controlados de expertos en
seguridad xa identificar vuln. y ptos entrada de posibles atacantes. De caja negra o de caja blanca. Se
realizan antes de poner en producción el software y periódicamente en el entorno de producción.
 Pruebas de Vulnerabilidad (Vulnerability Assessment): Evalúan vuln. conocidas en sistemas y
aplicaciones con escáneres automatizados especializados en detectar debilidades de seguridad.
 Pruebas de Seguridad Web (Web Application Security Testing): Evaluan seg. Apps web y sitios web.
Pruebas de inyección SQL, cross-site scripting (XSS), cross-site request forgery (CSRF), y otras
[Link]íficas web xa Garantizar que apps web sean resistentes a ataques comunes.
 Pruebas de Seguridad de Aplicaciones Móviles (Mobile Application Security Testing): Busca de
vuln. específicas de plat.móviles en aspectos como el [Link], autenticación, y comunic. segura.
 Pruebas de Seguridad de Red (Network Security Testing): Evalúan seguridad de infraestructura de
red, como firewalls, routers y conmutadores.
 Pruebas de Autentic.y Autorización: Aseguran que solo usuarios autorizados  acceso a recursos.
 Pruebas de Seg. APIs (API Security Testing): Verifican que API sean seguras y resistentes a ataques.
 Pruebas de Estrés y Carga (Stress and Load Testing): Evalúan el sistema bajo cargas de trabajo
intensas o condiciones de estrés. Identifican cuellos de botella y prob. rdto que podrían afectar seg.
Prueba Herramientas
Pruebas de Análisis Estático Checkmarx, Fortify, SonarQube
Pruebas de Análisis Dinámico AppScan, Veracode, Burp Suite
Pruebas de Penetración Metasploit, Nmap, Burp Suite, OWASP ZAP
Pruebas de Vulnerabilidad Nessus, OpenVAS, Qualys, Nikto
Pruebas de Seguridad Web OWASP ZAP, Burp Suite, Acunetix
Pruebas de [Link] Móviles MobSF, OWASP Mobile Security Testing Guide, Burp Suite
Pruebas de Seguridad de Red Wireshark, Nmap, Snort
Pruebas de Autenticación y Autorización No [Link]íficas, sino casos de prueba diseñados xa evaluar fns
Pruebas de Seguridad de APIs Postman, Swagger Inspector y OWASP API Security Top Ten
Pruebas de Estrés y Carga Apache JMeter, LoadRunner y Gatling

4.2.- Recomendaciones a la hora de realizar las pruebas.

 Cada caso de prueba debe definir el resultado de salida esperado.
 El programador debe evitar probar sus propios programas.
 Se debe inspeccionar a conciencia el resultado de cada prueba  posibles síntomas de defectos.
 Al generar casos de prueba, incluir datos de entrada válidos/esperados como no válidos/ inesperados.
 Las pruebas deben centrarse en dos objetivos (es habitual olvidar el segundo):
o Probar que el programa hace lo que debe hacer.
o Probar que el programa no hace lo que no debe hacer.
 Todos los casos de prueba deben documentarse y diseñarse con cuidado.
Las pruebas de software automatizadas (con scripts o herram. De prueba) son una práctica fundamental en el
desarrollo de aplicaciones. Existen múltiples herram.  ej: Selenium
5.- Evaluación de lenguajes de programación.
Mayoría de veces seg. no depende de lenguaje, sino del programador, de la tecnología que implementa ese
lenguaje y sobre todo del volumen de código que hay publicado de ese lenguaje de programación. El lenguaje
con + vuln es C (casi 50% vuln reportadas relacionadas con C). La explicación es:
 Es uno de los lenguajes más antiguos  usado durante más tiempo  más vuln-encontradas
 Es el lenguaje con mayor volumen de código abierto publicado en Internet
 Muchos sistemas operativos como UNIX/Linux, incluso partes de Windows usan C
Para evaluar [Link]. x su seg. deberíamos de valorar más que el lenguaje el ciclo de desarrollo del mismo
dentro de un proyecto. XA mayoría [Link]. existe guías de buenas prácticas para desarrollar con
seguridad.
"OWASP Secure Coding Practices". Cjto prácticas y pautas de seguridad recomendadas por el Proyecto de
Seguridad de Aplicaciones Web Abiertas (OWASP, en inglés) para ayudar a desarrolladores a escribir código
seguro. Ofrecer orientación específica para escribir código seguro en varios lenguajes y plataformas.
Proporciona directrices detalladas y ejemplos para abordar vulnerabilidades conocidas, como inyección de
SQL, XSS (Cross-Site Scripting), CSRF (Cross-Site Request Forgery) y muchas otras.
Al desarrollar y probar software necesitamos disponer de un entorno de desarrollo aislado xa hacer nuestras
pruebas y verificar si el software se comporta de la manera esperada ante las distintas variables o datos
procesados.  Estos entornos se conocen como sandbox, entorno cerrado donde probar cambios de código
de forma aislada, sin comprometer producción ni edición del programa en desarrollo..
PPS02. Determinación del nivel de
seguridad requerido por aplicaciones.
EL NIVEL DE SEG. REQUERIDO POR APPs Se basa en distintos
 Estandares Que ayudan en la identificación del
o Riesgo Como OWASP Top10
 Lista de controles A1...A10
 Desarrollado por Colaboración expertos y empresas
o Para establecer unos Controles Como ASVS
o Que fijan Niveles de Aplicación De –a+ restrictivos
 N1 - N2 - N3
 Que establezcan unos controles V1..V14

1.- Fuentes abiertas para desarrollo seguro.

2.- Listas de riesgos de seguridad habituales.
2.1.- Vulnerabilidades y exposiciones comunes
3.- Comprobaciones de seguridad a nivel de aplicación.
3.1.- Niveles de seguridad ASVS
4.- Req. verificación necesarios asociados al nivel de [Link].

1.- Fuentes abiertas para desarrollo seguro.

Ultimamente evolución clara desde software cerrado o propietario, hacia el soft.
de fuentes abiertas que aporta ventajas tanto a usuarios como a Eas:
 Estabilidad: usuarios y programadores expertos pueden revisar código y mejorarlo (+estabilidad del
software y + seguro). Cuanto mayor sea la comunidad más mejoras.
 Coste: Si comunidad grande  costes de desarrollo se reducen (menos depuración testeo…)
 Favorece la innovación colectiva incentiva la acción de la [Link], revisando, mejorándolo.
 Mejoras: Los usuarios al interactúar con el código lo modifican  nuevos usos y capacidades.
La idea/el movimiento del software de fuentes abiertas se ha difundido por todo el mundo  muchas Eas de
desarrollo de [Link] han incorporado como parte de su ADN  el paradigma ha cambiado de forma radical.
2.- Listas de riesgos de seguridad habituales.
El riesgo asociado con el uso de software se puede describir: un agente de amenaza (threat agent)
interactúa con un sistema (system), que puede tener un vulnerabilidad (vulnerability) que puede ser
explotada (exploited) para causar un impacto (impact). EJ: un ladrón (agente de amenaza) pasea por un
gimnasio revisando las taquillas (el sistema) en busca de taquillas sin candado (la vulnerabilidad) y cuando
encuentran una la abre (el exploit) y toma lo que sea que haya dentro (el impacto).
Toda aplicación/sistema puede tener fallos explotables, pero detectarlos y corregirlos no es simple. Existen
diferentes org/Ea que se dedican a detectar y plantear soluciones a vuln. que se van detectando. Ej:
 NVD (La BBDD [Link] [Link] E.E.U.U): recopila de datos de gestión de vulnerabilidades basados en
estándares operados por el gobierno federal.
 La Corporación Mitre y el Instituto SANS, junto con otros expertos mundiales, mantienen el sistema de
categorías CWE que cataloga las diversas vulnerabilidades.
 OWASP (Proyecto Abierto de [Link] [Link]), se encarga de determinar y combatir las causas de
que el software no sea seguro.
En España el INCIBE. que "Trabaja para afianzar la confianza digital, elevar la ciberseguridad y la resiliencia
y contribuir al mercado digital de manera que se impulse el uso seguro del ciberespacio en España".
OWASP Foundation
Uno de los [Link] en mejora del software en entornos web (sin ánimo de lucro), su objetivo es
trabajar en mejorar la [Link]. Proyectos de código abierto (y fuentes abiertas) liderados por la
comunidad (miles de miembros), conferencias educativas y cursos anuales de capacitación.
Uno de los proyectos es el Top10 de riesgos teniendo en cuenta distintos parámetros cómo vuln, ataques
conocidos, impactos, manejo de los datos, etc.
Top 10 vulnerabilidades web (2021)
A1 - Pérdida de Control Acceso A2 - Fallos Criptográficos
A3 - Inyección de código A4 - Diseño Inseguro
A5 - Problemas de configuración a nivel de seguridad A6 - Componentes vulnerables y obsoletos
A7 - Fallos de Autenticación e Identificación A8 - Fallos de Software y de Integridad de los Datos
A9 - Fallos en el registro (logging) y Monitorización de la Seguridad
A10 - Falsificación de peticiones en el servidor (Server-Side Request Forgery)
Top 10 vulnerabilidades móviles (2023)
M1: Uso inadecuado de credenciales
M2: Seguridad inadecuada de la cadena de suministro (Inadequate Supply Chain Security)
M3: Autenticación/autorización insegura M4: Insuficiente validación de entrada/salida
M5: Comunicación insegura M6: Controles de privacidad inadecuados
M7: Protecciones binarias insuficientes M8: [Link]ónea de la seg.(Security Misconfig)
M9: Almacenamiento de datos inseguro M10: Criptografía insuficiente
2.1.- Vulnerabilidades y exposiciones comunes
Las Vulnerabilidades y exposiciones comunes (CVE en inglés), es una lista de info. sobre vuln. con:
 Nº identificación CVE-ID.
 Descripción de la vulnerabilidad.
 Versiones del software afectadas.
 Posible solución al fallo (si existe) o como configurar para mitigar la vulnerabilidad.
 Referencias a publicaciones/foros o blog donde se hizo pública la vuln.o se demuestra su explotación.
 Suele mostrar tb enlace a la info. de la BBDD de vuln. (NVD) del NIST donde hay + detalles.
CVE-ID ofrece nomenclatura estándar para identificación de la vuln. de forma inequívoca CVE-YYYY-NNNN,
donde YYYY es el año y NNNN un número generado aleatoriamente. La lista es mantenida por “The MITRE
Corporation” (fondos USA) y forma parte del llamado Security Content Automation Protocol.
3.- Comprobaciones de seguridad a nivel de aplicación.
La fundación OWASP tien proyectos como una serie de guías y herramientas para la construcción y
mantenimiento de aplicaciones seguras. Por ejemplo:
 La guía de desarrollo (Development Guide ) cómo diseñar y construir una aplicación segura.
 La guía de verificación de seg. de la app o ASVS muestra cómo verificar la seguridad.
 La guía de pruebas o WSTG muestra cómo verificar la seguridad de una aplicación web.
El proyecto del Estándar de Verificación de Seguridad de Aplicaciones (ASVS) de OWASP da info. para
poder probar los controles técnicos de seguridad de apps web y proporciona lista de requisitos para un
desarrollo correcto y seguro, minimizando impacto de los riesgos detectados. Objetivos principales:
 Ayudar a orgs en el desarrollo/mantenimiento apps seguras.
 Alinear necesidades y ofertas de Ss seguridad, [Link] de seg. y consumidores.
Los requisitos se desarrollaron con los siguientes objetivos en mente:
 Usarlo como métrica, xa q desarrolladores y propietarios de apps tengan criterio xa evaluar el grado
de confianza que se puede depositar en sus aplicaciones web.
 Utilizarlo como guía, de orientación a desarrolladores sobre qué incorporar en los controles de
seguridad para satisfacer los requisitos de seguridad de las aplicaciones.
 Usarlo durante la compra de software como requisito,  base para especificar requisitos de
verificación de seguridad de la aplicación en los contratos.
OWASP desarrolla el MASVS  equivalente al ASVS pero para apps móviles. Hasta 2023 usaba 3 niveles
verificación (L1, L2 y R), pero ahora han sido reformulados como "perfiles de pruebas de seguridad" y
trasladados al OWASP MASTG (Mobile Application Security Testing Guide).
3.1.- Niveles de seguridad ASVS (v.4.0.3)
 ASVS Nivel 1 (Opportunistic):
o Deben cumplirlo todas las aplicaciones.
o Contiene 136 controles.
o Se alcanza ASVS Nivel 1 si app logra defenderse contra vuln. de seg. fáciles de descubrir,
incluido el Top 10 de OWASP y otras listas de comprobación similares.
 ASVS Nivel 2 (Standard)
o Deben cumplirlo apps con datos sensibles, y recomendable para todas las aplicaciones.
o Contiene 267 controles
o Se alcanza si se defiende ok contra mayoría riesgos asociados con el software hoy en día.
  ASVS Nivel 3 (Advanced).
o Deben cumplirlo apps críticas por el alto valor de las transacciones (ej, la bolsa), o por tratar
datos [Link] (ej, médicos) o apps que requieran alto nivel de confianza.
o Contiene 286 controles.
o Se alcanza si se defiende ok contra [Link] de seg. y demuestra principios de buen
diseño de seguridad.
4.- [Link]ón necesarios asociados al nivel de [Link].
Cada nivel ASVS v. 4.0.3 contiene lista de [Link]. Cada uno de ellos se puede asignar a caract. y
capacidades específicas de seguridad que se deben incorporar al software
Cada requisito tiene un identificador en el formato: v<version>-<capítulo>.<sección>.<requisito>
 Por ejemplo: v4.0.2-1.11.3 corresponde a Versión de ASVS 4.0.2
 El capítulo 1 es de Arquitectura.
 La sección 11 del capitulo 1: 1.11.  Requisitos de [Link] la lógica de negocio del [Link].
 Requisito 3 de sección 11 de capítulo 1, (1.11.3) Verificar que todos flujos de lógica de negocio de
alto valor, incluyendo la autenticación, gestión de la sesión y control de acceso son seguros para los
hilos y resistentes a las condiciones de carrera de tiempo de verificación y tiempo de uso.
El listado de controles generales en ASVS versión 4.0.3 es:
V1. Arquitectura, diseño y modelado de amenazas - V2. Autenticación
V3. Gestión de sesiones - V4. Control de acceso
V5. Validación, sanitización y codificación - V6. Criptografía en el almacenamiento
V7. Gestión y registro de errores - V8. Protección de datos
V9. Comunicaciones - V10. Código Malicioso
V11. Lógica de negocio - V12. Archivos y recursos
V13. Servicios Web y API - V14. Configuración
Dentro de cada capítulo  secciones con aspectos mas específicos.
PPS03. Detección y corrección de vulnerabilidades de
aplicaciones web.
Para proteger un aplicativo web debemos
 Controlar entrada de datos
o En especial en FORMULARIOS Mediante
 Higienización de variables
 Parámetros Dinámicos (bind)
 Control entrada datos
 Valorar las principales vulnerabilidades
o Como OWASP Top10 Con especial atención a
 Fallos criptográficos
 Pérdida Control Acceso
 Con especial atención a Proceso de
Autenticación v Autorización
 Inyección
 Lado cliente - Lado servidor
 Diseño Inseguro
 Configuración de seguridad defectuosa
 Aplicar contramedidas
o Como
 Controles de Sequridad - WAF

1.-Desarrollo seguro de aplicaciones web

2.- Entrada basada en formularios.
3.- Estándares de autenticación y autorización.
4.-Robo de sesión. Ataque por fuerza bruta, sniffing, propagación en URL, servidores compartidos.
Métodos de prevención.
5.- Vulnerabilidades web.
6.- Almacenamiento seguro de contraseñas.
7.- Contramedidas.
8.- Seguridad de portales y aplicativos web.

1.-Desarrollo seguro de aplicaciones web

OBJETIVOS DE LA SEGURIDAD

CONFIDENCIALIDAD INTEGRIDAD DISPONIBILIDAD

La info. sólo debe estar disponible Se sabe que los datos son Los usuarios con permisos pueden acceder
a quién debe tener acceso. correctos y confiables. a la [Link] la necesitan

Principales mecanismos:
 Autenticación Principales mecanismos: Principales mecanismos:
 Autorización  Validación de datos  Manejo de errores
 Gestión de sesión  Logging  Logging
 Logging  Encriptación  Encriptación
 Manejo de errores

OTROS OBJETIVOS DE LA SEGURIDAD

Resiliencia Robustez Trazabilidad Autenticación Fiabilidad
El SDLC seguro (ciclo vida desarrollo de soft seguro) es el habitual ciclo vida desarrollo soft, pero con
acciones de seguridad incorporadas en cada fase:
[Link]
[Link] ⇒ [Link]ÑAR
⇒
⇑ SDLC ⇓
⇐[Link] E ⇐
6. MANTENER
INTEGRAR [Link]
OWASP establece que un SDLC seguro es: “Cjto principios de diseño y buenas prácticas a implantar en el
SDLC, para detectar, prevenir y corregir defectos seguridad en desarrollo de aplicaciones,  se obtenga
[Link] confianza y robusto frente a ataques, que realice solo las funciones para las que fue diseñado, que
esté libre de vuln, intencionales o accidentales durante su ciclo de vida y se asegure su integridad,
disponibilidad y confidencialidad”. Además, recomienda:
 Implementar un ciclo de vida de desarrollo de software seguro
 Definir claramente roles y responsabilidades.
 Proporcionar a los equipos de desarrollo la formación adecuada en seguridad de software.
 Establecer estándares de codificación seguros
 Construir una biblioteca de objetos reutilizable.
 Verificar la efectividad de los controles de seguridad (ASVS, que ya vimos en la unidad 2).
 Establecer prácticas seguras de desarrollo subcontratado (definición requisitos seguridad y métodos
verificación).
 Establecer un modelo de amenazas y una matriz de amenazas
Principios a la hora de desarrollar el software (OWASP Development Guide):
 Minimizar ptos ataque. - Establecer valores predeterminados seguros.
 Mínimo privilegio (POLP). - Defensa en profundidad.
 Fallar de forma segura. - Segmentación.
 No confiar en los sistemas externos: validar datos de entrada y salida.
 Evitar la seguridad por ocultación. - Simplicidad de diseño de la seguridad.
 Corregir probl. seguridad correctamente. - Registrar los eventos de seguridad
Cjto de buenas prácticas (OWASP Development Guide, + info en CheatSheets OWASP): Se agrupan en:
 Validación de entradas (y de salidas). - Autenticación y gestión de contraseñas
 Administración de sesiones - Autorización y control de acceso.
 Criptografía. - Manejo de errores y logs.
 Protección de datos. - Manejo de archivos.
 Manejo de memoria. - Seguridad en las comunicaciones.
 Seguridad en las BBDD. - Configuración segura de los sistemas.
 Codificación en general.

2.- Entrada basada en formularios.

Un formulario se diseña para que usuario introduzca datos estructurados para ser registradas y procesados
posteriormente. Los elementos más comunes son: Cajas de texto, Listas de selección, Checkbox, Botones,
Listas desplegables. Si formulario no está configurado y protegido ok  puede ser manipulado para prodcucir
acciones inesperadas (obtener contenido de BBDD, eludir autenticación, introducir contenido malicioso en
BBDD o aplicación)  se llaman ataques de inyección.  Importante que aplicativo valide correctamente
entradas de datos, compruebe si contenido se corresponde con lo esperado, que higienice la entrada de
caracteres extraños y recomendable que interacción con BBDD sea a través de interfaz parametrizada o de
herramienta de ORM.
Habitualmente tienen como objetivo cambiar el comportamiento del aplicativo web se comporta como en el
caso de SQL Inyection (Server Side inyection). Pero hay otro tipo de ataques que tienen como objetivo el
propio usuario (robar info. usuario o sus cookies). Son Client Side Inyection y los ej. más claros son los
ataques de tipo XSS (Cross-Site-Scripting) y HTML Inyection.
Uno de los ataques más importantes son los de robo de sesión (Session Hijacking), usan ataques de
inyección del lado cliente para robar cookies del usuario y usar esa cookie (que garantiza una sesión
autenticada y autorizada en un recurso) de forma maliciosa.
3.- Estándares de autenticación y autorización.
Autenticación Básica (Basic Auth): El método más simple (usuario y contraseña). Se recomienda en Ss
web si datos a intercambiar no tienen muchas restricciones de uso. Este tipo de autenticación puede ser
utilizado tanto con un tipo de servicio web de tipo REST como SOAP.
Autenticación con certificados: Se solicita el [Link] del cliente y verificando cada mensaje enviado
contra dicho certificado garantizando que cliente es quien dice ser. Tedioso xa autenticar usuarios, pero útil
para autenticar otro servicio web ya que se integra en protocolo HTTPS y asegura identificación,
autenticación, confidencialidad e integridad.  Esta modalidad se conoce como autenticación mutua TLS.
Autenticación mediante cookie de sesión: El usuario se autentica con usuario y contraseña u otro método,
el servidor crea una sesión en su memoria/BBDD y devuelve la [Link] usuario a través de una cookie con el
id. de la sesión creada. En cada solicitud, se pasa el id. y el servidor da acceso si esa sesión esta activa.
Autenticación mediante token: Después de tener usuario y contraseña validados por servidor, se crear un
token que el cliente recibe como respuesta y que le permitirá acceder a algún recurso. El token no se guarda
en el servidor. Es el + usado en Ss de tipo REST (compacto y autocontenido, en formato JSON).
Autenticación OAuth (v1 y v2) 2 versiones: OAuth 1.0a y OAuth2 (la + usada).
4.-Robo de sesión. Ataque por fuerza bruta, sniffing, propagación en
URL, servidores compartidos. Métodos de prevención.
El robo de sesión es una técnica para acceder a cuentas de usuario sin permiso con el secuestro de sesión
de usuario legítimo, asumiendo su identidad en posteriores acciones. Formas de robo de sesión:
Por fuerza bruta
El atacante intenta descifrar la contraseña del usuario probando posibles combinaciones.  Lento por numero
de posibles combinaciones pero si contraseña débil o predecible, el atacante tendrá éxito rápidamente. Los
usuarios deben utilizar contraseñas fuertes y únicas (mayus, minusc, números, caracteres especiales) y los
servidores implementar medidas, como bloqueo después de un nú[Link] fallidos.

Sniffing de sesiones
Los atacantes interceptan datos de sesión que viajan a
través de la red x uso de conexión no segura o x
explotan vulnerabilidades en la red.
Para prevenir sniffing de sesión  usar conexiones
seguras con cifrado (ej. HTTPS) y evitar redes Wi-Fi
públicas para acceder a aplicaciones con info sensible.
Los servidores también pueden implementar medidas
como usar encabezados HTTP seguros y políticas de
seguridad de contenido (CSP), para proteger a los usuarios contra ataques de sniffing de sesión.
Cross-Site Scripting (XSS)
Permiten a atacantes inyectar código malicioso en una web, que se ejecuta en el navegador del usuario y
puede usarse para robar cookies de sesión o info. de autenticación.
Phishing
Engañar a usuarios para que revelen credenciales a través de sitios web o email falsos. Para evitar ataques
de phishing los usuarios han de ser cautelosos y verificar autenticidad de enlaces que visitan, mejor escribir la
dirección directamente en el navegador que clic en enlaces.
Propagación por URL
Gran variedad de técnicas o conceptos relacionados con la propagación de URLs maliciosas o engañosas en
ataques. Aquí hay algunos conceptos relacionados:
 Phishing por URL: Envio de vínculos a webs falsas que imitan sitios legítimos xa engañar a usuarios
y revelen info. como contraseñas o datos financieros. Los atacantes pueden propagar estas URL
maliciosas a través de correos electrónicos, mensajes de texto u otras formas de comunicación.
 Difusión de malware por URL: URLs que conducen a sitios web o descargas de archivos que
contienen malware (virus, troyanos o ransomware).
 URL acortadas: Los Ss de acortamiento de URL, como Bitly o TinyURL, se utilizan para convertir
URLs largas en versiones más cortas y fáciles de compartir. Los atacantes pueden aprovecharse de
esto para ocultar las URL maliciosas y hacer que parezcan seguras.
 Propagación de enlaces maliciosos en redes sociales: Los atacantes a menudo utilizan
plataformas de redes sociales para compartir enlaces maliciosos o engañosos que redirigen a los
usuarios a sitios web o contenido peligroso.
5.- Vulnerabilidades web.
Perdida del Control de Acceso: El control de acceso hace cumplir la política de modo que usuarios no
puedan actuar fuera de sus permisos. Consecuencias de la vulnerabilidad:
 Divulgación de info. no autorizada
 Modificación/destrucción de datos.
 Realización de una función fuera de los límites del usuario.
Fallos criptográficos: La [Link], deber almacenarse/trasmitirse sin expuesta indebidamente.
Consecuencias de la vuln: exponer [Link], (con posibles consecuencias penales y de reputación).
Inyección: Incluye: Secuencia de Comandos en Sitios Cruzados (XSS, CWE-79), Inyección SQL (CWE-89) y
Control Externo de Nombre de archivos o ruta (CWE-73). CWE = Common Weakness Enumeration. Se deben
validar/limpar toda entrada y salida de datos.
Diseño inseguro: Representa diferentes debilidades, expresadas como "diseño de control faltante o
ineficaz". Las princip CWE son CWE-209: Generación de mensaje de error con [Link], CWE-256:
Almacenamiento desprotegido de credenciales, CWE-501: Violación de fronteras de confianza y CWE-522:
Credenciales protegidas insuficientemente.
Configuración de seguridad defectuosa: Sin un proceso concertado y repetible de configuración de la
seguridad de las aplicaciones, los sistemas corren un mayor riesgo. Ejemplos:
 Falta un “hardening” de seguridad apropiado en cualquier parte de la pila de aplicaciones o se
configuran incorrectamente los permisos en los servicios en la nube.
 Se han habilitado funciones innecesarias (ej, puertos, Ss, páginas, cuentas o privilegios innecesarios).
 Cuentas por defecto y sus contraseñas siguen habilitadas y sin cambios.
 El manejo de errores revela rastros de pila u otros mensajes de error informativos para atacantes.

6.- Almacenamiento seguro de contraseñas.

Lo mejor es evitar almacenar o gestionar cualquier info. sensible salvo que sea estrictamente
necesario. Pero si lo es:
Cifrado: Permite cifrar info. de clave simétrica o asimétrica (+seguro pero requiere +carga computacional).
Funciones Hash: Permite guardar una imagen hash de la contraseña en vez de la misma contra. Pequeños
cambios en la contra.  grandes cambios en su hash  muy complicado obtener la contraseña del usuario.
Los algoritmos hash mas usados son SHA1, SHA2, SHA3. Antiguamente MD5 pero no seguro.
Protocolos: Muchos protocolos llevan embebidas funciones hash y sistemas de cifrado. Ej: openssl.
7.- Contramedidas.
CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart). Pruebas de tipo
desafío-respuesta que permite a los apps web saber si usuario real y reducir ataques de tipo botnet.
HSTS (HTTP Strict Transport Security) Mecanismos que soportan los servidores y navegadores web para
evitar robo de sesiones y datos de [Link] que atacante intercepte comunicación entre cliente-servidor
y robe/espie contenido o degradase la seguridad.
CSP (Content Security Policy): Estándar que define un cjto de orígenes pre-aprobados desde donde un
navegador puede cargar recursos o ejecutar scripts cuando un usuario visita una web. Un navegador
compatible con CSP solo ejecuta scripts de archivos fuentes especificados en esa lista blanca de dominios,
ignorando cualquier otro script (incluyendo los scripts inline y atributos de HTML de manejo de eventos).
Surgió para dar respuesta a ataques de tipo Cross Site Scripting (XSS).
8.- Seguridad de portales y aplicativos web.
El programador trata de garantizar código seguro y se comporte de forma esperada, pero a veces intervienen
otros componentes como BBDD que escapan de su control  + difícil garantizar comportamiento esperado.
Un WAF opera en el backend xa salvaguardar la seguridad del servidor web al llevar a cabo análisis, filtrado
y bloqueo de paquetes de solicitud HTTP/HTTPS. El WAF examina las solicitudes al servidor antes de que
alcance la aplicación, asegurándose de que cumpla con reglas predefinidas del firewall. Los WAFs saben
cómo funciona un aplicativo web, cómo interacciona con la BBDD y que tipo de datos suelen entrar y salir del
aplicativo, detectando ataques de manera más sencilla.  al instalar un WAF esta meses aprendiendo cómo
funciona la app, qué datos maneja, cuándo se conectan usuarios y demás. Son capaces de detectar redes de
bots, bloqueando estas conexiones y reduciendo el impacto de los ataques de denegación de servicio.
Las características WAF pueden ser implementadas:
 Como software: prog independiente, o complemento de servidor web (ej, módulo ModSecurity de
[Link] o Nginx) o como "plugin" de gestor de contenidos (ej:, WP WAF en Wordpress).
 Como un servicio de nube: todos los "cloud" disponen de servicio WAF (por ejemplo, el AWS WAF ).
 Con un hardware específico (por ejemplo, los Barracuda web application firewall 860)
PPS04. Detección de problemas de seguridad en
aplicaciones para dispositivos móviles
Los dispositivos móviles tienen los siguientes mecanismos de seguridad
 Controlar entrada de datos En especial en
o Controlar el acceso a datos o funciones Mediante
 Permisos Mediante
 Entornos controlados de sandboxing
 Llamadas al sistema protegidas Mediante
 Entornos controlados de sandboxing
 Controlar las Aplicaciones Mediante
o Firmado aplicaciones
 Permiten Garantizar seguridad y legitimidad
de las aplicaciones
o Control de las tiendas oficiales
 Permiten Garantizar seguridad y legitimidad
de las aplicaciones
 Securizar la información interna
o Mediante Cifrado información
 Para prevenir Fuga Información
 Validación compras
o Mediante Securización compras A través de
 Canales seguros
 Confirmación usuario
 Tecnología
o Como CASB Que permite
 Controlar interacción con la nube
 Monitorizar
 Establecer políticas y reglas
1.- Modelos de permisos en plataformas móviles. Llamadas al
sistema protegidas.
2.- Firma y verificación de aplicaciones.
3.- Almacenamiento seguro de datos.
4.- Validación de compras integradas en la aplicación.
5.- Fuga de información en los ejecutables.
6.- Soluciones CASB.

Hoy en día los móviles objetivo de cibercriminales (de forma directa o mediante apps maliciosas) xa entrar a
los datos. Los dispositivos cuentan con protecciones xa las amenazas. El SO usan mecanismos para proteger
la seguridad de los datos (de los princip. El sandboxing,)

1.- Modelos de permisos en plat.móviles. Llamadas al [Link].

Cada plataforma define un esquema de permisos xa que apps al intentar acceder a un recurso sin haber
solicitado permiso, se genera excepción de permiso y app interrumpida. Tanto iOs como Android ejecutan
apps en sandbox. En Android cada app funciona con un usuario especifico creado para esa app y en iOS
todas se ejecutan con mismo usuario ("mobile") y cada app tiene un directorio de inicio único para sus
archivos asignado aleatoriamente al instalarla.
Cuando se instala una app en Android que necesita acceder a funcionalidad (fotos, cámara, contactos, etc)
solicita permiso y usuario verifica si es lícito o no. Hay accesos estándar y los más especiales o peligrosos (no
acceso a estos sin consentimiento explícito). Las apps deben declarar antes de publicarse en la tienda oficial
a que recursos necesitan tener acceso.
En iOS algo distinto: las apps acceden sólo a funciones que sistema habilita y resto no permitido. Cuando app
quiere acceder a info. usuario usa un entitlement o permiso firmado digitalmente. Cuando app quiere acceso a
cámara, fotos, ubicación, etc, debe aprobarse explícitamente por usuario (simil Android).
2.- Firma y verificación de aplicaciones.
Tiendas no oficiales foco de Malware. Para solucionarlo todas apps deben pasar controles en tienda oficial.
Uno de ellos son las firmas digitales (firmadas por desarrollador y si no rechazadas por tienda y dispositivo
no permitirá instalarla). Dentro de los controles de tiendas oficiales para alojar una app, podríamos destacar:
 Una revisión exhaustiva de la la interacción que hacen con los datos de usuario.
 Los permisos que solicitan o requieren.
 Actualizaciones periódicas.
 Seguir y cumplir una serie de normas y políticas establecidas por la tienda oficial, etc.

3.- Almacenamiento seguro de datos.

Los SO móviles dotan de seguridad a los datos almacenados mediante su cifrado (lo + común el cifrado de
todo el [Link] con [Link] simétrico/ asimétricos). Cuando usuario legítimo introduce su clave o
accede con biométria  esta [Link] usa como clave para descifrar y usuario pueda acceder a datos.
Keystore (Android) genera y almacena de forma segura las claves usadas en los [Link] cifrado, tanto xa fase
de cifrado como la de descifrado.
En iOS se puede usar Keychain. Keychain permite almacenar directamente info del usuario encriptada x API
de Keychain. También podemos usar Keychain idem Keystore en Android para almacenar las claves para
cifrar/descifrar info almacenada
Vital definir en fase de diseño apps robusta y correcta estrategia para almacenado de datos sensibles.
4.- Validación de compras integradas en la aplicación.
La validación de compras esencial para prevenir fraudes, garantizar autenticidad de transacciones y proteger
la info financiera de usuarios. Desafíos: falsificación compras, robo identidad y [Link] transacciones.
La compra con apps sigue [Link]ón, desde canales seguros de [Link] prevenir Man-In-The-
Middle cómo autenticación y validación expresa por parte del usuario. Veamos algunos de estos mecanismos:
1. Criptografía y Firma Digital:
Algoritmos criptografía robustos y firmas digitales ayuda a asegurar integridad de datos de compra impidiendo
manipulación de info. durante transmisión  solo transacciones legítimas sean aceptadas.
2. Autenticación Multifactor (AMF):
Ana capa adicional de seguridad, exigiendo verificación
identidad mediante múltiples métodos: contraseñas,
códigos de un uso, biometría….  dificulta usurpación de
cuentas y fortalece la autenticación.
3. Monitoreo de Patrones Anómalos:
Permite detección temprana de patrones de actividad
inusuales/[Link]. Esto posibilita respuestas
rápidas ante posibles amenazas y minimiza el impacto de
posibles incidentes de seguridad.
5.- Fuga [Link] los ejecutables.
Los ejecutables de las apps móviles pueden ser analizados
y manipulados con el objetivo de obtener [Link],
eludir medidas seguridad, introducir malware o incluso
realizar ataques de falsificación de identidad.
La ingeniería inversa permite extraer info. del código fuente analizando el código binario (análisis estático) o
la ejecución (dinámico) xa comprender su estructura interna y lógica de funcionamiento.  abre la puerta a
posibles actividades maliciosas.  descubrir [Link] de la app, vulnerabilidades de seguridad y
algoritmos críticos. Se realiza a menudo con [Link] decompilación.
También existe la posibilidad del Tampering, o manipulación no autorizada de apps móviles alterando el
binario o su entorno para afectar a su comportamiento para eludir medidas de seguridad, introducir malware o
ataques de falsificación de identidad.
Para mitigar estos riesgos  medidas defensivas: ofuscación de código, cifrado robusto y la implementación
de técnicas de detección de manipulación xa, no solo proteger prop intelectual e info confidencial, sino tb xa
preservar integridad y autenticidad apps.
6.- Soluciones CASB (Cloud Access Security Brokers).
El dato no solo en disp, tb en Ss en entornos cloud.  problemas desde poco control a no tener reglas de
detección y bloqueo. Muchos usuarios (teletrabajo) usan sus disp.móviles para acceder a Ss en nube (correo,
imáenes, ficheros…) corporativos o de terceros perdiéndose trazabilidad y control info. Es donde entra
tecnología de CASB aportando visibilidad sobre la info, monitorización y trazabilidad (saber qué flujo sigue un
documento o qué tipo de info sale o entra del disp). Esta tecnología se está extendiendo rápidamente en Eas
x necesidad de securizar además de tu entorno y servidores, los entornos de nube y, sobre todo, los móviles.
CASB a nivel técnico funciona como agente instalado en dispositivo que recibe centralizadamente lista de
políticas y reglas y que detecta lo que hace el dispositivo, limita acceso a Ss de nube o previene subida o
bajada de determinada info. Algunas [Link] avanzada disponen de capacidad UEBA (User and Entity
Behaviour Analitycs) que analizan patrones de comportamiento de los usuarios.
La mayoría de estas soluciones cifran los datos antes de enviarlos a la nube  capa de seguridad adicional.
PPS04. IMPLANTACION DE SISTEMAS SEGUROS DE
DESPLEGADO DE SOFTWARE
 Metodologías
o DevOps Se basa en
 Estrategia Colaborativa
 Desarrollos Cortos Como Sprints
 Interacción con el cliente
o Scrum
 Se basa en Sprints Genera Bucles de revisión v feedback
 Control de versiones Ventajas
o Gestión del cambio Como Git
o Gestión de las versiones Como Git
 Integración continua Mediante
o Backups y sistemas de recuperación En Repositorio
o Trabajo Colaborativo Como Repositorio
 Contenedores aportan Entorno seguro y controlado (Docker)
 Orquestación de Contendores Ayudan Escalabilidad Como Kubernetes
Trabaja con Docker
1.- Puesta Segura en producción y DevOps.
1.1.- Desarrollo Ágil.
2.- Control de versiones.
3.- Sistemas de automatización de construcción
4.- Integración continua y automatización de pruebas.
5.- Virtualización y contenedores.
6.- Gestión automatizada de configuración de sistemas
7. Herramientas de simulación de fallos
8.- Orquestación de contenedores.

El ciclo de [Link] ha cambiado mucho últimos años, modelos como

DevOps con entregas y alineamientos continuos con [Link] han
cambiado metodología y cultura en desarrollo. Con comunic,continua con
cliente, entregas cortas y continuo alineamiento con necesidades reales. Por
otra parte hay que garantizar seguridad en implantación y posibilidad de colaboraborar miembros equipo (git)
1.- Puesta Segura en producción y DevOps.
La puesta segura en [Link] código ha evolucionado últimos años, ahora desarrollos en equipo (los
desarrolladores conocen en T real desarrollo resto compañeros) y muy cercano al cliente. Esta metodología
engloba un cjto prácticas que agrupan desarrollo de software (Dev) y operaciones de TI (Ops). Además
la seguridad de la TI tb debe desempeñar papel en ciclo vida apps DevSecOps (Dev+ Sec + Ops). Implica
pensar desde principio en seguridad de apps e infraest. Tb automatizar controles seguridad para impedir que
se ralentice el flujo de trabajo de DevOps. Ventajas DevOps:
 Las versiones más frecuentes  alinear la expectativa del cliente de forma más sencilla.
 Cualquier cambio en el proyecto se puede corregir con más facilidad.
 El software tiene más calidad al estar enfocado en objetivos más concretos.
El enfoque DevOps abarca varias fases ciclo vida desarrollo software (esencial automatización con
herramientas en todas para lograr entrega continua y eficiente). Fases típicas:
 Planificación (Plan): se establecen los sprints (término Agile) y se asignan tareas a desarrolladores.
 Codificación (Code): se desarrolla el código y se hacen pruebas unitarias.
 Construcción (Build): se utilizan [Link]ón para crear artefactos de lanzamiento (copia
aislada del código compilado/"configurado" que puede desplegarse en los entornos pruebas/ prodción)
 Pruebas (Test): la nueva versión software se somete a serie pruebas para ver si ok xa producción.
 Lanzamiento (Release): garantizar que infraestructura y entorno preparados para lanzar el software.
 Despliegue (Deploy): equipo de ops se coordina para copiar artefactos probados en [Link]ón.
 Funcionamiento (Operate): en esta fase [Link] debe garantizar que componentes de la
infraestructura permanezcan en línea y crezcan con la demanda según sea necesario.
  Monitorización (Monitor): la recopilación y análisis de datos del software ([Link], registro
accesos, errores...), junto con comentarios usuarios y revisión de procesos  mejoras.
Existen cjtos ("toolchains") de herramientas.  Control de versiones Git
La metodología DevOps debe integrar seguridad en
todas fases para que tb sea segura. DevSecOps. No Automatización de la construcción Jenkins
solo incorporar herr. nuevas, sino tb enfoque distinto, Pruebas Selenium
automatizar seguridad para proteger entorno y datos
en proceso de integración y distrib. continuas. Se Gestión de la configuración Terraform
busca fomentar cultura colaborativa donde equipos Implementación Kubernetes
trabajan juntos e identifican/abordan proactivamente
vuln, permitiendo entrega rápida y segura. Monitorización ELK Stack
1.1.- Desarrollo Ágil.
Para adaptarnos a cambios del cliente surgen las metodologías ágiles en el desarrollo. Principios básicos:
1. Satisfacción del cliente mediante la entrega temprana y continua de software de calidad.
2. Gran aceptación y respuesta al cambio de los requisitos definidos durante el proyecto.
3. Entrega frecuente de software funcional, periodos 2-6 semanas.
4. Trabajo conjunto entre el cliente y desarrolladores.
5. Creación de equipos motivados y respaldados.
6. Comunicación cara a cara desarrolladores-cliente.
7. Equipos auto-organizados.
8. Reflexión continua para mejorar efectividad y realizar ajustes para corregir cualquier desviación.
De entre ellas surge Scrum,  metodología ágil con principios que ayudan a equipos a desarrollar pdtos en
periodos cortos (sprints), obteniendo rápidam. feedback, adaptaciones y mejora continua. Dentro de los
Sprints tb se hacen ciclos de verificación o bucles, y sim. Fallos xa verificar y mejorar calidad software.
2.- Control de versiones.

Los equipos trabajan con [Link] versiones (VCS), son [Link] que gestionan, administran y
controlan (creación, adición, eliminación, modificación del código) sobre un repositorio común disponible
para todos desarrolladores y permite trabajo colaborativo (todo aceso a código y saber quién cambia qué y
cuándo). Tb permite tener un backup del código y recuperarnos ante error/problema. Este repositorio es el
rtdo visible de lo que se conoce como Integración continua (práctica desarrollo software donde prog.
combinan cambios en [Link] periódicam, tras lo cual se ejecutan versiones y pruebas automáticas).
 Revertir y corregir cambios de manera sencilla. - Copia de seguridad o backup del código.
 Resolución de conflictos cuando uno o más miembros modifiquen el mismo fichero a la vez.
Algunos ejemplos de herramientas populares para el control de versiones son:
 Git: Permite llevar registro cambios en código a lo largo T, trabajar en ramas y colaborar en proyectos.
GitHub y GitLab utilizan Git. En Git un archivo puede estar en: estado modificado, preparado o
confirmado. Mediante Git podremos clonar repositorio, podremos construirlo (build) de manera
automática usando el mismo código que han usado los desarrolladores para crearlo.
 Subversion (SVN): Ha perdido popularidad frente a Git, herramienta control versiones centralizada.
Permite mantener historial de versiones y realizar seguimiento de cambios en archivos y directorios.
3.- Sistemas de automatización de construcción
La automatización es una de las princ. claves en DevOps (reducción T + minimizar riesgo de errores). La
entrega y despliegue continuo (CI/CD) son fundamentales en ámbito DevOps que buscan optimizar y acelerar
ciclo vida desarrollo software. La entrega continua (CI) implica [Link] de construcción, prueba y
empaquetado, garantizando que código probado y funcional siempre disponible para desplegar. El
despliegue continuo (CD) lleva la automatización más allá al liberar automá[Link] versiones software en
entornos prod. tras las pruebas pertinentes. Las [Link] automat. tareas CI/CD permiten reducir errores,
acelerar T entrega y garantízar coherencia en [Link]. Los equipos se centran en innov. y desarrollo
Jenkins: [Link]ón de código abierto para facilitar CI/CD. Funciona como un
[Link] automatización que permite definir, programar y ejecutar flujos trabajo
automatizados, desde compilación y prueba hasta implementación en [Link]ón. Usa
arquitectura extensible y +++ complementos, Jenkins se integra con otras herr. y Ss,
permitiendo orquestación [Link]. Los conceptos clave de Jenkins: creación trabajos,
gestión pipelines, monitorear y visualizar estado procesos de construcción y despliegue.
Circle CI plataf. CI/CD basada en la nube. Permite automatizar proceso construcción, prueba y
despliegue apps en entornos diversos. Usa pipelines configurables para definir flujos trabajo
facilitando orquestación tareas complejas. Con soporte <> [Link]ón y frameworks. Se integra
fácilmente con repos.código en GitHub y Bitbucket. Se enfoca en escalabilidad y velocidad  opción popular
permitir acelerar ciclo de vida del desarrollo y mantener la calidad del software a lo largo del tiempo.
GitHub Actions [Link]ón integrada en el entorno GitHub, para facilitar automatización
flujos trabajo. Permite definir, personalizar y compartir flujos trabajo CI/CD.
4.- Integración continua y automatización de pruebas.
La automatización pruebas en CI/CD papel crucial en mejora calidad software y eficiencia proceso desarrollo.
Creación y ejecución automatizada de pruebas a lo largo [Link] en el pipeline de CI/CD xa identificar
rápidamente posibles problemas y garantizar que actualizaciones no introduzcan regresiones.
Pruebas unitarias: Para validar que cada componente realiza sus tareas aisladam y produce rtdos
esperados. No sólo durante desarrollo, tb deben hacerse en el CI/CD para asegurar software correcto y
seguro. Ejemplos herr: PHPUnit, JUnit, NUnit, pytest, Jasmine
Pruebas de Integración: verifican que uds funcionen Ok cuando se combinan. Objet. identificar conflictos en
la interfaz y asegurar que <> elem. software trabajen Ok en conjunto. Ejemplos: TestNG, Mocha, Protractor
Pruebas de Aceptación: Evaluan comportamiento global app desde perspectiva usuario final, verificando
que funciones y caract. se desempeñen según lo esperado. Al integrar esta pruebas en un pipeline de CI/CD,
aseguramos que nuevas implementaciones no solo técnicamente sólidas, sino tb cumplan con expectativas
usuario. (este testing es como un robot que usa app, simulando acciones y peticiones realizadas desde un
navegador. Ejemplos: Selenium WebDriver, Cucumber, Cypress
Pruebas de Seguridad: Buscan identificar/mitigar vuln. y riesgos seguridad, se automatiza evaluación
posibles amenazas. Ej: OWASP ZAP, Burp Suite, Nessus, Acunetix, SonarQube, Docker scan
5.- Virtualización y contenedores.
Uno de los problemas en desarrollo y despliegue apps es la heterogeneidad entre [Link] desarrollo entre
desarrolladores y tb en sist desarrollo, entornos pruebas, preproducción y producción (librerías y SO <>que
hace que puede que una app ok en unos pero no en otros). Tenemos que asegurar que equipo desarrollo usa
misma V. de las aplicaciones y librerías necesarios. Es + difícil de lo que parece (desarrolladores prefieren
unos a otros, concurrencia de desarrollos en <> entornos, …)  Importante que desarrolladores creen código
en entornos controlados y replicables (máquinas virtuales/ contenedores).  tecnologías de virtualización
que permiten optimizar eficiencia y flexibilidad en despliegue de aplicaciones (con <> enfoque y caract.).
Las máquinas virtuales son entornos completamente aislados que emulan SO completos dentro de un
hipervisor. Cada VM SO propio + recursos dedicados. Alto nivel de aislamiento permitiendo ejec. Apps en
entornos distintos pero > consumo recursos y T de inicio x carga SO completo.
Contenedores son entornos ligeros que comparten núcleo (kernel) del SO subyacente (+eficientes en
recursos y T inicio). Encapsulan solo bibliotecas y dependencias necesarias para ejecutar app específica
permitiendo rápida implementación y escalabilidad. Se exportan y usar en segundos permitiendo que todos
trabajen con mismas herr, y si desarrollador está en varios proyectos usar contenedores distintos xa cada 1.
La elección depende de requisitos proyecto. VMs si se requiere de aislamiento más estricto (ej. Si SO <>),
Contenedores para implementaciones ágiles y escalables donde eficiencia recursos prima. Ej. plataformas de
VM son VMware, KVM y VirtualBox, mientras que Docker es habitual xa gestión contenedores.
Veamos un poco más en detalle Docker:
 Se basa en imágenes (representación ligera y portátil
de un [Link] que incluye app + dependencias).
 Un contenedor es una imagen ejecutándose en un
sistema. Ej, imagen de Debian con Apache Tomcat +
Mysql que se puede lanzar en un [Link] creando un contenedor. El contenedor puede tener IP
propia y comparte recursos hardware con el resto apps corriendo en sistema (se pueden fijar límites).
 Docker tiene un registro central con todo tipo de imágenes (Docker Hub).
 Docker ofrece herramientas de gestión de cluster con Swarm y Compose.
  La arquitectura de docker está compuesta de:
o El cliente de Docker (Docker Client) interfaz de usuario para Docker. Acepta comandos del
usuario y se comunica con el demonio Docker.
o El demonio Docker (Docker Engine) corre en maquina anfitriona (host). Usuario no interactúa
con demonio  cliente Docker interactúa con él.
o [Link] levanta [Link] imágenes en local o en el Docker Registry ([Link]ág).

6.- Gestión automatizada de configuración de sistemas

En orgs con >> máquinas (físicas o virtuales) un desafío es automatizar procesos para preparar la
infraestructura, gestionar configuración, implementar apps y organizar sistemas, mejorar seguridad y el
cumplimiento, ejecutar parches y compartir automatización en toda Eª, entre otros procedimientos de TI.
Las herr. gestión automatizada de configuración de sistemas aseguran consistencia e integridad de la config.
a lo largo T, facilitan automatización tareas repetitivas y simplifican implementación/actualización de software.
Ansible se centra en gestión de config, implementación apps y automat. tareas. En Python. Usa
enfoque basado en [Link] código (IaC)  las configs y tareas se definen en archivos de
config. Con un modelo de ejecución basado en SSH, los usuarios especifican cómo deberían estar
configurados sistemas y Ss, y Ansible las aplica consistentemente en todos nodos sistema. Su diseño
sin agente (también admite con agente) y su arquitectura modular  escalable y fácil de implementar.
Puppet [Link]ón config. código abierto para automatizar y gestionar config. sistemas
informáticos. Usa enfoque declarativo, admins definen estado deseado sistemas, y Puppet se los
lleva a ese estado de manera coherente. En Ruby. Puppet usa lenguaje específico del dominio
(DSL) para describir configs y políticas. Usando modelo cliente-servidor, los nodos gestionados por Puppet se
conectan a [Link] que distribuye y aplica configs definidas. Se usa mucho xa gestión infraestructura,
desde config. servidores hasta instalación de software y la gestión de recursos de red.
Chef Se enfoca en gestión de config. y automatización de infraestructura. Enfoque basado en
código, Admins describen config. deseada de sistemas en forma de "recetas" y "roles". Las
recetas definen cómo deben configurarse y qué software debe estar instalado en cada nodo.
Opera en modelo cliente-servidor, donde nodos gestionados se conectan a servidor Chef para obtener y
aplicar configs definidas. Chef destaca x flexibilidad y capacidad gestion entornos pequeños y grandes.
7. Herramientas de simulación de fallos
La simulación de fallos es esencial en ingeniería de software y gestión sistemas  reproducir
condiciones adversas de forma controlada para evaluar resistencia y capacidad recuperación del
sistema (robustez, resiliencia). Herr. como "Chaos Engineering" populares para implementar
controlada y gradualm. simulación de fallos xa fortalecer sist.y Ss en condiciones adversas
simuladas antes de enfrentar eventos reales no planificados.  contribuye a mejora continua
fiabilidad y la disponibilidad de sistemas críticos. Ej. Chaos Monkey xa entornos basados en microservicios
que introduce deliberadamente fallos en nodos o Ss en prodción para evaluar capacidad xa resistir y
recuperarse eventos inesperados (ej. desconexión nodos, introducción retrasos en la red o generación errores
en capa de aplicación).  equipos pueden descubrir debilidades potenciales, optimizar recuperación
automática y mejorar la resiliencia general del sistema frente a eventos disruptivos del mundo real
8.- Orquestación de contenedores.
Un orquestador es herr. o plataf. que
coordina y gestiona ejec. procesos o Ss de
manera eficiente y automatizada en entorno
computacional. Son esenciales en entornos
complejos/distribuidos, xq <> componentes
deben trabajar juntos coordinadam. Tipos:
Orquestador de Infraestructura como
Terraform y AWS CloudFormation, se
centran en provisión y gestión recursos de
infraestructura en la nube, como servidores
virtuales, redes, BBDD y otros Ss.
Trabajan a nivel más bajo, proporcionando
capa de abstracción sobre recursos físicos y
permitiendo definición y gestión de infraestr.
como código (IaC). Se centran en VMs,
almacenamiento y redes.
Orquestador de Contenedores como Kubernetes y Docker Swarm, xa gestionar C.V apps contenerizadas,
desde implementación y escalado hasta admin. recursos y orquestación Ss. Operan en un nivel más alto,
enfocándose en contenedores y apps, ofreciendo abstracciones que facilitan gestión y orquestación múltiples
instancias apps. Especializados en gestionar despliegue/escalabilidad de contenedores. Tareas habituales:
 Búsqueda Ss (Service Discovery) que permite acceso <> contenedores del cluster.
 Balanceo carga.
 Configuración red.
 Escalabilidad.
 Registro (Logging) y Monitoreo.
 Respuesta a fallos.
Ambos tipos de orquestadores desempeñan roles distintos, a menudo se usan de manera complementaria en
entornos de desarrollo y operaciones.