DEV Community: Alfred Tejeda

API Testing basado en OWASP

Alfred Tejeda — Mon, 17 May 2021 18:46:58 +0000

En API Testing y no morir en el intento realicé una introducción sobre qué deberíamos de probar en una API, en esta oportunidad vamos a tomar en consideración el top 10 de OWASP para que agreguemos casos de pruebas de introducción a seguridad.
Para que la lectura no sea tan larga, he decidido abarcar 2 puntos por post.

OWASP (Open Web Application Security Project), es un proyecto sin ánimo de lucro a nivel mundial que busca mejorar la seguridad del software en general. Para esto, la organización se ha provisto de una serie de herramientos y documentos que explican cuáles son las brechas de seguridad más comunes en cualquier sistema de información. Sobra decir, que todos los materiales de OWASP están disponibles de manera libre (gratuita) para su libre consulta y uso.

1. Autorización segura a nivel de objeto:

Las API suelen procesar sus funcionalidades a través del uso de identificadores de objetos.
Supongamos que tenemos un endpoint al que se le indica el número de documento que queremos acceder:

method	endpoint	result
GET	/document/2000	200 OK
GET	/document/2001	200 OK
GET	/document/1999	404 Not Found

Podemos evidenciar que el número de documento es un valor consecutivo, por lo que un atacante puede intentar acceder a estos documentos o saber cuales se encuentra disponibles o no. Para este punto que estamos tratando como QAs (debemos ser preventivos, según definición) podemos recomendar al equipo de desarrollo que el número de documento se encuentre cifrado y podemos crear un caso de prueba que evalue que al colocar un valor no cifrado este retorne error , por lo que al ejecutar nuestras pruebas podríamos tener el siguiente resultado:

method	endpoint	result
GET	/document/2000	400 Bad Request
GET	/document/08f90c1a417155361a5c4b8d297e0d78	200 OK
GET	/document/1999	400 Bad Request

2. Autenticación insegura

Los mecanismos de autenticación a menudo se implementan de manera incorrecta, permitiendo a los atacantes comprometer los tokens de autenticación o explotar las fallas de implementación para asumir las identidades de otros usuarios temporal o permanentemente. Comprometer la capacidad del sistema para identificar al cliente / usuario, compromete la seguridad de la API en general. Pero, ¿Esto a qué hace referencia?. Veamos:
Un usuario (puede ser atacante o no) intenta realizar un inicio de sesión exitoso:

method	endpoint	result
POST	/login user / password1	Contraseña incorrecta 403 Forbidden
POST	/login user / password2	Contraseña incorrecta 403 Forbidden
POST	/login user / passwordN	Contraseña incorrecta 403 Forbidden
POST	/login user / password1000	Autenticado 200 OK

Podemos evidenciar que luego de mil intentos pudo acceder, pero se debería permitir tantos intentos, la recomendación que debemos dar es establecer un límite de intentos ya sea para suspender y/o bloquear la cuenta. En mi experiencia he visto que para evitar esta autenticación insegura se establece un límite de 3 intentos para suspensión y luego 6 para bloqueo, por otra parte he visto un límite de 3 intentos por día para suspensión, 6 intentos (entre 2 días) bloqueo preventivo y 9 intentos (entre 3 días) bloqueo definitivo. Esto por su puesto va anclado al tipo de negocio, pero la finalidad es la misma: ¡Establecer límites de intentos! Así nuestros casos de prueba se basarían en probar estos límites:

method	endpoint	result
POST	/login user / password1	Contraseña incorrecta 403 Forbidden
POST	/login user / password2	Contraseña incorrecta, queda 1 intento 403 Forbidden
POST	/login user / passwordN	Contraseña incorrecta 403 Forbidden

Otro escenario dónde los procesos de autenticación son inseguros puede ser el siguiente, el usuario (atacante o no) desea conocer si un correo se encuentra registrado o no, para ello utiliza la opción de recuperar contraseña. Veamos:

method	endpoint	result
POST	/password_recovey usuario1@yopmail.com	El usuario no existe 200 OK
POST	/password_recovey usuario2@yopmail.com	El usuario no existe 200 OK
POST	/password_recovey usuarioN@yopmail.com	El usuario no existe 200 OK
POST	/password_recovey usuario100@yopmail.com	Se enviaron las instrucciones al correo 200 OK

