Resultados experimentos - Sprint 4

Detección de ataques

Verificar integridad del mensaje

Primero se recibio el siguiente correo en donde se tenía el reporte y el hash de verificación:

En primera instancia este fue el hash generado al analizar el reporte enviado (igual al del correo):

Posteriormente se modifico el reporte y trato de validarse el hash respectivo, el resultado fue el siguiente:

También se puede ver que para acceder al PDF se requiere la contraseña que se la como llave a cada usuario en su registro:

Resistencia a ataques

Identificar, autenticar y autorizar actores

• AUTENTICACIÓN CON JWT (JSON Web Token)

Login

Para la experimentación utilizamos el usuario admin, el cual tiene permisos para crear usuarios y realizar consultas a los servicios de CCT. El mecanismo de autenticación genera un token JWT el cuál contiene la información del usuario y debe ser enviado en las peticiones a los servicios de la aplicación en el header Authorization.

Crear usuario

Autorización Se procede a crear el usuario con el que se realizarán las pruebas. Se realiza la petición utilizando el token de autenticación generado en la petición anterior.

Creación

Utilizando el token de autenticación se realiza la petición, en la respuesta podemos observar las llaves que se crearon para este usuario. En este caso la llave privada (privateKey) es la llave que se utilizará para encriptar los reportes.

Validación de permisos

Realizamos el login con el usuario recién creado.

Para efectos del ejemplo, intentamos crear un usuario en el sistema, lo cuál no es posible ya que el usuario que estamos utilizando no tiene rol de ADMIN y por lo tanto no puede acceder a esta funcionalidad.

La respuesta del servicio a la petición es un 401 (Unauthorized). Por lo tanto este usuario nunca podrá acceder a servicios que no estén configurados dentro de su dominio de permisos de la aplicación.

Generación de reporte

Procedemos a probar la generación de un reporte, en este caso un reporte de Inventario. Para esto el usuario indica el tipo de reporte, la fecha inicial y la fecha final.

En la respuesta podemos observar que se indica así mismo el MD5 del reporte recién generado y la url donde el usuario podrá descargarlo.

De igual forma este reporte será enviado al correo electrónico del usuario, donde de igual manera se le indica la información de seguridad.

Envío del reporte Reporte encriptado

Para efectos de seguridad, y evitar information disclosure, los reportes son encriptados con la clave privada de cada usuario, esta clave es diferente a la clave de acceso al sistema y no debe ser publicada.

Una vez ingresamos la clave con la que se encriptó el reporte, es posible visualizarlo.

En caso de que el reporte sea utilizado desde una computadora y no desde la web, el usuario que está observando este reporte puede realizar la verificación del documento accediendo a la url que se encuentra en la parte inferior, donde encontrará una copia exacta del documento generado originalmente. En caso de que este documento haya sido vulnerado, es posible realizar la detección del cambio a través de la suma de chequeo que fue enviada al usuario.

Encriptar información

Al acceder al servicio usando el protocolo HTTP fue posible ver como la página web redigiria automaticamente al aplicativo en HTTPS: