Cómo mejorar la seguridad de tu API

Como mejorar la seguridad de tu API

Existen en el mercado muchísimas herramientas que te ayudan a incrementar la seguridad de tu API, comenzando a bajo nivel mediante la revisión de vulnerabilidades de las librerías que emplea tu framework de desarrollo favorito hasta simulaciones de intentos de romper la API una vez publicada.

Hoy nos centraremos en estas últimas pero empleandolas en las primeras fases del desarrollo.

Usaremos stackhack , un servicio cloud que nos permite escanear nuestra API mediante fuerza bruta para identificar ciertas vulnerabilidades que podrían ser aprovechadas por un atacante que cuando la API esté publicada y expuesta al público.

Accediendo al servicio

Darse de alta en stackhawk.com es muy sencillo y en pocos minutos nos habrá proporcionado una cuenta para desarrolladores con 15 días de prueba.
Es importante que en el proceso de registro y mientras seguimos la guía guardemos el token de acceso que nos proporciona en un lugar seguro y además lo añadamos al fichero de configuración según los pasos que se indica.

Ya en el último paso nos indicará que descarguemos una plantilla del fichero de configuración.

Cómo funciona stackhawk

El funcionamiento es bien sencillo , pero no exento de cumplir unas mínimas reglas.

Dispondremos en su página web de un espacio de trabajo donde se representarán los "entornos" y se asociarán los resultados de las revisiones de nuestra aplicación.

Las revisiones se ejecutarán en nuestro equipo local mediante un contenedor de docker, por ello es importante que tengamos -docker- funcionando correctamente en nuestro equipo. En todo momento la url donde se encuentre publicada la API debe ser accesible desde nuestro equipo, en nuestro caso la API corre en http://localhost:3000 , por lo que no habrá ningún problema.

Cada vez que revisamos la API desde la línea de comando recibiremos un informe y este será remitido al espacio de trabajo de stackhawk por lo que podremos consultar los distintos informes y ver cómo afectan los cambios incorporados.

Por dónde comenzamos

El primer punto es configurar mediante la plantilla unos parámetros mínimos.

app:
  applicationId: XXXXX-XXXX-XXXX-XXXX-XXXXXXXXX # (required)
  env: Development # (required)
  host: 'http://localhost:3000/'
  api: './openapi.json'

Habremos recibido una applicationId que representa la aplicación que vamos a testear. Podemos obtener uno desde el espacio de trabajo al pulsar sobre "Add an APP" aunque por estar en la versión demo solo podremos tener una aplicación.

Es importante indicar un entorno, ya que todas las ejecuciones se agrupan por este campo.

Indicaremos el host , sin indicar la ruta a la API, pero si el puerto.
(*) Recordar en todo momento emplear las comillas simples de lo contrario obtendréis un mensaje como este:

Error: HawkScan is unable to continue.
Please check the target host configuration -
        host: "http://localhost:3000/",
Be sure to include any additional host paths with their respected keys.
(e.g. `loginPath` or `schemaPath`) 

Ahora quizás lo más complicado es que debemos disponer de la especificación openapi o swagger de nuestra API en formato .json o .yaml

Y debemos revisar que los recursos se correspondan con el uri completo.
En mi ejemplo la api se encuentra en /api , y el recurso es /qrisk2 , por ello en la definición de la api se modificar por :

    "paths": {
        "/api/qrisk2": {
            "get": {
                "responses": {
                    "200": {

Arrancamos

Bien con esto preparado es el momento de recibir nuestro primer resultado, para ello ejecutamos el contenedor con la siguiente línea de comandos:

$ source ~/.hawk/hawk.rc ; \
docker run -e API_KEY=${HAWK_API_KEY} --rm -v $(pwd):/hawk:rw \
-it stackhawk/hawkscan:latest

La primera vez que ejecutemos tardará un momento en descargar la imagen y una vez que comience la ejecución nos aparecerá algo similar a ...

Bien , ya tenemos nuestro primer informe. Veamos que podemos mejorar.

Al acceder al espacio de trabajo vemos nuestro entorno

Si pulsamos sobre el símbolo " ⋮ " , podemos seleccionar View Scans .

Vemos al última ejecución y nos encontramos con 6 incidencias de importancia media y otras 6 de carácter Low , si las revisamos nos damos cuenta pronto que en realidad una la podemos descartar porque hace referencia a que NO disponemos de un endpoint accessible mediante https , lógico estamos en local.

Como eliminar la primera incidencia de seguridad

Veamos otro de los aspectos que debemos revisar en nuestro desarrollo, nos centraremos en los de nivel Low , vemos que las 6 hacen referencia al mismo problema en diferentes rutas.

Esta indica que mediante el uso de la cabecera "X-Powered-By" un atacante puede identificar el framework que emplea nuestra API y puede focalizar el ataque en el o identificar una vulnerabilidad de último día que pueda afectarla. En este caso lo que debemos hacer es no aportar esta información.

Mi API usa Node.js y Express , por lo que para solventar este inconveniente puedo apoyarme en un módulo que me facilitará mucho el trabajo , llamado helmet.

Lo instalamos en el proyecto.

npm install helmet

He iremos a la sección de nuestro código donde configuramos el servidor express, importamos el módulo y hacemos uso de él.

const helmet = require('helmet');

// Hide the X-Powered-By header
server.use(helmet.hidePoweredBy());

Y voilá...
Arrancamos de nuevo nuestra api y lanzamos de nuevo el scanner desde la línea de comando.

Volvemos al espacio de trabajo y podremos observar que ya no aparecen los 6 fallos de tipo Low

Conclusiones

Una herramienta de estas características nos permitirá revisar que mantenemos en nuestro desarrollo un cierto nivel de control sobre la seguridad. Con el tiempo y solventando las incidencias iremos incorporando de forma continua a nuestras aplicaciones buenas prácticas que eviten exponer información comprometida a terceros o que facilite el acceso no autorizado a nuestros servicios.

Evidentemente, nunca podremos estar 100% seguros pero es un paso en la buena dirección.

La plataforma de stackhack permite la integración con la mayoría de soluciones de gestión de código y de despliegue, de modo que podemos validar nuestra API antes de publicarla e incluso modificando el fichero de configuración cuando esta esté publicada en su URL final.