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谩 escribiendo y probando activamente el c贸digo, y la aplicaci贸n no est谩 abierta para el acceso externo. Los entornos del sistema correspondientes 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.

En este art铆culo se describen las mejores pr谩cticas de seguridad para las aplicaciones Express desplegadas en producci贸n.

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
          }
  })
);

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.

Utilice una o las dos herramientas siguientes para garantizar la seguridad de los paquetes de terceros que utiliza: nsp y requireSafe. Las dos herramientas hacen pr谩cticamente lo mismo.

nsp es una herramienta de l铆nea de mandatos que comprueba la base de datos de vulnerabilidades de Node Security Project para determinar si la aplicaci贸n utiliza paquetes con vulnerabilidades conocidas. Inst谩lela de la siguiente manera:


$ npm i nsp -g

Utilice este mandato para enviar el archivo npm-shrinkwrap.json para su validaci贸n a nodesecurity.io:


$ nsp audit-shrinkwrap

Utilice este mandato para enviar el archivo package.json para su validaci贸n a nodesecurity.io:


$ nsp audit-package

requireSafe se utiliza de la siguiente manera para auditar los m贸dulos de Node:


$ npm install -g requiresafe
$ cd your-app
$ requiresafe check

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:

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.