Esta traducci贸n proporcionada por StrongLoop / IBM.

Este documento puede estar desfasado respecto a la documentaci贸n en ingl茅s. Para ver las 煤ltimas actualizaciones, consulte la documentaci贸n en ingl茅s.

Mejores pr谩cticas de producci贸n: seguridad

Visi贸n general

El t茅rmino 鈥減roducci贸n鈥 hace referencia a la etapa del ciclo de vida del software donde una aplicaci贸n o una API tiene disponibilidad general para sus consumidores o usuarios finales. Por su parte, en la etapa de 鈥渄esarrollo鈥, todav铆a est谩s escribiendo y probando activamente el c贸digo, y la aplicaci贸n no est谩 abierta para el acceso externo. Los correspondientes entornos del sistema se conocen como los entornos de producci贸n y desarrollo, respectivamente.

Los entornos de desarrollo y producci贸n se configuran normalmente de forma diferente y tiene requisitos tambi茅n muy diferentes. Lo que funciona en el desarrollo puede que no sea aceptable en la producci贸n. Por ejemplo, en un entorno de desarrollo, puede que desee el registro detallado de errores a efecto de depuraci贸n, mientras que el mismo comportamiento puede suponer un problema de seguridad en un entorno de producci贸n. De la misma forma, en el desarrollo, no es necesario preocuparse por la escalabilidad, la fiabilidad y el rendimiento, mientras que estos son clave en la producci贸n.

Note: Si crees haber encontrado una vulnerabilidad de seguridad en Express, por favor mira nuestras Pol铆ticas de Seguridad y Procedimientos.

Las mejores pr谩cticas de seguridad para aplicaciones Express en producci贸n incluyen:

No utilizar versiones en desuso o vulnerables de Express

Express 2.x y 3.x ya no se mantienen. Los problemas de seguridad y rendimiento en estas versiones no se solucionar谩n. No las utilice. Si no ha cambiado todav铆a a la versi贸n 4, siga la gu铆a de migraci贸n.

Asimismo, aseg煤rese de que no est谩 utilizando ninguna de las versiones vulnerables de Express que se listan en la p谩gina Actualizaciones de seguridad. Si las utiliza, actual铆cese a uno de los releases estables, preferiblemente el m谩s reciente.

Utilizar TLS

Si la aplicaci贸n maneja o transmite datos confidenciales, utilice Transport Layer Security (TLS) para proteger la conexi贸n y los datos. Esta tecnolog铆a cifra los datos antes de enviarlos desde el cliente al servidor, lo que evita algunos de los ataques de pirateo m谩s comunes (y sencillos). Aunque las solicitudes Ajax y POST no sean obvias visiblemente y parezca que est谩n 鈥渙cultas鈥 en los navegadores, su tr谩fico de red es vulnerable para los rastreos de paquetes y los ataques de intermediarios.

Es posible que est茅 familiarizado con el cifrado SSL (Secure Socket Layer). TLS es simplemente el siguiente paso despu茅s de SSL. Es decir, si antes utilizaba SSL, se recomienda actualizar a TLS. En general, se recomienda Nginx para manejar TLS. Encontrar谩 una buena referencia para configurar TLS en Nginx (y otros servidores) en la wiki de Mozilla Recommended Server Configurations.

Asimismo, una herramienta muy 煤til para obtener un certificado de TLS gratis es Let鈥檚 Encrypt, una entidad emisora de certificados (CA) abierta, automatizada y gratuita proporcionada por Internet Security Research Group (ISRG).

Utilizar Helmet

Helmet ayuda a proteger la aplicaci贸n de algunas vulnerabilidades web conocidas mediante el establecimiento correcto de cabeceras HTTP.

Helmet es realmente una colecci贸n de nueve funciones de middleware m谩s paquetes que establecen cabeceras HTTP relacionadas con la seguridad:

Instale Helmet como cualquier otro m贸dulo:


$ npm install --save helmet

A continuaci贸n, util铆celo en el c贸digo:


...
var helmet = require('helmet');
app.use(helmet());
...

Como m铆nimo, inhabilitar la cabecera X-Powered-By

Si no desea utilizar Helmet, como m铆nimo, inhabilite la cabecera X-Powered-By. Los atacantes pueden utilizar esta cabecera (que est谩 habilitada de forma predeterminada) para detectar las aplicaciones que ejecutan Express e iniciar ataques con destinos espec铆ficos.

Por lo tanto, se recomienda desactivar la cabecera con el m茅todo app.disable():


app.disable('x-powered-by');

Si utiliza helmet.js, lo hace autom谩ticamente.

Utilizar cookies de forma segura

Para garantizar que las cookies no abran la aplicaci贸n para ataques, no utilice el nombre de cookie de sesi贸n predeterminado y establezca las opciones de seguridad de las cookies correctamente.

Hay dos m贸dulos de sesi贸n de cookies de middleware principales:

La principal diferencia entre los dos m贸dulos es c贸mo guardan los datos de sesi贸n de las cookies. El middleware express-session almacena los datos de sesi贸n en el servidor; s贸lo guarda el ID de sesi贸n en la propia cookie, no los datos de sesi贸n. De forma predeterminada, utiliza el almacenamiento en memoria y no est谩 dise帽ado para un entorno de producci贸n. En la producci贸n, deber谩 configurar un almacenamiento de sesi贸n escalable; consulte la lista de almacenes de sesi贸n compatibles.

