¿Te imaginas la cantidad de información que se maneja en cualquier aeropuerto internacional? Participamos con una de las principales empresas industriales del país en el desarrollo de un producto que sirva como cuadro de mando integral de cualquier aeropuerto.
Abordamos el reto de agregar la ingente cantidad de información disponible desde diferentes sistemas heterogéneos y la elaboración de un cuadro de mando parametrizable que permita una gestión óptima de la operativa de cualquier aeropuerto.
¿Puede haber peor noticia que decirle al CEO de la compañía que han dejado inaccesible la página web y el correo corporativo?
Respondemos en menos de 24 horas a una importante empresa de inversión y gestión de activos: determinamos las causas del incidente de seguridad, realizamos análisis en un entorno sandbox para eliminar las trazas y efectos del ataque y por último limpiamos y securizamos el sitio web (WAF, 2FA, servicios tokenizados, cross-sripting, sql-injection)
Para el servidor de correo afectado se procedió a implementar las políticas de seguridad (DKIM , SPIF) para evitar la suplantación de identidad. Al igual que en la web, se implantó un sistema 2FA para mitigar los accesos indebidos.
Hasta hace relativamente poco tiempo disponer de asistencia médica en todo momento y lugar a través de nuestro dispositivo móvil no era una quimera, pero quizás sí, mucho más un deseo del sector de la tecnología para ponerse al servicio del paciente.
Sanitas, como aseguradora de referencia a nivel mundial en cuanto innovación en servicios y tecnología, fue la primera aseguradora de salud en España que lanzó en los primeros meses de 2018 una iniciativa para desarrollar su propia plataforma de video-consulta con el fin de ofrecer un producto digital (Blua) a todos los profesionales de la compañía y poder realizar consultas digitales con los pacientes aportando valor a todas las partes:
Los profesionales que atienden por videoconsulta son los mismos que atienden en los centros de Sanitas, tanto propios y concertados.
Ahorro de tiempo en desplazamientos.
Posibilidad de prescripción de una prueba médica o una receta directamente desde la videoconsulta.
Consulta de resultados de pruebas médicas tanto por el paciente como por el médico desde un mismo punto.
Elección del médico con el que se quiere conectar.
Orientación y atención profesional de los mejores asesores a través de programas personalizados de prevención y cuidado de la salud.
Retos
Hasta el planteamiento de esta innovación en el servicio, la relación médico-paciente siempre había necesitado de cercanía, considerándose la atención presencial imprescindible.
El objetivo era conseguir un producto digital con una experiencia de usuario memorable, que no solo enfrentase de forma satisfactoria el momento de la videollamada, sino que para profesional y paciente se cubriese todo el proceso de atención digitalmente desde un mismo punto con las peculiaridades de cada perspectiva: solicitud y gestión de citas, sala de espera, acceso a historial clínico, revisión y compartición de informes, etc.
La solución
La plataforma de videoconsulta de Sanitas consiste en un portal web multiplataforma y multiproveedor, integrado con los principales portales donde trabajan los profesionales de la compañía y desde donde acceden para poder realizar sus consultas digitales, bien sea a través de video, chat o teléfono.
ITERIAM colabora con Sanitas en el diseño técnico, desarrollo y puesta en producción de la plataforma aportando diferentes squads agile con perfiles como: jefes de proyecto técnico, líderes técnicos, desarrolladores front-end, desarolladores back-end, desarrolladores app, testers. Dichos squads se van adecuando a la demanda necesaria.
La plataforma de videoconsulta se ha desarrollado según los requisitos tecnológicos corporativos sobre una arquitectura de microservicios escalable con diferentes módulos:
Modulo principal de la plataforma con acceso a los servicios de la plataforma mediante tecnología webRTC con diferentes proveedores de videoconsulta para alta disponibilidad de servicios.
Buses de comunicaciones.
Reglas de negocio para la utilización de los múltiples proveedores de videoconsulta.
API de grabaciones para la gestión de los servicios del portal de grabaciones.
Módulo de estadísticas.
Tres frontales específicos para profesionales, pacientes y la consulta de grabaciones.
Así mismo, se ofrece un plugin para la integración con app.
Adicionalmente, y con el comienzo de la pandemia del COVID-19, Sanitas decidió poner a disposición de todos sus asegurados el servicio que inicialmente se había concebido como servicio premium para un grupo de clientes. Se tuvieron que replantear algunas partes de la arquitectura con el fin de asumir el volumen de peticiones de servicio que se esperaban.
Dichas circunstancias permitieron a la videoconsulta acelerar su proceso de implantación e incrementar su uso de una forma vertiginosa. A finales de 2020 se habían multiplicado por 15 los accesos a este servicio llegando a realizarse 640.000 videoconsultas.
Resultados
Los clientes de Sanitas disponen tanto del portal web como de la app, ambos integrados con el proyecto MiSanitas, donde accederán a la plataforma para realizar su consulta digital.
Actualmente hay dos tipos de videoconsulta:
Con profesionales médicos: acceso al servicio de videoconsulta, conectando con médicos de la mayoría de especialidades de una manera cómoda y sencilla, sin necesidad de desplazamientos.
Urgencias: también podrás realizar tus consultas generales o de atención pediátrica sin cita previa.
ITERIAM sigue colaborando con Sanitas en este ámbito mediante un servicio de mantenimiento evolutivo y correctivo de la plataforma.
Cuando hablamos de un altavoz inteligente o asistente de voz, estamos haciendo referencia a un altavoz conectado a Internet a un servicio de voz basado en nube que recibe comandos a través de una interfaz de voz y, por lo tanto, permite hacer uso de servicios en línea basados en audio y permiten controlar dispositivos conectados a través de Wifi o Bluetooth.
El servicio de voz de Amazon (Alexa) ofrece ya de serie varias funciones básicas tales como la reproducción de música, escuchar noticias, recibir informes de tráfico, predicciones meteorológicas, etc. Además, pueden instalarse otras funciones extra, las llamadas Skills o funcionalidades de Alexa, disponibles en la Alexa Skills Store, la cual actúa como un marketplace de aplicaciones o funcionalidades extras para los usuarios.
¿Qué es una Skill de Alexa?
Las Skills de Alexa son programas que pueden instalarse en todo dispositivo inteligente que haga uso del servicio de voz de Alexa y que sirven para ampliar la gama de funciones básicas que este servicio ofrece. Más a bajo nivel, la arquitectura de una Skill de Alexa sigue un modelo cliente-servidor, donde cualquier dispositivo que soporte el servicio lingüístico de Alexa, (ya sea un altavoz inteligente Amazon Echo o un horno debidamente equipado), actúa como el cliente o frontend de la Skill, y donde el backend se ejecuta en su propio servidor o en AWS Lambda, un servicio de procesamiento de datos desarrollado por Amazon basado en arquitectura serverless ofrecido por AWS (Amazon Web Services).
Puedes desarrollar tus propias Skills de Alexa haciendo uso del Alexa Skills Kit y el AWS Lambda.
Alexa Skills Kit: Requisitos para el desarrollo
Las Skills de Alexa se desarrollan utilizando el Alexa Skills Kit (ASK), disponible gratuitamente una vez hayas creado tu cuenta de desarrolladores de Amazon.
El Alexa Skills Kit (ASK) es una colección de APIs, herramientas, documentación y ejemplos de código que te permite crear tus Skills de Alexa.
Por otro lado, si no deseas encargarte de alojar tú mismo la lógica del programa de tu Skill de Alexa en tu propio servidor, necesitarás una cuenta AWS que te proporcione acceso al servicio en la nube de AWS Lambda.
Después de estos conceptos pasa a segunda parte del artículo para realizar los 6 pasos que nos permitirán tener disponible nuestra Skill:
Paso 1. Creación de la Skill en la consola de desarrollo de Amazon
Paso 2. Definiendo el modelo de interacción de tu Skill
Paso 3. Creación de la función Lambda de AWS
Paso 4. Conectar la función Lambda de AWS a la Skill
Mejorando TDD con la premisa de la prioridad de transformación
¿Qué es la Premisa de la Prioridad de Transformación?
La mayoría de los programadores que han utilizado la práctica de desarrollo de software TDD (Rojo/Verde/Refactorización) en su ciclo de trabajo, deben estar ya acostumbrados a introducir pequeños cambios en el código en cada una de sus fases, y principalmente deben conocer los cambios asociados a las refactorizaciones que realizamos durante la última fase de TDD.
La refactorización, tal como fue definida por Martin Fowler en su libro Refactoring: Improving the Design of Existing Code (1999), “es el proceso de cambiar un sistema de software, de forma tal que no se altere el comportamiento externo del mismo pero que se mejore su estructura interna. Con el objetivo de hacerlo más sencillo de entender y barato de mantener, permitiendo que el diseño del programa mejore luego de haber sido escrito”.
Al igual que con la fase de Refactorización, durante la fase Verde también se realizan alteraciones en el código, mediante las cuales intentamos hacer que el software supere la prueba que se encuentra fallando, empleando el menor cambio posible. A estas operaciones Robert C. Martin (tío Bob) las denominó transformaciones.
Podemos pensar en estas transformaciones como la contraparte de las refactorizaciones, debido a que consisten en pequeñas variaciones en el código que permiten modificar el comportamiento externo del software pero que conservan significativamente su estructura interna. Dicho en otras palabras, las transformaciones generalizan el comportamiento del sistema sin cambiar su estructura.
Pensando en estas transformaciones, el tío Bob definió la “Premisa de Prioridad de Transformación” (sus siglas TPP del inglés Transformation Priority Premise) la cual afirma que las transformaciones poseen un orden inherente fundamental, y que al ser aplicadas en correcto orden se conduce a mejores algoritmos y se evitan interrupciones del ciclo de TDD.
Él describe esta premisa en algunas de sus charlas mediante un ejemplo de desarrollo de un algoritmo de ordenamiento, y hace notar que al violar dicho orden se conduce a un algoritmo de ordenamiento de burbuja, mientras que empleando un orden preestablecido se alcanza un algoritmo de ordenamiento rápido, el cual es mucho más eficiente que el anterior.
Basándose en sus experiencias y evaluando publicaciones de otras personas, el tío Bob llegó a la siguiente lista ordenada de transformaciones:
01
{}–>null
De no tener código alguno a código que retorna Null
02
null->constant
De código que retorna Null a devolver un valor literal simple
03
constant->constant+
De un valor literal simple a un valor literal complejo
04
constant->scalar
De un valor literal a una variable
05
statement->statements
Agregar más sentencias
06
unconditional->if
Dividir el flujo de ejecución mediante condicionales
07
scalar->array
De una variable a una colección
08
array->container
De una colección a un contenedor
09
statement->tail-recursion
De una sentencia a recursión de cola
10
if->while
De un condicional a un bucle while
11
statement->non-tail-recursion
De una sentencia a una iteración
12
expression->function
De una expresión a una función
13
variable->assignment
Reemplazar el valor de una variable
14
case/else
Añadir una bifurcación a un condicional existente
Tabla 1. Orden de Transformaciones según su Prioridad
Este listado sugiere un grado de complejidad incremental en nuestras transformaciones a medida que avanzamos en él, de forma que es más sencillo cambiar una constante a una variable que el añadir una sentencia condicional. Debido a esto, se sustenta la idea de dar prioridad en su uso a las transformaciones más simples por encima de aquellas más complejas.
Como una guía para nuestro uso durante el ciclo de TDD se puede representar dicho listado con el siguiente diagrama:
Figura 2. Diagrama de la Premisa de Prioridad de las Transformaciones
Para propiciar el uso de las transformaciones más simples, cuando diseñamos una prueba, primero debemos pensar en desarrollar aquellos casos de uso que nos permitan emplear transformaciones más simples en vez de las transformaciones más complejas. Debido a que a mayor complejidad de la prueba, mayor será el riesgo que tomemos para lograr hacer que nuestra prueba pase.
Encontrarnos en una situación donde no sabemos cómo hacer que una prueba pase, es un problema que muchos hemos observado mientras realizamos TDD. Algunas veces, la causa de este tipo de impasses recae en nuestro proceso de toma de decisiones durante el ciclo de desarrollo de TDD.
La transformación más simple suele ser la mejor opción que incurrirá en el menor riesgo para crear una situación de bloqueo. Debido a que mientras mayor sea el cambio en el código, más tiempo nos tomará antes de que nuestra prueba vuelva a pasar, por lo que se produce un riesgo mayor de romper el ciclo de TDD.
Por todo lo antes expuesto, el tío Bob plantea como premisa que si se eligen las pruebas e implementaciones que empleen transformaciones que están más arriba en la lista, se podrán evitar las situaciones de impasse o interrupciones prolongadas en el ciclo rojo / verde / refactorización.
Aplicando la TPP al Kata de los Números Primos
Aplicando la TPP al Kata de los Números Primos
Podemos practicar y dominar estos conceptos aplicando esta premisa de la prioridad de las transformaciones en un problema conocido como lo es la kata de los números primos.
El objetivo de esta kata es determinar el listado de factores primos un número. Un número primo sólo puede ser dividido exactamente por sí mismo y por 1.
A continuación, realizaremos la kata de los factores primos:
1. Añadimos un Test Fallido para 1 (Caso más simple)
Nos detenemos al fallar la compilación de la prueba
1.1 Transformando para Compilar
La forma más fácil de tener éxito (compilar ahora) es crear un método con valor de retorno nulo. Esta es la primera transformación o transformación nula ({} -> null).
1.1 Transformando para Pasar el Test
Esta prueba falla porque el método primeFactorsOf devuelve null, y no una lista vacía. Para que esta prueba sea exitosa, transformaremos el valor nulo en una lista vacía.
Nuestra segunda transformación es null -> constant.
¿Acaso null no es una constante? Null también es una constante, pero Null es una constante muy especial. Es una constante sin tipo definido y sin valor. Por lo tanto, es diferente de una constante que tiene un tipo y un valor.
La transformación realizada con null -> constant hace que el código sea más general. Null es un caso muy especial, inmutable, pero una lista vacía tiene el potencial de ser general. Ser general significa que puede manejar una variedad más amplia de casos.
Para que esta prueba sea exitosa, generalizamos la constante new ArrayList()
Para hacer esto, transformamos la constante en una variable llamada factors. La tercera transformación es constant -> variable.
Lo que hemos hecho es una refactorización (extracción de una variable), con la cual no hemos cambiado el comportamiento en un sentido estricto. Debido a que reemplazar una constante por una variable con su valor original no altera el comportamiento del sistema. Sin embargo, nos abre la posibilidad de poder cambiar ese comportamiento. En otras palabras, cambiar una constante por una variable no es una transformación independiente, pero es una parte necesaria del proceso de transformación.
2.2 Transformación – Flujo Dividido
Una transformación que modifica una constante en una variable permite que realicemos una cuarta transformación llamada división de flujo. En la transformación de flujo dividido, una sentencia if es empleada para dividir el flujo de control del programa. Esta transformación fue habilitada por la transformación anterior. La sentencia if hizo de nuestro código algo más específico. Por lo que nos toca ahora generalizarlo.
2.2 Refactorización – Generalizando
La condición if(number == 2) fue un caso muy específico (coincidiendo con la intención de la prueba). Debemos refactorizar para manejar casos más generales.
if(number > 1) es más general debido a que está abierto a posibilidades.
3. Añadimos un Test Fallido para 3
Al incluir la tercera prueba assertThat(primeFactorsOf(3), isListOf(3)); dicha prueba fallará.
3.1 Transformación – Constante a Variable
Para lograr hacer pasar la prueba con la transformación más simple, aplicamos la transformación constant -> variable en la cual modificaremos el 2 que añadimos a la lista de factores por la variable de entrada number.
4. Añadimos un Test Fallido para 4
Para la cuarta prueba incluimos la siguiente sentencia:
De forma que logremos pasar esta prueba, debemos volver a hacer una división en el flujo, dependiendo si la entrada number es divisible por 2.
4.2 Transformación – Flujo Dividido Nuevamente
Aún con este cambio, otra de nuestras pruebas continúa fallando. Esto se debe a que el caso de los factores primos de 4 es exitoso, pero el caso de los factores primos de 2 debe incluir a un solo valor y no dos. Por lo que tendremos que dividir el flujo nuevamente para evitarlo.
Y con esto podremos pasar todas las pruebas.
4.3 Refactorización
En el caso de number > 1, la división es realizada dos veces. No debemos preocuparnos de ello en este momento debido a que pronto desaparecerá. No generamos ningún inconveniente si movemos la parte del segundo condicional number > 1 fuera de la primera cláusula condicional.
4.4 Refactorización
Al igual que con el código productivo, el código que compone nuestras pruebas también debe ser mantenido. Por lo que podemos refactorizar para mejorar su legibilidad al eliminar duplicación en el código.
5. Añadimos más pruebas
En los casos de 5, 6 y 7, estas pruebas funcionan correctamente si son incluidas debido a que su comportamiento se encuentra incluido en nuestro algoritmo.
6. Añadimos prueba fallida para el 8
assertThat(primeFactorsOf(8), isListOf(2, 2, 2));
La cual falla.
6.1 Transformación – If a While
Podemos aplicar la transformación If -> while de forma que pasemos la nueva prueba.
El bucle while es simplemente una forma generalizada del condicional if, por lo que if es una forma especial de la estructura while.
6.2 Refactorización
Se mejora la legibilidad del código al refactorizar el bucle while a un bucle for como se muestra a continuación.
7. Añadimos un Test Fallido para 9
Añadimos la prueba assertThat(primeFactorsOf(9), isListOf(3, 3));
7.1 Hacemos pasar con Duplicación
Añadimos la condición de división por 3 como se muestra a continuación para hacer que nuestra prueba pase.
7.2 Transformación para remover la duplicidad – Bucle más general
Hemos introducido una duplicidad en nuestro código. Podemos incurrir en estas mientras estemos trabajando en un ciclo de TDD, pero las mismas no deben registrarse en el repositorio de origen como código repetido. Esta redundancia no es una transformación, debido a que nada ha sido generalizado. Simplemente es un experimento que nos permite imaginar como debe ser la solución general.
Nuestra tarea ahora es aplicar un ciclo más generalizado para eliminar la duplicación. El código duplicado siempre es inusual y específico.
7.3 Refactorización
Mejoramos nuevamente la legibilidad al refactorizar el bucle while por un bucle for y eliminamos el condicional restante, para obtener el resultado final compuesto por dos bucles for fáciles de entender.
Conclusión
Las siguientes transformaciones fueron observadas en este ejercicio de ejemplo:
{} -> null (1)
null -> constant (2)
constant -> variable (4)
split flow (6)
if -> while (10)
Pudimos ver mediante la kata de ejemplo una ilustración del proceso descrito por el tío Bob, y ver que al aplicar las transformaciones que propone TPP conseguimos garantizar:
Menor tiempo en rojo (evitar el impasse)
Descubrimiento de los puntos principales del problema
Desarrollo de una solución genérica y con menos duplicación
La Premisa de la Prioridad de Transformación (TPP) es una de las herramientas con las que contamos para garantizar el cumplimiento de las reglas del desarrollo guiado por tests. Este listado de transformaciones no implica reglas inalterables, sino una guía para evitar los bloqueos en el ciclo de TDD, especialmente al hacer el cambio de rojo a verde.
Si te interesa conocer más sobre TPP puedes buscar el siguiente material:
En los proyectos ágiles, a la vez que se acortan los ciclos de desarrollo se vuelven todavía más importantes las pruebas de nuestro API (Application Programming Interface) y se convierte en obligatoria la ejecución de pruebas automáticas.
En API testing utilizamos herramientas de software para enviar llamadas a la API, obtener resultados y registrar la respuesta del sistema. Existen muchos artículos para conocer las principales recomendaciones para este tipo de testing así como diferentes herramientas, tanto libres como de pago: Postman, Insomnia, Ping ApI, HP QTP, vREST, JMeter…
Este tipo de herramientas son de gran utilidad para poder interactuar con APIs y, como desarrolladora front-end que soy, poder hacer pruebas de los servicios que se tienen que implementar.
Probablemente las más usada o conocida sea Postman, pero en este artículo me gustaría hablaros un poco de REST Client que nos permite realizar llamadas HTTP desde el propio editor Visual Studio Code (VS Code) de una forma muy sencilla.
Algunas de las características y ventajas que se pueden destacar de REST Client son:
Ejecutar solicitudes HTTP y ver la respuesta directamente en el panel
Tener todas las solicitudes en un mismo fichero
Soporta los tipos de autenticación más comunes
Definición de variables de entorno
Generar code snippets
Voy a ir explicando paso a paso como empezar a utilizar esta herramienta.
Instalación
La instalación es muy sencilla puesto podemos acceder a la extensión desde el mismo VS Code:
Fichero
Una vez instalado REST Client, crearemos un fichero cuya extensión debe ser .http o .rest para que nuestro código sea compatible con las solicitudes HTTP que vayamos a realizar.
Entornos y variables
Hay diferentes formas de definir variables. Aquí vamos a explicar dos de ellas:
1. Variables de entornos Se pueden definir variables de entorno en el propio settings de VS Code. En la siguiente imagen se muestra un ejemplo de cómo se configuraría un entorno para local y otro para producción.
Una vez configurado el fichero de settings, tenemos que seleccionar el entorno con el que queremos trabajar. Para ello abrimos nuestro fichero .rest, pulsamos F1, elegimos la opción: Rest Client: Switch Environment y seleccionamos el entorno.
2. Variables en el mismo fichero Se pueden definir variables en el mismo fichero con la siguiente sintaxis:
@nombreVariable = valor
En la siguiente imagen se muestra un ejemplo con algunas variables y una llamada a un servicio GET haciendo uso de ellas.
Peticiones
REST Client nos permite realizar peticiones GET, POST, PUT y DELETE de una forma muy sencilla.
En la siguiente imagen vemos algunos ejemplos de peticiones, variables y de como se muestra el resultado de una petición.
Empezamos definiendo algunas variables como el host o el puerto la base de nuestro proyecto para poder reutilizarlas en todo nuestro código.
Seguimos escribiendo nuestras peticiones separadas entre ellas con un comentario que debe empezar por tres o más almohadillas (###) . Esto es importante ya que, sin ello, no podremos realizar las siguientes peticiones.
Después de cada una de estas líneas, tendremos el encabezado de nuestra solicitud, el cual podremos llamar situándonos encima de la petición y pulsando sobre Send Request
El resultado se mostrará en un panel que se abrirá a la derecha automáticamente.
Autorización
Además, como ya apuntaba al principio, Rest Client soporta los tipos de autenticación más comunes como: Basic Auth, Digest Auth, SSL Client Certificates. etc.
Aquí te muestro un ejemplo de cómo se añadiría una cabecera de «Authorization»:
Code Snippet
Una vez tengamos nuestras peticiones, podemos generar estas peticiones en el lenguaje que queramos.
Para poder generar este código nos situamos sobre la petición y con el botón derecho del ratón nos aparecerá un menú. Seleccionamos: «Generate Code Snippet»
Una vez seleccionado nos muestra un listado con los diferentes lenguajes y seleccionamos uno de ellos:
En mi caso selecciono JavaScript y automáticamente se abre un panel a la derecha con el código generado.
Esto nos puede ahorrar tiempo y ayudar bastante a la hora de realizar las llamadas a estas peticiones desde nuestra aplicación.
Como podemos ver, REST Cient nos permite realizar peticiones de una forma muy sencilla. Una de las cosas que más me gusta es que podemos tener todas nuestras peticiones de nuestro proyecto en el mismo directorio y hacer pruebas sin necesidad de abrir otros programas.
Actualmente, tanto los clientes como los desarrolladores de software estamos muy preocupados por la calidad del código, pero parece que se sigue pesando más el cumplimiento de las fechas de entrega y el ajuste en el presupuesto.
Tan evidente es que en el documento de cumplimiento del servicio (ANS) que se firma en muchas colaboraciones se recogen todo tipo de variables, KPIs y sus correspondientes penalizaciones en el caso de incumplimiento, pero pocas veces se miden o se cuantifican criterios de seguridad.
En el mundo Agile en el que se definen las historias de usuario, se establecen los sprints y se hacen las fases más difusas y menos largas, en ningún momento se tiene en consideración la securización de las aplicaciones de forma explícita. Se diseña, construye, prueba y se entrega, pero ¿y la seguridad?, ¿en qué fase entra? ¿se considera incluida en la parte de construcción? ¿no debería ser una parte de cada una de las fases?
El diseño de aplicaciones debería abordarse siempre bajo criterios de seguridad, siguiendo unos estándares de construcción seguros y finalmente se debería probar la seguridad de cada una de las funcionalidades desarrolladas en el sprint correspondiente.
En este punto debemos reflexionar si en nuestro caso tenemos en cuenta la seguridad: ¿existe un checklist al respecto que validamos antes de entregar y/o recepcionar los desarrollos o mientras que cumplan con las funcionalidades definidas y se entregue en los plazos establecidos entendemos que es un buen trabajo?
No se necesita ser un experto ni tener un equipo de hacking ético para definir una línea base y poder testar la seguridad de nuestros desarrollos. Mi recomendación para definir correctamente esos mínimos debemos tomar como referencia OWASP – Open Web Application Security Project.
OWASP es una fundación sin ánimo de lucro cuyos miembros trabajan a favor de la seguridad del software en general. Cada año analizan los 10 principales riesgos que se producen en las aplicaciones.
El informe de 2020 nos recomienda tener en cuenta los siguientes aspectos:
Consiste en la ejecución de comandos o querys directamente desde la propia aplicación. Supongamos que tenemos el típico método de acceso a una aplicación con los campos usuario y contraseña ¿Qué ocurriría si la consulta a la base de datos no tuviese mecanismos de validación o estuviese mal construida y permitiese meter en el campo usuario el siguiente texto?
' or "=';
La consulta siempre saldría positiva y accederíamos a la base de datos.
Englobaría a todo lo referido en el tratamiento y técnicas de protección de credenciales y cómo las implementan las aplicaciones. Es decir, la utilización de canales no cifrados para transmitir credenciales (https), no proteger debidamente las credenciales de usuarios, mala gestión en la recuperación de credenciales, exposición de los ID de sesión (Cookies de sesión). Un ejemplo de esto podría ser
Se produce cuando un usuario puede comprometer los datos debido a una mala u obsoleta encriptación de los mismos. Tiene puntos de conexión con el reglamento general de protección de datos (RDPD). Un ejemplo claro puede ser guardar en un archivo de configuración el usuario y contraseña en “texto plano”.
Antiguos procesadores de XML permiten la especificación de una entidad externa, una URI sin referencia y evaluada durante el procesamiento del XML. Es decir, que al parseador de XML se le envía un XML con funcionalidades añadidas. Ejemplo de esto podría ser:
El control de acceso determina qué usuarios se comunican con qué sistemas y recursos. Esto implica que los usuarios no pueden actuar fuera de los permisos previstos.
Un ejemplo de esto es la configuración incorrecta de CORS que permite el acceso no autorizado a una API, o acceder a una API sin control de acceso mediante el uso de POST, PUT o DELETE.
En este apartado se incluiría todo aquello que se relaciona con el despliegue de una aplicación y su entorno. Es decir, permisos, configuraciones por defecto, actualizaciones librerías, sistema operativo, servidores de aplicaciones, puertos, servicios, cuentas de usuarios, manejo de errores, etc.
Este ítem considera la posibilidad de modificar valores que la aplicación web usa para pasar variables entre dos páginas.Los ataques XSS se basan en la inyección de scripts maliciosos que se ejecutan en el navegador del usuario. En muchos casos, el usuario ni siquiera es consciente de lo que está ocurriendo. Los tipos principales de ataques XSS son:
Reflected: Normalmente se basan en conseguir que el usuario siga un link o complete un formulario malicioso, aunque aparentemente normal. (ejemplo: Phising)
Stored: El código malicioso se inyecta en algún elemento persistente, como una base de datos, de manera que se consigue que se ejecute en el navegador del cliente al recuperar la información almacenada.
Estos defectos ocurren cuando una aplicación recibe objetos serializados dañinos y estos pueden ser manipulados por el atacante para realizar ataques de repetición, inyecciones o modificar sus privilegios de ejecución. En el peor de los casos, la deserialización insegura puede conducir a la ejecución remota de código en el servidor.
Los datos serializados (que el atacante envía al servidor de consumo de servicios) hacen que se ejecute, al momento de deserializar, un código arbitrario (malicioso).
Este tipo de ataque ocurre cuando se emplean librerías o frameworks que contienen vulnerabilidades. Un ejemplo de esta vulnerabilidad es la no actualización de los plugins de WordPress.
No es en sí una vulnerabilidad de las aplicaciones, pero si hace que la detección y las acciones de mitigación sean más dificultosas y lleven más tiempo.
Con estos 10 puntos, podemos definir nuestra línea base de actuación en temas de seguridad, y a partir de ella, hacer un checklist e incorporarlo como tarea en nuestro desarrollo Agile.
¿Qué valor añadido le daría a un cliente el saber que el desarrollo que ha contratado o realizado, además de cumplir funcionalmente con las especificaciones, cumple unos mínimos de seguridad?
Y a partir de aquí, ¿cómo seguimos? Con nuestra línea base definida, con nuestros mínimos de seguridad implementados, ahora toca ir evolucionando y madurando de forma incremental como en cualquier otro sistema de calidad que tengamos en nuestra empresa.