Acá podemos evidenciar que el sistema está indicando si el correo existe o no, por lo que le estamos dando la respuesta que el atacante esperaba. Cómo sugerencia podemos indicar que la respuesta del servicio pueda ser "Se enviaron las instrucciones al correo" aún si el correo existe o no, de esta forma si un atacante realiza 1000 peticiones en las que todas respondan OK, entonces tendrá que tomar más tiempo para comprobar si en efecto el correo existe o no:

method	endpoint	result
POST	/password_recovery usuario1@yopmail.com	Se enviaron las instrucciones al correo 200 OK
POST	/password_recovery usuario2@yopmail.com	Se enviaron las instrucciones al correo 200 OK
POST	/password_recovery usuarioN@yopmail.com	Se enviaron las instrucciones al correo 200 OK
POST	/password_recovery usuario1000@yopmail.com	Se enviaron
las instrucciones al correo 200 OK

Se puede sugerir alguna estrategia, una no muy común pero si efectiva que he visto en mi trayecto es enviar un mensaje indicando que ha ocurrido un error en específico pero el mensaje si es enviado en caso de coincidir coincidencia.

Hasta este punto hemos visto 2 de los 10 puntos que OWASP nos menciona, tomando en consideración estos 2 puntos ya podemos ir creando casos de prueba que cumplan con requirimientos básicos de seguridad. En la próxima entrada hablaremos de la "Exposición excesiva de datos" y la "Falta de recursos y límites de uso".

Puedes dejarme en los comentarios, que estrategias aplican en tu corporación y que casos de prueba crees que puedan llegar a ser o sean imprescindible para evitar estos puntos

Me gusta escribir sobre testing en general, gracias a esto me doy cuenta de lo que me falta por aprender, también me encanta el café, por si deseas regalarme uno :)

Primer test

Alfred Tejeda — Sun, 09 May 2021 18:06:05 +0000

En el capítulo 1 realizamos la instalación de las librerías que vamos a usar en el proyecto y realizamos la configuración básica para poder usar Jasmine, en este capítulo vamos a organizar nuestro proyecto y realizar nuestro primer test.

Ya que deseo utilizar en el tutorial una API real, debemos de crear una cuenta en TheMovieDB, una vez creada la cuenta, iniciamos sesión, vamos a Ajustes / Api y guardamos el valor que se encuentra en Llave API / API Key (v3 auth)

¡Empezemos!

Configuración variables de entorno

Lo primero que vamos a realizar es preparar nuestro proyecto para usar variables de entorno por lo tanto en la raíz del proyecto vamos a crear un nuevo archivo .js (yo le pondré environment.js pero le pueden colocar el nombre que ustedes deseen) y dentro de él colocaremos el siguiente código:

/** environment.js */
require("dotenv").config();

module.exports = {
  API_KEY: process.env.API_KEY || "4p1k3y",
  BASE_URL: process.env.BASE_URL || "http://localhost:3000",
  USER_TMDB: process.env.USER_TMDB || "defaultUser",
  PASSWORD_TMBD: process.env.PASSWORD_TMBD || "defaultPassword",
};

Lo que estamos haciendo con estas líneas de código es exportar un objeto cuyos valores de las llaves están tomando los valores de las variables del sistema y en caso de no existir tomar un valor por defecto:

Nombre	Descripción
API_KEY	Nombre de la propiedad
process.env.API_KEY	Nombre de la variable del sistema
"4p1k3y"	Valor por defecto en caso de no existir coincidencia

En la misma raíz del proyecto un archivo que debe de llamarse .env (el archivo debe de llamarse así ya que es el valor por defecto para que dotenv lea el archivo, en caso de colocar otro nombre debemos de indicarle a dotenv la ruta del archivo que deseamos leer) y copiaremos lo siguiente:

API_KEY=TuAPIKey
BASE_URL=https://api.themoviedb.org/3/
USER_TMDB=UsuarioCreado
PASSWORD_TMBD=ContraseñaCreada

Creación de rutas

Dentro de ./spec/support vamos a crear una archivo llamado routes.js (En el vamos a especificar las diferentes rutas o endpoints que vamos a estar utilizando) y dentro de el vamos copiar el siguiente código:

module.exports = {
    authentication: {
        createRequestToken: '/authentication/token/new',
        createSession: '/authentication/session/new'
    }
}

Al igual que en environment.js acá estamos exportando también un objeto, este contiene las diferentes rutas que vamos a estar utilizando en nuestras pruebas.

Creación de nuestro primer test

Según la documentación del API de TheMovieDB antes de poder iniciar sesión debemos de solicitar un token, este será nuestro primer caso de pruebas: Vamos a validar que en efecto este parámetro esté en la respuesta y validaremos también el código de respuesta.