Por su parte, el middleware cookie-session implementa un almacenamiento basado en cookies: serializa la sesi贸n completa en la cookie, en lugar de s贸lo una clave de sesi贸n. Util铆celo s贸lo cuando los datos de sesi贸n sean relativamente peque帽os y f谩cilmente codificables como valores primitivos (en lugar de objetos). Aunque se supone que los navegadores pueden dar soporte a 4096 bytes por cookie como m铆nimo, para no exceder el l铆mite, no supere un tama帽o de 4093 bytes por dominio. Asimismo, aseg煤rese de que los datos de la cookie est茅n visibles para el cliente, para que si se deben proteger u ocultar por cualquier motivo, se utilice mejor la opci贸n express-session.

Si utiliza el nombre de cookie de sesi贸n predeterminado, la aplicaci贸n puede quedar abierta a los ataques. El problema de seguridad que supone es similar a X-Powered-By: un posible atacante puede utilizarlo para firmar digitalmente el servidor y dirigir los ataques en consecuencia.

Para evitar este problema, utilice nombres de cookie gen茅ricos, por ejemplo, con el middleware express-session:


var session = require('express-session');
app.set('trust proxy', 1) // trust first proxy
app.use( session({
   secret : 's3Cur3',
   name : 'sessionId',
  })
);

Establecer las opciones de seguridad de las cookies

Establezca las siguientes opciones de cookies para mejorar la seguridad:

A continuaci贸n, se muestra un ejemplo de uso del middleware cookie-session:


var session = require('cookie-session');
var express = require('express');
var app = express();

var expiryDate = new Date( Date.now() + 60 * 60 * 1000 ); // 1 hour
app.use(session({
  name: 'session',
  keys: ['key1', 'key2'],
  cookie: { secure: true,
            httpOnly: true,
            domain: 'example.com',
            path: 'foo/bar',
            expires: expiryDate
          }
  })
);

Prevenir ataques de fuerza bruta a la autenticaci贸n

Asegurate de que los puntos finales del inicio de sesi贸n est谩n protegidos para convertir los datos privados m谩s seguros.

Una simple y potente t茅cnica es bloquear intentos de autorizaci贸n usando dos m茅tricas:

  1. Seg煤n el n煤mero de intentos fallidos consecutivos por el mismo nombre de usuario y direcci贸n IP.
  2. Seg煤n el n煤mero fallido de intentos desde una direcci贸n IP a lo largo de un cierto per铆odo de tiempo. Por ejemplo, bloquear una direcci贸n IP si realiza 100 intentos fallidos en un d铆a.

El paquete rate-limiter-flexible ofrece herramientas para realizar esta t茅cnica de forma f谩cil y r谩pida. Aqu铆 puedes encontrar un ejemplo de protecci贸n de fuerza bruta en la documentaci贸n.

Asegurarse de que las dependencias sean seguras

El uso de npm para gestionar las dependencias de la aplicaci贸n es muy 煤til y c贸modo. No obstante, los paquetes que utiliza pueden contener vulnerabilidades de seguridad cr铆ticas que tambi茅n pueden afectar a la aplicaci贸n. La seguridad de la aplicaci贸n s贸lo es tan fuerte como el 鈥渆nlace m谩s d茅bil鈥 de las dependencias.

Desde npm@6, npm revisa autom谩ticamente cada solicitud de instalaci贸n. Tambi茅n puedes utilizar 鈥榥pm audit鈥 para analizar tu 谩rbol de dependencias.

$ npm audit

Si quieres mantener m谩s seguro, considera Snyk.

Snyk ofrece tanto herramienta de l铆nea de comandos como una integraci贸n de Github que comprueba tu aplicaci贸n contra la base de datos de c贸digo abierto sobre vulnerabilidades de Snyk por cualquier vulnerabilidad conocida en tus dependencias. Instala la interfaz de l铆nea de comandos:

$ npm install -g snyk
$ cd your-app

Usa este comando para comprobar tu aplicaci贸n contra vulnerabilidades:

$ snyk test

Usa este comando para abrir un asistente que te guiar谩 mediante el proceso de aplicar actualizaciones o parches para arreglar las vulnerabilidades que hayan sido encontradas:

$ snyk wizard

Evitar otras vulnerabilidades conocidas

Est茅 atento a las advertencias de Node Security Project que puedan afectar a Express u otros m贸dulos que utilice la aplicaci贸n. En general, Node Security Project es un excelente recurso de herramientas e informaci贸n sobre la seguridad de Node.

Por 煤ltimo, las aplicaciones de Express, como cualquier otra aplicaci贸n web, son vulnerables a una amplia variedad de ataques basados en web. Familiar铆cese con las vulnerabilidades web conocidas y tome precauciones para evitarlas.

Consideraciones adicionales

A continuaci贸n, se muestran algunas recomendaciones para la excelente lista de comprobaci贸n Node.js Security Checklist. Consulte el post de este blog para ver todos los detalles de estas recomendaciones: