Esta tradução fornecida pelo StrongLoop / IBM.

Este documento pode estar desatualizado em relação à documentação em Inglês. Para obter as atualizações mais recentes, consulte a documentação em Inglês.

✖

Melhores Práticas em Produção: Segurança

Visão Geral

O termo “produção” refere-se ao estágio no ciclo de vida do software onde um aplicativo ou API está geralmente disponível para os seus usuários finais ou consumidores. Em contrapartida, no estágio de “desenvolvimento”, você ainda está ativamente escrevendo e testando o código, e o aplicativo não está aberto para acesso externo. Os ambiente de sistema correspondentes são conhecidos como ambientes de produção e desenvolvimento, respectivamente.

Os ambientes de desenvolvimento e produção são geralmente configurados de forma diferente e possuem requisitos completamente diferentes. O que é bom em desenvolvimento pode não ser aceitável na produção. Por exemplo, em um ambiente de desenvolvimento você pode desejar registros detalhados de erros para depuração, enquanto o mesmo comportamento pode se tornar um risco de segurança em um ambiente de produção. E em desenvolvimento, você não precisa se preocupar com a escalabilidade, confiabilidade, e desempenho, enquanto estas preocupações se tornam críticas na produção.

Note

If you believe you have discovered a security vulnerability in Express, please see Security Policies and Procedures.

Este artigo discute algumas melhores práticas de segurança para aplicativos do Express implementadas na produção.

Não use versões descontinuadas ou vulneráveis do Express

Os Express 2.x e 3.x não são mais mantidos. Problemas de segurança e desempenho nestas versões não serão corrigidos. Não use-as! Se não tiver migrado para a versão 4, siga o guia de migração.

Assegure-se também de que não esteja usando nenhuma das versões vulneráveis do Express listadas na Página de atualizações de segurança. Se estiver, atualize para uma das liberações estáveis, preferivelmente a mais recente.

Use TLS

Se o seu aplicativo negocia com ou transmite dados sensíveis, use a Segurança da Camada de Transporte (TLS) para proteger a conexão e os dados. Esta tecnologia criptografa os dados antes deles serem enviados do cliente para o servidor, assim evitando alguns ataques comuns (e fáceis). Apesar de solicitações Ajax e POST não parecerem visivelmente óbvias e parecerem “ocultas” em navegadores, o seu tráfego de rede é vulnerável a sniffing de pacotes e ataques man-in-the-middle .

Você pode estar familiarizado com a criptografia Secure Sockets Layer(SSL). O TLS é simplesmente a próxima progressão do. Em outras palavras, se você estava usando o SSL antes, considere fazer o upgrade para o TLS. Em geral, recomendamos o Nginx para lidar com o TLS. Para obter uma boa referência para configurar o TLS no Nginx (e outros servidores), consulte Configurações Recomendadas de Servidores (Mozilla Wiki).

Além disso, uma ferramenta útil para obter um certificado TLS gratuito é a Let’s Encrypt, uma autoridade de certificação (CA) gratuita, automatizada, e aberta fornecida pelo Grupo de Pesquisas de Segurança da Internet (ISRG).

Do not trust user input

For web applications, one of the most critical security requirements is proper user input validation and handling. This comes in many forms and we will not cover all of them here. Ultimately, the responsibility for validating and correctly handling the types of user input your application accepts is yours.

Prevent open redirects

An example of potentially dangerous user input is an open redirect, where an application accepts a URL as user input (often in the URL query, for example ?url=https://example.com) and uses res.redirect to set the location header and return a 3xx status.

An application must validate that it supports redirecting to the incoming URL to avoid sending users to malicious links such as phishing websites, among other risks.

Here is an example of checking URLs before using res.redirect or res.location:

app.use((req, res) => {
  try {
    if (new Url(req.query.url).host !== 'example.com') {
      return res.status(400).end(`Unsupported redirect to host: ${req.query.url}`)
    }
  } catch (e) {
    return res.status(400).end(`Invalid url: ${req.query.url}`)
  }
  res.redirect(req.query.url)
})

Use Helmet

O Helmet pode ajudar a proteger o seu aplicativo de algumas vulnerabilidades da web bastante conhecidas configurando os cabeçalhos HTTP adequadamente.

Helmet is a middleware function that sets security-related HTTP response headers. Helmet sets the following headers by default:

Each header can be configured or disabled. To read more about it please go to its documentation website.

Instale o Helmet como qualquer outro módulo:

$ npm install helmet

Em seguida use-o no seu código:

// ...

const helmet = require('helmet')
app.use(helmet())

// ...

Reduce fingerprinting

It can help to provide an extra layer of security to reduce the ability of attackers to determine the software that a server uses, known as “fingerprinting.” Though not a security issue itself, reducing the ability to fingerprint an application improves its overall security posture. Server software can be fingerprinted by quirks in how it responds to specific requests, for example in the HTTP response headers.

By default, Express sends the X-Powered-By response header that you can disable using the app.disable() method:

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

Note

Disabling the X-Powered-By header does not prevent a sophisticated attacker from determining that an app is running Express. It may discourage a casual exploit, but there are other ways to determine an app is running Express.

Express also sends its own formatted “404 Not Found” messages and formatter error response messages. These can be changed by adding your own not found handler and writing your own error handler:

// last app.use calls right before app.listen():

// custom 404
app.use((req, res, next) => {
  res.status(404).send("Sorry can't find that!")
})

// custom error handler
app.use((err, req, res, next) => {
  console.error(err.stack)
  res.status(500).send('Something broke!')
})

Use cookies de maneira segura

Para assegurar que os cookies não deixem o seu aplicativo aberto a ataques, não use o cookie de sessão padrão e configure as opções de segurança de cookies adequadamente.

Existem dois módulos de middleware principais para sessão de cookies:

The main difference between these two modules is how they save cookie session data. The express-session middleware stores session data on the server; it only saves the session ID in the cookie itself, not session data. By default, it uses in-memory storage and is not designed for a production environment. In production, you’ll need to set up a scalable session-store; see the list of compatible session stores.

Em contrapartida, o middleware cookie-session implementa um armazenamento apoiado em cookies: ele serializa a sessão inteira para o cookie, ao invés de apenas a chave da sessão. Use apenas quando os dados da sessão são relativamente pequenos e facilmente codificados como números primitivos(ao invés de objetos). Only use it when session data is relatively small and easily encoded as primitive values (rather than objects). Apesar de navegadores supostamente suportarem pelo menos 4096 bytes por cookie, para assegurar que você não exceda o limite, não exceda um tamanho de 4093 bytes por domínio. Além disso, esteja ciente de que os dados do cookie serão visíveis para o cliente, portanto se houver razão para mantê-los seguros ou obscuros, então o express-session pode ser uma escolha melhor.

Usando o nome do cookie da sessão padrão pode deixar o seu aplicativo aberto a ataques. O problema de segurança levantado é parecido ao do X-Powered-By: um invasor em potencial poderia usá-lo para identificar o servidor e direcionar ataques de acordo com ele.

Para evitar este problema, use nomes de cookie genéricos; por exemplo usando o middleware express-session:

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

Configure as seguintes opções de cookie para aprimorar a segurança:

Aqui está um exemplo usando o middleware cookie-session:

const session = require('cookie-session')
const express = require('express')
const app = express()

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

Prevent brute-force attacks against authorization

Make sure login endpoints are protected to make private data more secure.

A simple and powerful technique is to block authorization attempts using two metrics:

  1. The number of consecutive failed attempts by the same user name and IP address.
  2. The number of failed attempts from an IP address over some long period of time. For example, block an IP address if it makes 100 failed attempts in one day.

rate-limiter-flexible package provides tools to make this technique easy and fast. You can find an example of brute-force protection in the documentation

Ensure your dependencies are secure

Using npm to manage your application’s dependencies is powerful and convenient. But the packages that you use may contain critical security vulnerabilities that could also affect your application. The security of your app is only as strong as the “weakest link” in your dependencies.

Since npm@6, npm automatically reviews every install request. Also, you can use npm audit to analyze your dependency tree.

$ npm audit

If you want to stay more secure, consider Snyk.

Snyk offers both a command-line tool and a Github integration that checks your application against Snyk’s open source vulnerability database for any known vulnerabilities in your dependencies. Install the CLI as follows:

$ npm install -g snyk
$ cd your-app

Use this command to test your application for vulnerabilities:

$ snyk test

Evitar outras vulnerabilidades conhecidas

Fique atento às recomendações do Node Security Project que podem afetar o Express ou outros módulos usados pelo seu aplicativo. Em geral, o Node Security Project é um excelente recurso para conhecimento e ferramentas sobre segurança do Node.

Finalmente, os aplicativos do Express - como outros aplicativos web - podem estar vulneráveis a uma variedade de ataques baseados na web. Familiarize-se com vulnerabilidades web conhecidas e tome precauções para evitá-las.

Considerações adicionais

Aqui estão algumas recomendações adicionais da excelente Lista de Verificação de Segurança do Node.js. Refira-se a esta postagem do blog para obter todos os detalhes destas recomendações:

Edit this page