Dentro del directorio ./spec/vamos a crear un nuevo directorio llamado tests y dentro el crearemos un nuevo archivo llamado authentication.spec y copiaremos el siguiente código:

const axios = require('axios')
const expect = require('chai').expect
const ENV = require('../../environment')
const ROUTES = require('../support/routes')


describe('Testcases for /authentication route', () => {

    it(`Request to ${ROUTES.authentication.createRequestToken} 
    generates new token and responds 200`, async () => {
        const request = await axios({
            method: 'get',
            url: `${ENV.BASE_URL}${ROUTES.authentication.createRequestToken}`,
            params: { api_key: `${ENV.API_KEY}` }
        })
        expect(request.status).eq(200)
        expect(JSON.stringify(request.data)).contain('success')
        expect(JSON.stringify(request.data)).contain('expires_at')
        expect(JSON.stringify(request.data)).contain('request_token')
    })

})

En las primera 4 líneas estamos importando todo lo que necesitamos tanto de librerías como los objetos que creamos para ejecutar nuestros casos de prueba.
El bloque describe nos permite indicar una descripción de lo que vamos a probar, dentro de el podemos crear otros describe si requieren que sean necesarios y luego declarar los casos de prueba.
El bloque it se usa para definir el caso de prueba
Al invocar axios debemos de pasarle el método que vamos a utilizar y la url a la que hará la petición, con esto ya es suficiente para realizar una petición, pero debemos de estar pendiente de la especificación del API para saber qué mas debemos de pasarle. Para este caso la documentación no nos pide que usemos HEADERS pero si requiere queryparams, es por eso que le pasamos a axios el parámetro params el cual recibe un json. Documentación Axios
Finalmente tenemos las validaciones con expect (pueden usar should) validamos que la respuesta contenga el status y que este sea igual a 200, y que dentro de data tengamos el request_token que usaremos más adelante para poder crear una sesión.

Ejecutemos la prueba

Para ejecutar nuestra prueba, desde una terminal ejecutamos yarn test o npm test y si no hemos cometido algún error de salida tendremos lo siguiente:

Para verificar que nuestro test funciona correctamente vamos a modificar la aserción a que espere que tenga como código de estatus un 201, esto nos debería fallar, yarn test o npm test nuevamente:

Podemos evidencia que en efecto nuestra prueba si está haciendo las validaciones correctamente.
Hasta acá llega el segundo capítulo, en la próxima entrada vamos a validar un caso negativo, es decir esperar a que nos retorne error (codigo 4xx y body con mensaje de error). Los casos negativos son con los que podemos verificar si un endpoint está bien definido, si tienen los errores controlados y si en efecto el error es el que se encuentra definido.

Cualquier cuda o comentario me la pueden hacer saber, responderé a la brevedad :D

Me gusta escribir sobre testing en general, gracias a esto me doy cuenta de lo que me falta por aprender, también me encanta el café, por si deseas regalarme uno :)

API Testing y no morir en el intento

Alfred Tejeda — Sun, 09 May 2021 00:04:36 +0000

Cuando nos dicen que debemos de probar una API probablemente lo primero que se nos viene a la mente es: "utilizaré Postman" o en algunos casos SoapUI. Y no está mal; ¿pero realmente sabemos qué debemos probar en una Rest API?.

Hay varios puntos importantes a la hora de crear nuestros casos de pruebas, pero antes de hablar sobre qué debemos probar el punto más importante es entender cuál es el propósito, sabiendo esto podemos determinar nuestros datos de prueba y saber con qué debemos contrastar el resultado: con una base de datos tal vez.

Ahora veamos que debemos probar:

Código de respuesta: esto determina el comportamiento que tendrá la aplicación que consume el servicio (frontend) si debe o no mostrar información; redirigir o cualquier otra acción determinada. Hay que tener presente las 5 clases o categorías:

Rango	Uso	Descripción
1xx	Información	Se recibe la solicitud y se sigue procesando
2xx	Exitoso	La solicitud es recibida, comprendida y aceptada con éxito
3xx	Redireccionamiento	Se deben tomar más medidas para completar la solicitud
4xx	Error de cliente	La solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx	Error de servidor	El servidor no cumple con una solicitud aparentemente válida

Debemos de asegurarnos que según los datos de entrada que estamos utilizando, estemos recibiendo el código de respuesta que corresponda según la definición del endpoint.

