Sprint 3. Documentanción de Resultados y Análisis

1. Selección de tecnologías y frameworks

Para el desarrollo del Sprint 3, se usaron varias tecnologías dentro de las que se comprende: una base de datos Postgres que permitía un mejor y mayor manejo de datos basados en los modelos que se construyeron con Django/Python; Python que fue el lenguaje principal de desarrollo de nuestro proyecto, permitió junto al framework Django un manejo más fácil de las consultas en la base de datos, aprovechar el uso del ORM provisto por el framework y una nueva comprensión del desarrollo basado en MVT (model, view, template). Por otro lado, se utilizó el API de Auth0 integrado con el framework Django para cubrir y garantizar la autenticación y autorización de los usuarios dentro de la aplicación, esta API permitió separar de la base de datos principal los datos sobre los usuarios (email, contraseñas, entre otros) y así garantizar una mejor distribución en el almacenamiento con base al tipo de datos. Continuando con la presentación de las tecnologías usadas, se incluyó Nginx es un servidor web/proxy inverso ligero de alto rendimiento, éste se usó para generar un load balancer que permite redireccionar ciertas peticiones que apuntan a URLs no existentes o que se encuentran en mantenimiento a una página amigable que informa al usuario que se encuentra en uno de los estados mencionados anteriormente.

Finalmente, no sobra nombrar los editores que se utilizaron para escribir el código del proyecto, estos fueron: Visual Studio Code y PyCharm.

Estas fueron las principales tecnologías y frameworks ocupados durante el desarrollo del Sprint 3.

2. Diseño y análisis de los escenarios de prueba

ASR 1: Consulta de historial de pedidos (Autenticación y Autorización)

Con base al escenario de prueba definido para el ASR 1, se probarán los siguientes pasos:

Se hará login con las credenciales de un tendero que tiene permisos sobre todas las funcionalidades de su tienda:

Se escriben las credenciales:

Se visualiza su página de inicio como tendero:

Se visualiza la lista de los últimos pedidos ordenados cronológicamente ordenados a esa tienda:

Se realiza un logout que permite volver a la página de inicio y posteriormente se intenta probar acceder a las distintas URLs que se empleaban anteriormente para ver si puede acceder si autenticación o autorización:

Acá se intenta a ingresar a la sección de autenticado que es donde se presenta la interfaz después de haber iniciado sesión de un tendero

Lo que sucede es que automáticamente lo dirige a que se autentique para poder proceder a esta sección:

Lo mismo sucede cuando se intenta ingresar a la sección del historial de pedidos (lo dirige al proceso de autenticación):

El objetivo de este escenario de prueba fue entonces probar que dicho usuario no pueda acceder a estos servicios, evitando así accesos no autorizados o elevación de privilegios.

A modo de conclusión, se observa que el escenario de prueba hace cumplir el atributo de confidencialidad planteado en el ASR 1.

ASR 2: Consulta de pedidos sugeridos (Integridad)

Basado en el escenario de prueba definido para el ASR 2, se realizó un intento de ataque SQL Injection a la plataforma, cuando el tendero accede a la lista de sus pedidos. El ataque se realizó como se describe a continuación:

1. En primer lugar, se accedió a la cuenta de uno de los tenderos registrados en la plataforma.

2. Luego, se accedió a la lista de sus pedidos, como se observa en la siguiente imagen:

3. En la figura anterior, se puede observar que el tendero tiene un pedido del producto "Leche Alpina". Por lo tanto, se procedió a intentar realizar el ataque mediante la URL, insertando en esta la sentencia para borrar los pedidos del tendero de la base de datos. Lo anterior se puede observar en la ruta del navegador en la siguiente figura:

4. El resultado obtenido al dar enter fue el siguiente, que es un error normal que se da al cargar la ruta.

5. Finalmente, al volver a cargar la ruta para obtener la lista de pedidos del tendero se obtuvo lo siguiente:

6. Se puede observar que el pedido realizado por el tendero sigue sin modificarse, debido a que el ataque intentado falló y no se borró el pedido de la base de datos.

Se puede concluir que el resultado obtenido anteriormente se debe a que todas las consultas que se realizan a la base de datos utilizan el ORM de Django. En ningún caso se ejecutan queries directamente en la base de datos. Es decir, no se utilizan raw(), extra() ni RawSQL.

• Adicionalmente, para tener certeza sobre la resistencia de la plataforma ante ataques de este tipo, se utilizó una herramienta llamada Bandit, la cual permite encontrar problemas de seguridad en Python mediante el procesamiento de cada archivo del proyecto bajo análisis (en este caso, el nuestro). A cada archivo se le realiza un AST (Application Security Testing) y, al finalizar el procesamiento (escaneo) de todos los archivos, la herramienta genera un reporte (guardado en un archivo html). Este archivo informa sobre dos aspectos importantes:

  • Severity : Severidad del hallazgo al procesar los archivos.
  • Confidence : Nivel de confianza que se tiene sobre el hallazgo específico.

También se pueden ver los test realizados por la herramienta, que son B311 y B105, los cuales analizan las vulnerabilidades en cuanto a las queries realizadas en el código. En nuestro caso, luego de correr el análisis con la herramienta obtuvimos los siguientes resultados:

Como se observa, el reporte muestra que las posibles vulnerabilidades para los ataques de inyección SQL tienen una severidad baja en todos los casos, lo que permite asegurar que el sistema resiste y resistirá los ataques que se intenten realizar (de nuevo, debido a que se hace uso efectivo del ORM de Django).

El reporte se puede observar más detalladamente en la siguiente página: https://reportebanditcanem.stackblitz.io

ASR 3: Redireccionamiento a página de mantenimiento (Disponibilidad)

A continuación, se presentan los escenarios de prueba aplicados para el ASR3:

• Caso 1: Finalizar los servicios por parte de los servidores.

En primer lugar, se establecieron dos máquinas virtuales EC2 de AWS para proveer el servicio a probar, la configuración de las máquinas y del Load Balancer implementado en Nginx se presenta a continuación:

A continuación, se presenta la vista principal al visitar la página:

Después de hacer login en la aplicación, se visualiza la siguiente interfaz:

Al hacer uso del botón inferior, se obtienen los siguientes resultados:

Se detiene la máquina 1 para probar la funcionalidad presentada por el segundo servidor:

Se obtienen los siguientes resultados al acceder nuevamente a la funcionalidad presentada en el botón inferior:

Se detiene la máquina 2 para probar la funcionalidad del ASR prestada por parte del Load Balancer:

Dado que no hay ningún servidor activo, el Load Balancer se encarga de cubrir el requerimiento presentado en el ASR por medio de la presentación de la siguiente pantalla:

• Caso 2: Se despliegan los servidores sin la funcionalidad a analizar.

Después de hacer login en la aplicación, el tendero asociado ve la siguiente pantalla (nótese la ausencia del botón inferior):

Al intentar acceder de forma directa a la funcionalidad por medio de la manipulación de la URL, se obtiene la siguiente pantalla:

• Caso 3: Se intenta acceder a enlaces inexistentes:

Tal como se puede observar en la siguiente imagen, cuando un usuario de la aplicación intenta acceder directamente a un enlace que no existe en el sistema de Chiper, el Load Balancer se encarga de mostrar esta interfaz:

Para concluir, tal como se puede observar en las anteriores imágenes, para el ASR 3 se cumple el requerimiento estipulado: cuando el sistema se encuentra degradado, el tendero visualiza correctamente una página de aviso de mantenimiento al intentar acceder a la opción de consultar el historial de pedidos realizados a Chiper.