MÓDULO 1 - UNIDAD 3

Professional Testing Master Nivel

Avanzado

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 2

Módulo 1
Unidad 3: Testing especializado

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 3

Presentación:
En esta tercera unidad del curso, nos enfocaremos en tres tipos especializados de testing:
el testing de seguridad, cada vez más importante en estos días, el testing de web
services, también fundamental debido al crecimiento de uso y el testing de performance.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 4

Objetivos:
Que los participantes:

● Comprendan el desafío que implica la seguridad de un sistema y cuenten con una

guía para poder implementar el testing de seguridad en forma rigurosa.
● Adquieran las nociones más importantes sobre webservices y la manera de
probarlas.
● Conozcan los principales factores a tener en cuenta a la hora de realizar pruebas
de performance.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 5

Bloques temáticos:
1. Testing de seguridad 9
1.1. Introducción 9
1.2. Planificación del testing de seguridad 9
1.3. Especificación del testing de seguridad 9
1.4. Aspectos formales y legales del testing de seguridad 10
1.5. Testing de los mecanismos de seguridad 10
1.5.1. Endurecimiento del sistema (system hardening) 10
[Link]. Comprendiendo el endurecimiento del sistema 11
[Link]. Comprobando la efectividad de los mecanismos de endurecimiento 12
1.5.2. Autenticación y Autorización 13
[Link]. La relación entre la autenticación y la autorización 13
[Link]. Comprobando la efectividad de los mecanismos de autenticación y
autorización 14
1.5.3. Encriptación 15
[Link]. Entendiendo la encriptación 15
[Link]. Comprobando la efectividad de los mecanismos de encriptación 16
1.5.4. Firewalls y Zona de redes 17
[Link]. Entendiendo Firewalls 17
[Link]. Comprobando la efectividad de los Firewalls 18
1.5.5. Escaneo de malware 18
[Link]. Entendiendo las herramientas para el escaneo de malware 18
[Link]. Comprobando la efectividad de las herramientas para el escaneo de
malware 19
1.5.6. Ofuscación de datos 20
[Link]. Entendiendo la ofuscación de datos 20

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 6

[Link]. Comprobando la efectividad de los enfoques de ofuscación de datos 21

1.5.7. Capacitación 21
[Link]. La importancia de la capacitación en seguridad 21
[Link]. Cómo comprobar la efectividad de la capacitación en seguridad 22

2. Introducción a OWASP 22
2.1. OWASP Top 10 23

3. Testing de webservices 25
3.1. Fundamentos de las APIs 25
3.1.1. ¿Qué es una API? 25
3.1.2. API SOAP 25
3.1.3. API REST 26
3.2. Testing funcional de una API 26
3.3. Desafíos del testing de APIs 26
3.3.1. No hay interfaz gráfica de usuario (GUI) 26
3.3.2. Dependencias sincrónicas y asincrónicas 26
3.3.3. Manejo de datos de prueba 27
3.3.4. Solicitud y respuesta 27
3.4. Explorando una API 27
3.5. Introducción a la herramienta SoapUI 28

4. Test de performance: conceptos y herramientas 28

4.1. Estructura de un script de prueba de performance 29
4.2. Implementación de un script de prueba de performance 30
4.3. Análisis de resultados 31
4.4. Reporte 33
4.5. Herramientas 33
4.5.1. Tipos de herramientas 33
4.5.2. Selección de las herramientas 34

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 7

Consignas para el aprendizaje colaborativo

En esta Unidad los participantes se encontrarán con diferentes tipos de actividades que,
en el marco de los fundamentos del MEC, los referenciarán a tres comunidades de
aprendizaje, que pondremos en funcionamiento en esta instancia de formación, a los
efectos de aprovecharlas pedagógicamente:

● Los foros proactivos asociados a cada una de las unidades.

● La Web 2.0.
● Los contextos de desempeño de los participantes.

Es importante que todos los participantes realicen algunas de las actividades sugeridas y
compartan en los foros los resultados obtenidos.

Además, también se propondrán reflexiones, notas especiales y vinculaciones a

bibliografía y sitios web.

El carácter constructivista y colaborativo del MEC nos exige que todas las actividades
realizadas por los participantes sean compartidas en los foros.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 8

Tomen nota
Las actividades son opcionales y pueden realizarse en forma individual, pero siempre es
deseable que se las realice en equipo, con la finalidad de estimular y favorecer el trabajo
colaborativo y el aprendizaje entre pares. Tenga en cuenta que, si bien las actividades son
opcionales, su realización es de vital importancia para el logro de los objetivos de
aprendizaje de esta instancia de formación. Si su tiempo no le permite realizar todas las
actividades, por lo menos realice alguna, es fundamental que lo haga. Si cada uno de los
participantes realiza alguna, el foro, que es una instancia clave en este tipo de cursos,
tendrá una actividad muy enriquecedora.

Asimismo, también tengan en cuenta cuando trabajen en la Web, que en ella hay de todo,
cosas excelentes, muy buenas, buenas, regulares, malas y muy malas. Por eso, es
necesario aplicar filtros críticos para que las investigaciones y búsquedas se encaminen a
la excelencia. Si tienen dudas con alguno de los datos recolectados, no dejen de consultar
al profesor-tutor. También aprovechen en el foro proactivo las opiniones de sus
compañeros de curso y colegas.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 9

1. Testing de seguridad
1.1. Introducción
El testing de seguridad difiere de otras formas de pruebas funcionales en 2 áreas
importantes:

● Las técnicas estándar para seleccionar datos de entrada pueden dejar pasar
importantes problemas de seguridad
● Los síntomas de defectos de seguridad son muy diferentes de los encontrados con
otros tipos de pruebas funcionales

Las pruebas de seguridad evalúan la vulnerabilidad de un sistema a las amenazas, al

intentar comprometer las políticas de seguridad.

1.2. Planificación del testing de seguridad

Debido a que los problemas de seguridad pueden ser introducidos durante la arquitectura,
diseño e implementación del sistema, se pueden planificar pruebas de seguridad para los
niveles de prueba de unidad, integración y sistema. Debido a la naturaleza cambiante de
las amenazas de seguridad, las pruebas de seguridad también pueden planificarse
regularmente después que el sistema esté en producción. Las estrategias de prueba
pueden incluir revisiones de código y análisis estáticos con herramientas de seguridad.
Esto puede ser efectivo para encontrar problemas de seguridad en la arquitectura, diseño
de documentos y código que pasan desapercibidos fácilmente durante las pruebas
dinámicas. Una parte esencial de la planificación de pruebas de seguridad es obtener las
aprobaciones (ver sección 1.4). Después de realizar mejoras de seguridad, es
aconsejable considerar la necesidad de realizar pruebas de performance (ver sección 4).

1.3. Especificación del testing de seguridad

Las vulnerabilidades específicas se pueden identificar mediante listas de verificación
como las que provee OWASP (2020). Los problemas de seguridad también se pueden
exponer mediante revisiones y/o el uso de herramientas de análisis estático (recuerde la
segunda unidad). Las herramientas de análisis estático contienen un extenso conjunto de
reglas específicas para las amenazas de seguridad y contra las cuáles se verifica el
código. Por ejemplo, la herramienta puede encontrar problemas de desbordamiento del

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 10

buffer, causados por la falta de verificación del tamaño del buffer antes de la asignación
de datos. Las herramientas de análisis estático se pueden usar para el código web y
verificar la posible exposición a vulnerabilidades como inyección de código, seguridad de
cookies, creación de scripts1 entre sitios (cross-site scripting o XSS), etc.

1.4. Aspectos formales y legales del testing de seguridad

Existen varias razones por las que el tester debe tener aprobación antes de ejecutar las
pruebas de seguridad:

● En casi todos los países del mundo, es ilegal intentar acceder a los sistemas de
datos y su información. En algunos países, incluso es ilegal tener acceso a
herramientas de pruebas de seguridad. Esto significa que en la mayoría de las
actividades de pruebas de seguridad se estará infringiendo una o más leyes. La
única posibilidad de realizar las pruebas es obtener una excepción del propietario y
la aprobación del gerente.
● Las pruebas de seguridad pueden desencadenar alertas de detección y el tester
puede parecer un intruso malicioso. La prueba de penetración es un caso
específico en que dicha autorización es necesaria.
● Las pruebas de seguridad pueden provocar fallas importantes al sistema y
“apagones”. El riesgo debe ser conocido y tomarse precauciones.
● Sin la autorización previa y específica para las pruebas de seguridad, el tester
puede estar infringiendo las políticas de seguridad. Esto podría hacer que el tester
sea despedido o enjuiciado.

1.5. Testing de los mecanismos de seguridad

1.5.1. Endurecimiento del sistema (system hardening)
Con los años, han surgido una variedad de mecanismos como prácticas clave en la
seguridad digital y activos físicos. Cada uno de estos mecanismos se puede aplicar de
varias maneras, algunos a través de herramientas e infraestructura y otros a través de
esfuerzos manuales. Ninguno de estos mecanismos por sí solos son suficientes en la
mayoría de los casos para asegurar la información. Cada mecanismo tiene sus propias
ventajas y desventajas.

1
Un script es un archivo de secuencia de comandos. Similar a un pequeño programa.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 11

Los testers de seguridad deben comprender los matices de cada línea de defensa para
que puedan diseñarse pruebas apropiadas para verificar y validar su efectividad. Los
testers de seguridad necesitan comprender las implicaciones de cada uno de los
mecanismos descritos en esta sección para diseñar una arquitectura de prueba que
brinde un marco para realizar pruebas de seguridad en forma contínua.

[Link]. Comprendiendo el endurecimiento del sistema

Los sistemas modernos se están volviendo cada vez más complejos, por lo que su
superficie de ataque crece continuamente. Las vulnerabilidades provienen de errores de
diseño (vulnerabilidades de diseño), defectos del código fuente (vulnerabilidades de
construcción) o falta de rigor en la configuración de estos sistemas (vulnerabilidades de
configuración).

El endurecimiento del sistema es el proceso paso a paso para reducir la superficie de

ataque mediante la aplicación de una política de seguridad y diferentes capas de
protección.

El objetivo principal es asegurar el sistema y reducir los riesgos de comprometer la

seguridad.

Dependiendo del contexto, el endurecimiento puede ser aplicado en diferentes niveles:

● Endurecimiento de un componente de software o hardware

● Endurecimiento de un producto/aplicación
● Endurecimiento de un sistema
● Endurecimiento de un sistema de sistemas

Las defensas de seguridad organizativas y técnicas que se aplicarán deben incluir:

● Eliminar software innecesario (puede contener defectos)
● Eliminar librerías y herramientas de desarrollo innecesarias (pueden contener
defectos)
● Eliminar cuentas/logins innecesarias (vectores de ataque)
● Eliminar aplicaciones innecesarias (pueden contener defectos) y servicios de red
(vectores de ataque)
● Eliminar periféricos y puertos de hardware innecesarios (por ejemplo, puertos USB,
lectores de tarjetas)
● Parchear rápidamente sistemas e instalar actualizaciones (por ejemplo, activar
actualizaciones automáticas)

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 12

● Actualización de configuraciones
● Seguir reglas de codificación (evitar vulnerabilidades de construcción)
● Configurar el servidor de registro (log) remoto (por ejemplo ryslog) para que en
caso de compromiso, el atacante solo pueda eliminar los archivos de registro de la
computadora atacada, pero no del servidor de registro remoto

Los siguientes mecanismos de seguridad deben ser utilizados

● Autenticación fuerte y gestión eficiente de la autorización (otorgue sólo los
derechos necesarios a roles dedicados)
● Cifrado (comunicación y almacenamiento alojado localmente)
● Firewalls (personal, sistema o aplicación web) y zonas de seguridad definidas (por
ejemplo, ejecución en una caja de arena (sand box)
● Sistema de detección de intrusos
● Anti-malware / anti-spyware
● Ofuscación de datos y aplicaciones (por ejemplo, protección contra ingeniería
inversa)

El endurecimiento del sistema es vital para proteger los archivos sensibles de una
organización pero las reglas de seguridad deben ser aplicadas en el nivel correcto y
equilibrado con la usabilidad del sistema. Si se exagera, las protecciones se terminan
deshabilitando porque bloquean la productividad de la empresa.

[Link]. Comprobando la efectividad de los mecanismos de endurecimiento

La comprobación de la efectividad de los mecanismos de endurecimiento del sistema se
puede lograr de formas variadas. La prueba dependerá de la naturaleza del sistema o de
la aplicación que debe ser endurecida, la sensibilidad de los activos protegidos y las
amenazas identificadas. El endurecimiento del sistema restringe el acceso del sistema a
roles correctos, abre solo los servicios necesarios y monitorea las actualizaciones de la
aplicación. Por lo tanto, para probar la efectividad del endurecimiento del sistema, las
pruebas deben ser diseñadas de modo que se sepa si los esfuerzos de endurecimiento
están funcionando, aplicados en los lugares correctos y aplicados de manera correcta.
También es importante evaluar protecciones de endurecimiento del sistema que son
demasiado restrictivas y pueden ser excesivas en vista de los riesgos de seguridad.

Algunas pruebas de endurecimiento pueden estar basadas en revisiones o auditorías,

mientras que otras pruebas pueden estar basadas en la capacidad de ciertos grupos de
usuarios para realizar ciertas acciones o acceder a ciertos datos.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 13

Las pruebas pueden incluir:

● La auditoría de la configuración de la base de datos y los servidores de

aplicaciones para verificar que los valores predeterminados fueron cambiados
● La auditoría de la configuración del sistema para identificar servicios y puertos de
red innecesarios
● La verificación de componentes, librerías y versiones de aplicaciones para verificar
que no son obsoletos o vulnerables

Se puede ejecutar un escáner de vulnerabilidades para facilitar las tareas de evaluación,

especialmente si el sistema es complejo. Las herramientas de análisis estático se pueden
usar para detectar violaciones de reglas de codificación que podrían introducir
vulnerabilidades de construcción. Los analizadores orientados a la seguridad pueden ser
particularmente útiles para detectar vulnerabilidades.

1.5.2. Autenticación y Autorización

[Link]. La relación entre la autenticación y la autorización

Los activos sensibles de una organización (por ejemplo, números de cuentas bancarias
de una lista de clientes, diseño de un nuevo producto) deben estar protegidos y deben ser
accesibles solo por la persona autorizada.

La autenticación se basa en la verificación de un identificador de usuario y un token para

responder las preguntas:

● Inicio de sesión/login: ¿Quién es el usuario?

● Contraseña: ¿El usuario realmente es quién pretende ser?

Se pueden utilizar diferentes implementaciones de mecanismos de autenticación

dependiendo de la necesidad de protegerse contra ataques para secuestrar la
autenticación o robar una contraseña. Estos incluyen la detección de debilidad de
contraseñas, empleo de contraseñas de un solo uso (One-Time Passwords, OTP), huellas
digitales, certificados de software, certificados en tokens duros y medios de autenticación
similares.

Dependiendo de la arquitectura del sistema, el contexto de aplicación y las necesidades

de organización (facilidad para administrar inicio de sesión / contraseña) los mecanismos

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 14

de autenticación pueden incluir autenticación local, servidor de autenticación,

autenticación de red, inicio de sesión único (Single Sign-On, SSO) y medios similares.
La autorización se utiliza para los siguientes propósitos:

● Verificar si el usuario autenticado tiene los derechos para realizar una acción (por
ejemplo, el usuario puede iniciar sesión en un servidor pero no puede modificar sus
datos, o un usuario está autorizado a usar un servidor FTP pero solo en su espacio
dedicado)
● Determinar qué nivel de acceso debe permitirse a los recursos del sistema

Existe un fuerte vínculo entre la autenticación y la autorización basado en el principio de

que un usuario no autenticado no tiene derechos o derechos restringidos sobre el sistema
(no está autorizado para manipular información delicada). Por ejemplo, en el contexto de
un sitio de ecommerce, un usuario no autorizado puede ver la lista de productos pero,
antes de comprar un artículo, debe crear una cuenta. El usuario autenticado puede
comprar un artículo, pero no puede realizar funciones administrativas.

[Link]. Comprobando la efectividad de los mecanismos de autenticación y

autorización
El objetivo de los atacantes es robar contraseñas o eludir sistemas para ejecutar acciones
no autorizadas. Por lo general, explotan diferentes tipos de debilidades: errores de código
(falta de filtrado de entrada), versiones viejas y vulnerables de librerías, errores de
configuración del sistema (mantener contraseñas predeterminadas, derechos
predeterminados) y contraseñas débiles (por ejemplo, la contraseña más utilizada es
“123456”).

Una organización puede tener un conjunto de reglas de contraseña que debe seguirse,
pero si el usuario no es diligente para mantener la contraseña segura, las reglas no harán
la diferencia. Adicionalmente, las reglas de contraseña deben reflejar las buenas prácticas
actuales en la definición de contraseñas. Estas prácticas se pueden encontrar en las
Pautas para Construcción de Contraseñas del Instituto SANS (SANS Institute, 2017).

Las pruebas para los mecanismos de autenticación y autorización podrían incluir:

● Fuerza bruta y ataques de diccionario para intentar descubrir las contraseñas de

los usuarios. Los primeros pasos pueden ser probar “123456”, “111111”, fecha de
nacimiento, nombre de la mascota, etc.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 15

● Explotar la falta de filtrado de entrada, por ejemplo, para inyectar solicitudes SQL
para autenticarse sin ningún nombre de usuario/contraseña conocido.
● Ingresar URI no autorizado (../../ en una cuenta FTP) o URL (dirección del
sitio/admin) para intentar obtener acceso a datos confidenciales.

Otro ejemplo podría ser explotar una vulnerabilidad en el sistema (tal vez porque no ha
sido actualizado) para causar un comportamiento no deseado y, por lo general, obtener el
control del sistema y permitir la escalada de privilegios.

1.5.3. Encriptación

[Link]. Entendiendo la encriptación

Para evitar la divulgación de datos confidenciales, incluso si se puede acceder a ellos
cuando se almacenan o intercambian entre cliente y servidor, se debería utilizar un
mecanismo de cifrado. Hashing y salting son los métodos usados durante la encriptación.

El cifrado (o encriptado) es un proceso de codificación de datos (por ejemplo texto) en

datos cifrados (texto cifrado), utilizando un algoritmo criptográfico y secretos, de tal
manera que solo las personas autorizadas tengan derecho a acceder mediante el uso de
un mecanismo de descifrado. El secreto es compartido y solo conocido por los usuarios
autorizados. El objetivo es tener un cifrado que sea lo suficientemente fuerte como para
evitar que un atacante, que puede haber tenido éxito en el robo de datos cifrados, pueda
recuperar el texto original. El uso de algoritmos criptográficos ayuda a garantizar la
confidencialidad, la integridad, la disponibilidad de los activos sensibles y el rechazo de su
manipulación.

Los protocolos criptográficos se pueden usar para proteger la información:

● Almacenada en un sistema, por ejemplo, contraseñas cifradas en una base de

datos, unidad lógica cifrada, todo el disco rígido cifrado
● Durante la comunicación, por ejemplo, correo electrónico cifrado, protocolo de
comunicación cifrado (SSL2, TLS3)

Los protocolos criptográficos principales y más reconocidos son:

2
SSL: Secure Sockets Layer (capa de sockets segura)
3
TLS:Transport Layer Security (seguridad de la capa de transporte, versión actualizada más segura de
SSL). A la fecha de escritura de este material se considera seguro desde TLS versión 1.2

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 16

● Cifrado simétrico: uso de clave secreta compartida

● Cifrado asimétrico: uso de clave privada y pública

[Link]. Comprobando la efectividad de los mecanismos de encriptación

Se sabe que algunos mecanismos criptográficos son débiles, especialmente debido al
pequeño tamaño de sus claves. Otros mecanismos son vulnerables porque no se
implementan con las mejores prácticas o incrustan defectos de codificación (como
desbordamiento de buffer).

Las pruebas para los mecanismos de cifrado deben incluir:

● Pruebas de vulnerabilidades de diseño:

○ Verificación de que el tamaño de las claves criptográficas no es demasiado
pequeño (por ejemplo, desde de 2015, una clave RSA4 de menos de 2048
bits se considera insegura)
○ Validación de la validez de los certificados y la capacidad de generar un
alerta si el certificado es autofirmado (usar SSL para evitar los ataques de
Man In The Middle)
○ Ataque de repetición (ej. ataque contra protocolos de privacidad equivalente
por cable (Wired Equivalent Privacy, WEP)
○ Ataques contra protocolos criptográficos para verificar su nivel de fuerza
(Bittau, 2014)
● Pruebas de vulnerabilidades de construcción:
○ Revisiones de código (por ejemplo, para verificar que la función
predeterminada random () no se usa para generar números aleatorios -seed-
porque el algoritmo random es relativamente fácil de descifrar)
○ Fuzzing para explotar comportamientos inesperados.
○ Ataques de tiempo (analizando el tiempo necesario para ejecutar algoritmos
criptográficos)
○ Análisis de potencia (utilizado para dispositivos de hardware encriptados)
● Pruebas de vulnerabilidades de configuración:
○ Evaluación de la configuración del protocolo criptográfico (por ejemplo,
configuración del lado del servidor de TLS, protocolos autorizados del lado
del cliente, según la guía de configuración de TLS para administradores)

4
RSA: Algoritmo criptográfico de Rivest, Shamir y Adleman

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 17

○ Orden de cifrado TLS en el lado del servidor, para ver si existe algún medio
para degradar o renegociar el cifrado que se está utilizando
● Pruebas de envejecimiento para verificar los mecanismos de cifrado que pueden
haberse debilitado y estar propensos a descifrado

1.5.4. Firewalls y Zona de redes

[Link]. Entendiendo Firewalls

Un firewall es un componente o un conjunto de componentes que restringe el acceso
entre una red protegida e Internet, o entre otros conjuntos de redes. Un firewall
implementa y aplica una política de seguridad basada en la definición de comunicaciones
autorizadas y prohibidas. Un firewall podría estar basado en el host / computadora
(software que se ejecuta en un solo host que monitorea las entradas / salidas de la
aplicación por ejemplo el firewall de Windows) o en la red (software que monitorea el
tráfico entre redes).

La tarea principal de un firewall es controlar el tráfico entre diferentes zonas de confianza

de red filtrando los datos que fluyen en dicha red. De esta manera, se detecta tráfico
malicioso proveniente de una zona no confiable y se bloquea.

Una zona de red es una subred identificada con un nivel de confianza definido:

● Internet / zona pública que se considera no confiable

● Varias zonas de seguridad llamadas zonas desmilitarizadas o DMZ, con diferentes
niveles de confianza.
● Una o más redes privadas / internas consideradas como las más confiables

Las zonas de red son parte de la configuración del firewall: se utilizan para definir los
flujos autorizados entre las diferentes redes. Todo el tráfico prohibido es bloqueado.

Por lo general, un firewall filtra la comunicación en función de:

● Direcciones y protocolos de origen y destino (direcciones Ethernet o IP, puertos

TCP / UDP, etc.)
● Opciones de protocolo (fragmentación, TTL, etc.)
● Tamaño de los datos

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 18

Los firewalls de aplicaciones web (WAF) también filtran la comunicación en función de:

● Los usuarios/las conexiones.

● Filtrado de datos (por ejemplo, usando descripciones de patrones)

[Link]. Comprobando la efectividad de los Firewalls

Debido a la cantidad de protocolos, sus diferentes opciones y la complejidad de las redes
a proteger, es difícil configurar un firewall de manera eficiente. Las pruebas de efectividad
del firewall deben incluir:

● Escaneo de puertos para verificar si la política de seguridad está bien

implementada
● Uso de paquetes de red mal formados y fuzzing de red para explotar un
comportamiento inesperado (por ejemplo, una denegación de servicio)
● Ataques de fragmentación para evitar las funciones de filtrado con el objetivo de
llevar a cabo el ataque detrás del firewall

Otro ejemplo de pruebas, dirigidas al WAF, es codificar y comprimir datos u ofuscarlos

para ocultar la información maliciosa que transmite el ataque.

1.5.5. Escaneo de malware

[Link]. Entendiendo las herramientas para el escaneo de malware

El código malicioso puede afectar a los servidores y a las computadoras de los usuarios
finales, proporcionando a sus inventores los privilegios esperados y datos confidenciales
específicos. El código malicioso se coloca en el destino utilizando diferentes medios,
como correo electrónico con archivos adjuntos maliciosos, URL falsas, ejecución de
código del lado del cliente, etc.

Una aplicación antimalware es un software utilizado para analizar, detectar y eliminar el

código malicioso recibido de diferentes fuentes, con diferentes objetivos de detección:
malware, phishing y pharming.

La principal característica de detección utilizada por el anti-malware es una estrategia

basada en firmas. El principio es buscar en una base de datos patrones conocidos de
datos que describen un código sospechoso. Sin embargo, el nuevo malware o malware
para el que la firma no está presente en la base de datos no se detectará y podría infectar

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 19

a su víctima. Para ayudar a combatir este problema, el anti-malware suele incluir un

mecanismo heurístico para identificar pequeñas variaciones de patrones maliciosos
conocidos.

[Link]. Comprobando la efectividad de las herramientas para el escaneo de

malware
Los desarrolladores de malware y puertas traseras utilizan diferentes técnicas para
proteger su código contra la ingeniería inversa y la detección mediante software
antimalware. Algunas de estas técnicas incluyen:

● Explotar funciones de librerías del sistema utilizadas por el malware (por ejemplo,
FindWindow que se puede utilizar para cerrar una aplicación antimalware)
● Ofuscación de cadenas para deshabilitar la comprensión del comportamiento del
código malicioso (por ejemplo, mediante el cifrado). Un ejemplo podría ser
almacenar un Javascript en un documento PDF. Otra es usar compresión como
Ultimate Packer para ejecutables (UPX).
● Carga dinámica de funciones y librerías (por ejemplo, para limitar el análisis del
código malicioso)
● Actualización automática de aplicaciones (por ejemplo, Skype Trojan)

El malware también puede usar otros recursos de hardware, como la unidad de

procesamiento de gráficos (GPU), para descomprimir el código malicioso y almacenarlo
en la memoria para que el procesador lo ejecute. En este caso, el malware no puede
analizarse antes de la ejecución.

Desde la perspectiva de la prueba funcional, podría usarse una herramienta como el

archivo de prueba antimalware (EICAR, 2020) para probar la efectividad del antimalware
sin desarrollar códigos maliciosos reales.

Una consideración importante al implementar una nueva aplicación antimalware o al

actualizar una aplicación antimalware existente es probar la implementación en una
plataforma representativa antes de implementarla en toda la organización. Ha habido
casos en los que el software antimalware identificó falsamente los archivos legítimos del
sistema operativo como malware y los puso en cuarentena, apagando así toda la
capacidad informática de la organización.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 20

1.5.6. Ofuscación de datos

[Link]. Entendiendo la ofuscación de datos

La ofuscación (a veces llamada enmascaramiento de datos) es un mecanismo para hacer
que los datos y el código fuente sean incomprensibles para un humano.

Esta técnica se utiliza principalmente para proteger datos confidenciales contra:

● Copia, para evitar los mecanismos de protección de la licencia.

● Ingeniería inversa, para comprender el código y aprovechar las vulnerabilidades.

La ofuscación de datos también se puede usar para permitir que los empleados de una
empresa (personal de soporte, testers funcionales, etc.) trabajen con datos no
confidenciales, mientras se ocultan los datos confidenciales. Algunos pueden referirse a la
ofuscación de datos como "anonimización de datos", ya que mantiene los datos
personales anónimos.

La ofuscación también se puede usar para proteger el código fuente contra copiar y pegar
(por ejemplo, para proteger un nuevo algoritmo innovador) y la reutilización futura
después de que se haya realizado una ingeniería inversa para comprenderlo.

A veces los desarrolladores necesitan optimizar su código para hacerlo más eficiente.
Esto puede generar un código fuente ofuscado (por ejemplo, al codificar algunas partes
en lenguaje ensamblador). Algunos ataques a nivel de aplicación web consisten en
inyección de scripts. Para tener éxito, los atacantes necesitan conocer la estructura del
sitio web y las páginas HTML. La ofuscación puede ayudar a proteger páginas HTML
sensibles y críticas (por ejemplo, páginas de conexión y administración).

Se pueden usar varias técnicas de ofuscación, como codificación base64, XORing,

cambio de nombres de funciones al azar, anulación (overriding) de métodos, eliminación
de espacios / saltos de línea / tabulaciones, mezclado, etc. El cifrado también es una
técnica de ofuscación pero con la salvedad de que los datos cifrados seguirán siendo
visibles para aquellos con claves válidas.

Nota: Los atacantes suelen utilizar la ofuscación de datos para ocultar su código malicioso
y sus ataques.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 21

[Link]. Comprobando la efectividad de los enfoques de ofuscación de datos

Se necesita un control de configuración estricto entre los datos ofuscados y las claves
utilizadas para la ofuscación para garantizar que se usen las versiones correctas de las
claves.

Dado que algunas pruebas podrían involucrar datos privados, la ofuscación de datos se
puede usar con fines de prueba para representar los datos de producción utilizados en un
entorno de prueba del sistema como anónimos. Los datos confidenciales, como la
información del usuario utilizada por un sistema de información de salud, no deben
divulgarse a los testers.

Las pruebas pueden incluir:

● Fuerza bruta o ataques de diccionario para intentar obtener datos simples de datos
ofuscados

Las pruebas para verificar la ofuscación del código podrían incluir:

● Ingeniería inversa del código de bytes (bytecode) Java (por ejemplo, regenerar el
código fuente de Java utilizando Java Decompiler) o programas .Net (por ejemplo,
recuperar el código fuente .Net con .NET Reflector)
● Ataques de fuerza bruta, porque algunos mecanismos de ofuscación son
vulnerables, por ejemplo, al usar un XOR (Chopitea, 2020).

En teoría, el código no puede protegerse contra la ofuscación, porque la depuración

siempre se puede usar. Si bien existen herramientas con el propósito de proteger el
código contra la descompilación, todavía existen riesgos y limitaciones en la protección de
la información patentada representada por el código.

1.5.7. Capacitación

[Link]. La importancia de la capacitación en seguridad

Los humanos son a menudo el eslabón más débil en el panorama general de
seguridad. Por lo tanto, se necesita capacitación constante y continua para recordar a las
personas la importancia de seguir las políticas de seguridad establecidas y para enfatizar
por qué son necesarias. Esta capacitación debe realizarse durante todo el proceso del
ciclo de vida del software y actualizarse a medida que se agregan nuevas políticas y

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 22

surgen nuevas amenazas. El entrenamiento debe cubrir la identificación de ataques de

ingeniería social y amenazas internas.

[Link]. Cómo comprobar la efectividad de la capacitación en seguridad

Por ejemplo, un programa de capacitación en seguridad podría abordar la importancia de
tener contraseñas de usuario seguras que se mantengan confidenciales.

Las pruebas pueden incluir:

● Ingeniería social para intentar que un usuario revele su contraseña durante una
conversación telefónica con una persona falsa de soporte técnico
● Buscar notas adhesivas en los escritorios con contraseñas (especialmente debajo
de los teclados)
● Ejecutar herramientas de auditoría de contraseñas para identificar contraseñas
débiles. Un riesgo de este tipo de herramienta es que las contraseñas pueden ser
visibles para la persona que ejecuta la prueba

Otro ejemplo sería que un desarrollador falle en validar una entrada para evitar el ingreso
de comandos SQL en un campo de entrada de datos. Debido a este error, un tester de
seguridad puede inyectar un comando SQL y ver el contenido de una base de datos de
clientes. Esto indicaría que el desarrollador necesita capacitación adicional en prácticas
de codificación segura. También sería bueno examinar las prácticas de codificación de
otros desarrolladores para ver si esta práctica es generalizada y se necesita una iniciativa
general de mejora de procesos.

Un tercer ejemplo sería cuando un tester intenta obtener acceso físico no autorizado a
una oficina y ver documentos que se han dejado al descubierto.

2. Introducción a OWASP
En relación con el testing de seguridad, el Open Web Application Security Project
(OWASP, 2020) es una fundación sin fines de lucro que trabaja para mejorar la seguridad
del software. A través de proyectos de software de código abierto liderados por la
comunidad, cientos de capítulos locales en todo el mundo, decenas de miles de miembros
y conferencias educativas, la Fundación OWASP es el recurso para que los
desarrolladores y tecnólogos hagan la web más segura.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 23

2.1. OWASP Top 10

El OWASP Top 10, es un documento estándar de concientización para los desarrolladores
y para la seguridad de aplicaciones web. Representa un amplio consenso sobre los
riesgos de seguridad más críticos para las aplicaciones web y es globalmente reconocido
por desarrolladores como el primer paso a una forma más segura de programar.
Las empresas deben adoptar este documento e iniciar el proceso que garantice que sus
aplicaciones web minimicen esos riesgos. Usar el OWASP Top 10, es quizás el primer
paso más efectivo para cambiar la cultura de desarrollo de software dentro de su
organización a una que produzca código más seguro.
Los 10 principales riesgos de seguridad de las aplicaciones web
1. Inyección: los defectos de inyección como la inyección de SQL, NoSQL, OS y
LDAP, ocurren cuando se envían datos no confiables a un intérprete como parte de
un comando o consulta. Los datos hostiles del atacante pueden engañar al
intérprete para que ejecute comandos no deseados o acceda a datos sin la
autorización adecuada.
2. Autenticación Rota: las funciones de la aplicación relacionadas con la
autenticación y la administración de sesiones a veces se implementan de manera
incorrecta, permitiendo a los atacantes poner en peligro contraseñas, claves o
tokens de sesión o explotar otros defectos de implementación para asumir las
identidades de otros usuarios de manera temporal o permanente.
3. Exposición de Datos Sensibles: muchas aplicaciones web y APIs no protegen
adecuadamente los datos confidenciales, como los financieros, médicos y la
información personal. Los atacantes pueden robar o modificar dichos datos
débilmente protegidos para hacer fraudes con tarjetas de crédito, robo de identidad
u otros delitos. Los datos confidenciales pueden estar en riesgo sin protección
adicional, como el cifrado en reposo o en tránsito y requieren precauciones
especiales cuando se intercambian con el navegador.
4. Entidades Externas XML (XXE): muchos procesadores XML antiguos o mal
configurados evalúan referencias de entidades externas dentro de documentos
XML. Las entidades externas se pueden usar para mostrar archivos internos
utilizando el manejador de URI de archivo ([Link] recursos compartidos de
archivos internos, escaneo de puertos internos, ejecución remota de código y
ataques de denegación de servicio (DoS). La solución más sencilla es el uso (si es
posible) de formatos más simples como JSON.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 24

5. Control de Acceso Roto: las restricciones sobre lo que los usuarios autenticados
pueden hacer a veces no se aplican de manera adecuada. Los atacantes pueden
explotar estos defectos para acceder a funcionalidad y / o datos no autorizados,
como acceso a las cuentas de otros usuarios, ver archivos sensibles /
confidenciales, modificar datos de otros usuarios, cambiar derechos de acceso, etc.
6. Mala configuración de Seguridad: la configuración incorrecta de seguridad es el
problema más común. Esto suele ser el resultado de configuraciones
predeterminadas inseguras, configuraciones incompletas o ad hoc,
almacenamiento abierto en la nube, encabezados HTTP mal configurados y
mensajes de error detallados que contienen información confidencial. No sólo todos
los sistemas operativos, frameworks, bibliotecas y aplicaciones deben estar
configurados de manera segura, sino que deben ser parcheados / actualizados de
manera oportuna.
7. Cross-Site Scripting XSS: los defectos de XSS ocurren cada vez que una
aplicación incluye datos no confiables en una nueva página web sin una validación
o escape adecuados, o actualiza una página web existente con datos
proporcionados por el usuario utilizando una API de navegador que puede crear
HTML o JavaScript. XSS permite a los atacantes ejecutar scripts en el navegador
de la víctima que pueden secuestrar sesiones de usuario, cambiar sitios web o
redirigir al usuario a sitios maliciosos.
8. Deserialización Insegura: la deserialización5 insegura muchas veces conduce a la
ejecución remota de código. Incluso si las fallas de deserialización no resultan en la
ejecución remota de código, pueden usarse para realizar ataques, incluidos
ataques de repetición, ataques de inyección y ataques de escalada de privilegios.
9. Uso de Componentes con Vulnerabilidades Conocidas: los componentes, como
bibliotecas, frameworks y otros módulos de software, se ejecutan con los mismos
privilegios que la aplicación. Si se explota un componente vulnerable, dicho ataque
puede facilitar la pérdida grave de datos o tomar el control del servidor. Las
aplicaciones y APIs que usan componentes con vulnerabilidades conocidas pueden
debilitar las defensas de las aplicaciones y permitir varios ataques e impactos.
10. Registro y Monitoreo Insuficientes : el registro y monitoreo insuficientes,
combinado con la integración faltante o ineficaz con la respuesta a incidentes,
permite a los atacantes atacar en más profundidad los sistemas, mantener la
persistencia, moverse a más sistemas y manipular, extraer o destruir datos. La
mayoría de los estudios de violaciones muestran que el tiempo para detectar una

5
Deserialización es la operación inversa a la serialización, que consiste en guardar el estado de un objeto
en una secuencia (stream) de bytes, para transmitirlo o almacenarlo en forma persistente.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 25

violación es mayor a los 200 días y generalmente es detectada por partes externas
en lugar de procesos internos o monitoreo.

3. Testing de webservices
Las APIs y los servicios web continúan disparándose en uso: conectando funciones o
datos de aplicaciones, integrando diferentes sistemas o encontrando nuevas formas de
monetizar a las empresas. Al final de esta sección, debería tener algunos conocimientos
nuevos en su haber: qué es una API, cómo ejecutar una prueba contra una, cómo crear
aserciones y más.

3.1. Fundamentos de las APIs

3.1.1. ¿Qué es una API?
Una API (Application Programming Interface) o Interfaz de Programación de Aplicaciones
es un software intermediario que permite que dos o más aplicaciones intercambien
funciones o datos, esencialmente permitiendo que el software se “comunique”.
Si bien muchas personas asocian APIs con servicios web, la definición es lo
suficientemente amplia como para incluir otros tipos de mensajes, incluyendo tecnologías
como: SOAP, REST, XML, JSON, MQTT, JMS, JDBC, etc.
Entonces se preguntará: ¿Qué es un servicio web? Es un servicio disponible en una red
que permite a otros sistemas comunicarse utilizando un protocolo estándar o definido. La
parte “web” denota que usará HTTP o HTTPS para comunicarse. Usaremos API y servicio
web indistintamente en esta sección pero queremos mencionar 2 estándares específicos
de servicios web: REST y SOAP.

3.1.2. API SOAP

Una API SOAP se define como un receptor de un documento XML y que también se
espera que responda con un documento XML. Todos los parámetros a los que el receptor
debe responder deben formar parte del documento XML que se envía. Las API SOAP han
perdido popularidad últimamente debido fundamentalmente a su complejidad.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 26

3.1.3. API REST

Una API REST o Representational State Transfer y su estilo de arquitectura se ha vuelto
más popular en aplicaciones web escalables. Un servicio web RESTful6 generalmente
pone mucho menos énfasis en el formato estricto, y típicamente usa datos formateados
en JSON (JavaScript Object Notation) en los cuerpos del mensaje en lugar de XML.
Aunque mucho en un servicio web RESTful se deja para que los diseñadores decidan.

3.2. Testing funcional de una API

El testing funcional involucra la verificación de que el comportamiento de un sistema
coincida con los requisitos de usabilidad y funcionalidad requeridos.
Una API funciona usando una serie de solicitudes y parámetros para invocar una
respuesta, usualmente datos de otro sistema o base de datos. El test funciona enviando
solicitudes y parámetros contra un sistema, y luego verificando si la respuesta recibida es
correcta.

3.3. Desafíos del testing de APIs

3.3.1. No hay interfaz gráfica de usuario (GUI)
Las APIs están destinadas principalmente a la comunicación de computadora a
computadora. Las computadoras no necesitan una interfaz de usuario. Este es un desafío
para el tester acostumbrado a hacer el testing a aplicaciones diseñadas para usuarios
finales, con una interfaz gráfica en la que pueden hacer click, arrastrar y manipular
visualmente una aplicación o datos.

3.3.2. Dependencias sincrónicas y asincrónicas

Las APIs a menudo se basan en otras APIs o sistemas back-end para funcionar
correctamente, a tiempo y de forma secuenciada. Si alguno de estos pasos o sistemas
está fuera de lugar, las aserciones7 fallarán. Estos sistemas o datos a menudo no están
disponibles para el testing debido a los costos, o porque no se construyeron totalmente u
otras razones.

6
Se denomina RESTful API o simplemente API REST a las API que siguen el estilo REST.
7
Aserción: afirmación o expectativa sobre el resultado esperado de una operación, en este caso como parte
de un caso de prueba.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 27

3.3.3. Manejo de datos de prueba

Las pruebas de API verifican la lógica de negocio de una capa de una aplicación, que a
menudo tiene millones de permutaciones y casos de uso. Puede ser complicado propagar
escenarios que prueben suficientemente los límites de una API.

3.3.4. Solicitud y respuesta

Como se mencionó anteriormente, las APIs funcionan por solicitud y respuesta. Las APIs
SOAP y REST tienen diferentes estándares para sus solicitudes y respuestas.
Las APIs basadas en SOAP usan XML como protocolo de comunicación. Deben
proporcionar un descriptor XML (como un WSDL) que en términos de máquina, defina
claramente todos los tipos de elementos de la solicitud que la API SOAP aceptará y todos
los tipos de elementos de respuesta que enviará de vuelta.
Esto significa, que como tester, se debe tener la habilidad para leer, comprender, crear y
actualizar documentos XML para poder testear una API SOAP.
Con servicios basados en REST, la solicitud puede ser mucho más simple, en su mayor
parte sólo involucra enviar un URL (o URI) al servicio. Esta solicitud tiene algunos
aspectos estándar. Primero, tiene una URL única, una carpeta de versiones, un método,
una consulta y uno o más parámetros. Las respuestas devueltas normalmente están en
formato JSON o XML. Estos una vez más, no están formateados para ser consumidos por
humanos, pero podemos hacerlo usando herramientas como SoapUI (2020).

3.4. Explorando una API

Un caso típico para usar una herramienta es “descubrir” o “explorar” una API
desconocida. A menudo, los servicios REST no tienen definiciones descriptivas que
expliquen sus comportamientos esperados. Los testers deben hurgar en los endpoints8 de
la API para explorar comportamientos correctos y crear aserciones. Los desarrolladores
también utilizarán este método cuando desarrollen una aplicación o servicio en torno a
una API desconocida o de terceros.
Las herramientas son útiles para explorar una API, permitiendo una configuración rápida
de consultas y parámetros de solicitud. SoapUI es una de las mejores herramientas en el

8
Se denomina endpoint (punto final) al lugar al que se envían solicitudes y donde reside el recurso. Por
ejempo [Link]

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 28

mercado cuando se trata de explorar y administrar los endpoints de las APIs. Ahí es
dónde la UI (por User Interface, interfaz de usuario) entra en juego.

3.5. Introducción a la herramienta SoapUI

Es la herramienta más popular para el testing de APIs en el mundo, SoapUI permite el
testing de las API REST y SOAP con más facilidad, porque ha sido creada especialmente
para el testing de APIs. Ofrece:
● Creación de pruebas rápida y fácil: la funcionalidad de apuntar y hacer click,
arrastrar y soltar, hace que las tareas complicadas sean simples (como trabajar con
JSON y XML)
● Potentes pruebas basadas en datos: carga de datos desde Excel, archivos y bases
de datos para simular la forma en que los consumidores interactúan con las APIs
● Reutilización de los scripts: reutilice sus casos de pruebas funcionales como
pruebas de carga y escaneos de seguridad con solo unos pocos clicks
● Integraciones transparentes: se integra con 13 plataformas de administración de
APIs, admite REST, SOAP, JMS e IoT
La versión comercial (SoapUI Pro, 2020) es usada por compañías como Apple, Microsoft,
Cisco, Oracle, HP, NASA, eBay, Mastercard, Intel, FedEx y Pfizer. Sin embargo, también
existe la versión open source (SoapUI, 2020) con la cual trabajaremos en este curso, la
cual es de uso ampliamente difundido y completamente gratuita.

4. Test de performance: conceptos y herramientas

Las pruebas de rendimiento o performance (López, 2020) evalúan la capacidad de un
componente o sistema para responder a las entradas del usuario o del sistema dentro de
un tiempo específico y bajo condiciones específicas. Las pruebas de performance se
realizan aplicando un perfil de carga (Bath, Black, Podelko, Pollne & Rice, 2018). Esto es,
una carga de trabajo distribuida en el tiempo. En la Figura 1 se muestra un ejemplo de
perfil de carga con el objetivo de probar el sistema bajo condiciones de stress.

Los siguientes conceptos son fundamentales a la hora de evaluar la performance

● Rendimiento (throughput) del sistema: es una medida del número de transacciones

que el sistema procesa en una unidad de tiempo.
● Concurrencia: es una medida del número de hilos simultáneos / paralelos de
ejecución.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 29

Figura 1 - Ejemplo de perfil de carga con stress

4.1. Estructura de un script de prueba de performance

Un script de prueba de rendimiento debe simular la actividad de un usuario o componente
que contribuya a la carga en el sistema bajo prueba (que puede ser el sistema completo o
uno de sus componentes). Inicia las solicitudes al servidor en un orden adecuado y a un
ritmo determinado. La manera de crear scripts de prueba de rendimiento depende del
enfoque de generación de carga utilizado:

● La forma tradicional es grabar la comunicación entre el cliente y el sistema o

componente a nivel de protocolo y luego reproducirlo después de que el script
haya sido parametrizado y documentado. La parametrización da como resultado un
script escalable y mantenible, pero la tarea de parametrización puede llevar mucho
tiempo.
● La grabación a nivel de GUI generalmente implica capturar acciones de GUI de
un solo cliente con una herramienta de ejecución de pruebas y luego ejecutar ese
script con la herramienta de generación de carga para representar a varios clientes.
● Usar programación para realizar solicitudes a nivel protocolo (por ejemplo,
solicitudes HTTP), acciones de GUI o llamadas a API. En este caso se debe
determinar la secuencia exacta de solicitudes enviadas y recibidas del sistema real,
lo que puede no ser trivial.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 30

Generalmente un script tiene una sección de inicialización (donde todo se prepara para la
parte principal), secciones principales que se pueden ejecutar varias veces y una sección
de limpieza (donde se ejecutan los pasos necesarios para finalizar la prueba
correctamente).

Para recopilar tiempos de respuesta, se deben agregar temporizadores al script para

medir el tiempo que demora una solicitud o una combinación de solicitudes. Las
solicitudes cronometradas deben coincidir con una unidad significativa de trabajo lógico,
por ejemplo, una transacción comercial para agregar un artículo a un pedido o enviar un
pedido.

Es importante comprender qué se mide exactamente: en el caso de los scripts de nivel de

protocolo, es solo el tiempo de respuesta del servidor y de la red, mientras que los scripts
de GUI miden el tiempo de extremo a extremo.

4.2. Implementación de un script de prueba de performance

Los scripts de prueba se implementan en base al plan de pruebas (Bath et al., 2018) y los
perfiles de carga. El script puede crearse mediante grabación o programación, según el
enfoque usado (sección 4.1). La grabación generalmente asegura que simula
exactamente el sistema real, mientras que la programación se basa en el conocimiento de
la secuencia de solicitudes adecuada.

Si se utiliza la grabación a nivel de protocolo, un paso esencial después de la grabación

en la mayoría de los casos es reemplazar todos los identificadores internos grabados que
definen el contexto. Estos identificadores se deben convertir en variables que se pueden
cambiar entre ejecuciones con valores apropiados que se extraen de las respuestas de la
solicitud (por ejemplo, un identificador de usuario que se adquiere al iniciar sesión y se
debe proporcionar para todas las transacciones posteriores).

Ejecutar múltiples usuarios virtuales con el mismo nombre de usuario y acceder al mismo
conjunto de datos (como suele suceder durante la reproducción de un script grabado sin
ninguna modificación adicional más allá de la mínima necesaria) es una manera fácil de
obtener resultados engañosos. Los datos podrían almacenarse en caché (copiarse del
disco a la memoria para un acceso más rápido) y los resultados serían mucho mejores
que en producción (donde dichos datos deben leerse desde un disco). El uso de los
mismos usuarios y / o datos también puede causar problemas de concurrencia (por
ejemplo, si los datos están bloqueados cuando un usuario los está actualizando) y los

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 31

resultados serían mucho peores que en producción, ya que el software tendría que
esperar a que el bloqueo se libere antes de que el próximo usuario pueda bloquear los
datos para su actualización.

Hay casos en los que algunos datos deben parametrizarse para que la prueba funcione
más de una vez, por ejemplo, cuando se crea un pedido y el nombre del pedido debe ser
único. A menos que el nombre del pedido esté parametrizado, la prueba fallará tan pronto
como intente crear un pedido con un nombre existente (el grabado).

Es importante asegurarse de que el entorno de prueba sea lo más cercano posible al

entorno de producción. Si esto no es posible, entonces debe haber una comprensión clara
de las diferencias y cómo se proyectarán los resultados de la prueba al entorno de
producción. El error de proyección y el nivel de riesgo aumentan a medida que el
ambiente de prueba se parece menos al de producción.

4.3. Análisis de resultados

Los datos que generalmente se analizan son:

● Estado de usuarios simulados. Esto debe ser examinado primero. Normalmente

se espera que todos los usuarios simulados hayan podido realizar las tareas
especificadas en el perfil operativo. Cualquier interrupción a esta actividad imitaría
lo que un usuario real puede experimentar. Esto hace que sea muy importante ver
primero que toda la actividad del usuario se completa ya que cualquier error
encontrado puede influir en los otros datos de rendimiento.
● Tiempo de respuesta de la transacción. Esto se puede medir de varias maneras,
incluyendo mínimo, máximo, promedio y un percentil (por ejemplo, 90%). Las
lecturas mínima y máxima muestran los extremos del rendimiento del sistema. El
rendimiento promedio no es necesariamente indicativo de otra cosa más que el
promedio matemático y, a menudo, puede ser sesgado por los valores atípicos. El
percentil 90 a menudo se usa como un objetivo, ya que representa a la mayoría de
los usuarios que alcanzan un umbral de rendimiento específico. No se recomienda
exigir un cumplimiento del 100% de los objetivos de rendimiento, ya que los
recursos necesarios pueden ser demasiado grandes y el efecto neto para los
usuarios generalmente será menor.
● Transacciones por segundo. Esto proporciona información sobre la cantidad de
trabajo realizado por el sistema (throughput del sistema).

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 32

● Transacciones fallidas. Estos datos se utilizan al analizar las transacciones por

segundo. Las fallas indican que el evento o proceso esperado no se completó o no
se ejecutó. Cualquier falla encontrada es motivo de preocupación y se debe
investigar la causa raíz. Las transacciones fallidas también pueden dar como
resultado un número inválido de transacciones por segundo, ya que una
transacción fallida tomará mucho menos tiempo que una completa.
● Hits (o solicitudes) por segundo. Esto proporciona una idea del número de
visitas a un servidor por parte de los usuarios simulados durante cada segundo de
la prueba.
● Throughput de red. Esto generalmente se mide en bits por segundo. Representa
la cantidad de datos que los usuarios simulados reciben del servidor cada segundo.
● Respuestas HTTP. Estas se miden por segundo e incluyen posibles códigos de
respuesta como: 200, 302, 304, 404, este último indica que no se encuentra una
página o recurso.

Aunque gran parte de esta información puede presentarse en tablas, las representaciones
gráficas facilitan ver los datos e identificar tendencias.

Las técnicas utilizadas en el análisis de datos pueden incluir:

● Comparación de resultados con los requisitos establecidos.

● Observación de tendencias en los resultados.
● Técnicas estadísticas de control de calidad.
● Identificación de errores
● Comparar los resultados con los de pruebas anteriores.
● Verificar el correcto funcionamiento de los componentes (por ejemplo, servidores,
redes)

Identificar la correlación entre las métricas puede ayudarnos a comprender en qué punto
el rendimiento del sistema comienza a degradarse. Por ejemplo, ¿qué número de
transacciones por segundo se procesaron cuando la CPU alcanzó el 90% de capacidad y
el sistema se ralentizó?

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 33

4.4. Reporte
Los resultados del análisis se consolidan y se comparan con los objetivos establecidos en
el plan de prueba de rendimiento (Bath et al., 2018). Suele incluir un resumen ejecutivo,
los resultados del test, registros de prueba / logs, recomendaciones.

Las recomendaciones resultantes de las pruebas pueden incluir lo siguiente:

● Cambios técnicos, como reconfigurar hardware, software o infraestructura de red

● Áreas identificadas para un análisis posterior (por ejemplo, análisis de logs del
servidor web para ayudar a identificar las causas raíz de problemas y / o errores)
● Monitoreo adicional de puertas de enlace, servidores y redes para que se puedan
obtener datos más detallados para medir las características y tendencias de
rendimiento (por ejemplo, degradación)

4.5. Herramientas
4.5.1. Tipos de herramientas
Las herramientas de prueba de rendimiento incluyen los siguientes tipos para ayudar a las
pruebas.

Generador de carga
El generador a través de un IDE, editor de scripts o conjunto de herramientas, puede
crear y ejecutar múltiples instancias de clientes que simulan el comportamiento del
usuario de acuerdo con un perfil operativo definido. La creación de varias instancias en
cortos períodos de tiempo provocará carga en el sistema bajo prueba. El generador crea
la carga y también recopila métricas para informes posteriores.

Al ejecutar pruebas de rendimiento, el objetivo del generador de carga es imitar el mundo

real tanto como sea práctico. Esto a menudo significa que se necesitan solicitudes de
usuarios que provengan de varias ubicaciones, no sólo de la ubicación de prueba. Los
entornos configurados con múltiples puntos de presencia se distribuirán desde donde se
origina la carga para que no todo provenga de una sola red. Esto proporciona realismo a
la prueba, aunque a veces puede sesgar los resultados si los saltos de red intermedios
crean demoras.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 34

Consola de administración de carga

La consola de administración de carga proporciona el control para iniciar y detener los
generadores de carga. La consola también agrega métricas de las diversas transacciones
que se definen dentro de las instancias de carga utilizadas por el generador. La consola
permite ver informes y gráficos de las ejecuciones de prueba y permite el análisis de
resultados.

Herramienta de monitoreo
Las herramientas de monitoreo se ejecutan simultáneamente con el componente o
sistema bajo prueba y supervisan, registran y/o analizan el comportamiento del
componente o sistema. Los componentes típicos que se supervisan incluyen las colas del
servidor web, la memoria del sistema y el espacio en disco. Las herramientas de
monitoreo pueden soportar efectivamente el análisis de la causa raíz de la degradación
del rendimiento en un sistema bajo prueba y también pueden usarse para monitorear un
entorno de producción cuando se lanza el producto. Durante la ejecución de la prueba de
rendimiento, los monitores también se pueden usar sobre el propio generador de carga.

Los modelos de licencia para las herramientas de prueba de rendimiento incluyen la

licencia tradicional por puesto de trabajo con propiedad total, un modelo de licencia de
pago por uso basado en la nube y licencias de código abierto que son de uso gratuito.
Cada modelo implica una estructura de costos diferente y puede incluir mantenimiento
continuo. Lo que está claro es que para cualquier herramienta seleccionada, comprender
cómo funciona esa herramienta (a través de capacitación y/o autoestudio) requerirá
tiempo y presupuesto.

4.5.2. Selección de las herramientas

Deben tenerse en cuenta los siguientes factores al seleccionar la herramienta de prueba:

Compatibilidad
En general, se selecciona una herramienta para la organización y no solo para un
proyecto. Esto significa considerar los siguientes factores en la organización:

● Protocolos: los protocolos de comunicación son un aspecto muy importante para la

selección de herramientas de rendimiento. Comprender qué protocolos utiliza un
sistema y cuáles de ellos se probarán proporcionará la información necesaria para
evaluar la herramienta de prueba adecuada.

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 35

● Interfaces con componentes externos: Es posible que las interfaces con

componentes de software u otras herramientas deban considerarse como parte de
los requisitos de integración completos para cumplir con el proceso u otros
requisitos de interoperabilidad (por ejemplo, integración en el proceso de CI9).
● Plataformas: La compatibilidad con las plataformas (y sus versiones) dentro de una
organización es esencial. Esto se aplica a las plataformas utilizadas para alojar las
herramientas y las plataformas con las que las herramientas interactúan para el
monitoreo y / o la generación de carga.

Escalabilidad
Otro factor a considerar es el número total de simulaciones de usuarios simultáneos que
la herramienta puede manejar. Esto incluirá varios factores:
● Número máximo de licencias requeridas.
● Requisitos de configuración de la estación de trabajo/servidor de generación de
carga.
● Capacidad para generar carga desde múltiples puntos de presencia (por ejemplo,
servidores distribuidos).

Comprensibilidad
Otro factor a considerar es el nivel de conocimiento técnico necesario para usar la
herramienta. Esto a menudo se pasa por alto y puede hacer que testers no calificados
configuren incorrectamente las pruebas, lo que a su vez proporciona resultados inexactos.
Para las pruebas que requieren escenarios complejos y un alto nivel de programabilidad y
personalización, los equipos deben asegurarse de que el tester tenga las habilidades, los
antecedentes y la capacitación necesarios.

Supervisión
¿Es suficiente el monitoreo proporcionado por la herramienta? ¿Existen otras
herramientas de monitoreo que puedan usarse como complemento? ¿Se puede
correlacionar el monitoreo con las transacciones? Estas preguntas deben ser respondidas
para determinar si la herramienta proporcionará el monitoreo requerido por el proyecto.

Cuando el monitoreo es un programa/herramienta/stack completo separado, se puede

usar para monitorear el entorno de producción cuando se lanza el producto.

9
CI: Continuous Integration (integración continua)

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning
 p. 36

Bibliografía utilizada y sugerida

Cursos
López, D. (2020). Professional Testing Master, UTN-FRBA. Curso Online.

Libros y otros manuscritos

Bath, G., Black, R., Podelko A., Pollner, A, Rice, R. (2018). Foundation Level Specialist
[Link] Testing. International Software Testing Qualifications
Board (ISTQB).

Sitios web
Bittau, A. (2014). Cryptographic protection of TCP Streams (tcpcrypt). Obtenido 4, 2020
de [Link]

Chopitea, T. unXOR. Obtenido 4, 2020 de [Link]

EICAR. European Institute for Computer Anti-Virus Research. Anti Malware Testfile.
Obtenido 4, 2020 de [Link]

OWASP. Open Web Application Security Project. Obtenido 4, 2020 de [Link]

SANS Institute (2017). Password Construction Guidelines. Obtenido 4, 2020 de

[Link]
tion-guidelines

SoapUI. Obtenido 4, 2020 de [Link]

SoapUI Pro. Obtenido 4, 2020 de [Link]

Centro de e-Learning SCEU UTN - BA.

Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148
[Link]/e-learning