Los códigos más comunes son: 200, 201, 304, 401, 402, 403, 404, 412, 500, 503.

Cuerpo de respuesta: si tendríamos que definir un orden de importancia el código de respuesta y cuerpo de respuestas estarían en el mismo puesto, esto determina que información va ser mostrada o utilizada desde el frontend. Esta información generalmente viene dada en formato Json por lo que deberíamos validar el JsonSchema (sobre todo si queremos aplicar contrac testing) y la información que esta trae. A su vez debemos conocer cuales campos o pares (llave - valor) son obligatorios u opcionales y sobre estos obligatorios nuestra prueba sería intentar enviar la petición sin estos valores o enviandoles vacío o null.
Métodos admitidos por el endpoint: los métodos más utilizados son GET, POST, PUT y DELETE (Lista completa de métodos), cuando recibimos la información del endpoint que vamos a probar siempre nos indican que método este utiliza, lo que debemos hacer es intentar hacer la misma petición pero con otro método.
Cabeceras de petición: las cabeceras de petición o headers permiten enviar información adicional entre el cliente y el servidor. Al igual que el cuerpo de respuesta, debemos validar que cabeceras son obligatorias y realizar la petición sin ellas, con valores errados, vacíos y nulos.

Hasta acá tenemos una base para poder empezar a validar el API, en la segunda entrada de API... sin morir en el intento! Vamos a tomar en cosideración para crear nuestros casos de prueba el top 10 de OWASP y así tener algunas pruebas básicas de seguridad.

Me gusta escribir sobre testing en general, gracias a esto me doy cuenta de lo que me falta por aprender, también me encanta el café, por si deseas regalarme uno :)

Instalación y configuración

Alfred Tejeda — Mon, 03 May 2021 22:12:29 +0000

Primera parte: Instalación de librerías y configuración inicial

Prerequisitos:

NodeJS 10 o Superior.
Editor de código (Utilizo Visual Studio Code)
Git
Opcional: Yarn

Cuando hablamos de API automation, muchas veces lo primero que se nos viene a la mente es usar RestAssured incluso es lo que recomiendan en grupos o comunidades, y si deseamos usar JavaScript lo primero que nos mencionan es el uso de Postman, aunque utilizamos la interfaz. En esta serie vamos a aprender a crear nuestro propio marco de trabajo para API testing utilizando diversas librerías de JavaScript. Empezemos!

Vas a crear un nuevo directorio (yo lo llamaré tutorial-api-automation) y dentro de el iniciar un nuevo proyecto de node, para ello abrimos una terminal (recomiendo el uso de Git Bash) y una vez dentro del directorio ejecutamos npm init -y (utilizamos -y para crear valores por defecto, en caso de querer personalizar solo usemos npm init)

$ mkdir tutorial-api-automation && cd tutorial-api-automation
$ npm init -y

Esto nos creará un nuevo archivo llamado package.json , ahora procedamos instalar las librerías que vamos a utilizar; En la terminal ejecutemos:

$ yarn add axios chai dotenv jasmine jasmine-spec-reporter -D

o en caso de no estar familiarizado con yarn podemos usar npm

$ npm install axios chai dotenv jasmine jasmine-spec-reporter -D

Librería	Uso
Axios	Librería para realizar peticiones HTTP
Chai	Librería para realizar las aserciones o validaciones
Dotenv	Librería para manejo de variables de entorno
Jasmine	Librería para ejecución de pruebas
Jasmine Spec Reporter	Librería para obtener en consola resultado de las pruebas

Una vez finalizada la instalación de nuestras librerías podemos observar que se han creado: directorio node_modules, archivo yarn.lock o package-lock.json y en nuestro package.json debemos de tener un apartado con la sección de "devDependencies".
Siguiente paso para la configuración vamos a ejecutar el siguiente comando en nuestra terminal:

$ npx jasmine init

Y esto nos crea un nuevo directorio llamado spec y dentro de este un nuevo directorio llamado support. Spec es el directorio por defecto para crear nuestros test, es el directorio por defecto de Jasmine.

Por último paso vamos a editar el archivo package.json en la sección de scripts vamos a editar el comando test por:

{
  "scripts: {
    "test": "jasmine"
  }
}

Hasta acá llega esta primera parte, hemos instalado las librerías que vamos a utilizar configurado jasmine y actualizado nuestro script para la ejecución de las pruebas.
En el próximo post vamos a crear varios directorios para organizar nuestro marco de trabajo y crear nuestro primer test.