Segurança em NodeJS

317 views
Skip to first unread message

Fabiano Chiaretto

unread,
May 25, 2016, 1:25:36 AM5/25/16
to Node.js Brasil
Quero levantar um debate sobre segurança em aplicações NodeJs.

Sou novo em node e não encontrei nada relacionado em português.

O que venho pensando ultimamente é o quão seguro é deixar o usuário e senha do banco dentro de um app.js por exemplo ?

Será que é impossível "baixar" ou ver o fonte desse arquivo, assim como o apache trabalha com o php ?

Ricardo Othuki

unread,
May 25, 2016, 4:57:13 AM5/25/16
to nod...@googlegroups.com
minha sugestão é que trabalhe com SPA e webService (ou microService). Com estas tecnologias é possível deixar toda a lógica do aplicativo no lado server e apenas as regras de apresentação no browser.



--
Você recebeu essa mensagem porque está inscrito no grupo "Node.js Brasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para nodebr+un...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

principe...@gmail.com

unread,
May 25, 2016, 5:28:43 AM5/25/16
to nod...@googlegroups.com

Acredito que nao pois no caso do nodejs o app.js fica no lado do servidor como php e so o q eh prpcessado e renderizado como html vai para a tela. Sim ainda ha o js do lado do cliente.  Mas nesse caso o envio dele para o navegador eh diferente.

Ian Garcez

unread,
May 26, 2016, 12:55:53 PM5/26/16
to Node.js Brasil
Só complementando o que o amigo Igor falou, o javascript que existe no lado do cliente é o mesmo que existe em qualquer site, é javascript especifico para rodar no cliente.

Os arquivos do aplicativo node não ficam disponíveis para acesso, apenas se for explicitamente disponibilizado em uma pasta configurada para ser rota de arquivos estáticos.

Jhosef Marks

unread,
May 26, 2016, 5:31:45 PM5/26/16
to nod...@googlegroups.com

Mais um ponto que deve ser levado em consideração,  você não deve deixar a senha no arquivo,  não importa a tecnologia. Você pode deixar essa informação como uma variável de ambiente.

Abel Neto

unread,
May 26, 2016, 6:07:31 PM5/26/16
to nod...@googlegroups.com
Bem observado, Jhosef. Achei que tinha respondido essa thread, mas acho que esqueci :P

O que ia comentar é que manter senhas e informações críticas em código pode ter inúmeras implicações de segurança. Por exemplo, essa base de código pode estar em um repositório público, ou um estagiário pode zipar todo o código e deixar o arquivo na raiz do site, como já vi acontecer (e tinha todas as senhas de bancos de dados e outros serviços lá!). Além disso, a base é compartilhada por toda a equipe que trabalha no projeto, então todas essas pessoas têm acesso a essas informações (e funcionários saem das empresas - às vezes muito putos com elas :P). Com variáveis de ambiente, por exemplo, você permite que todos utilizem a senha quando necessário mas sem necessariamente conhecê-la :)

Quanto a "baixar" o fonte, só se for através de um repositório ou como no exemplo do estagiário que citei... O que acontece no lado servidor fica no lado servidor. O código javascript, no seu caso o app.js, é interpretado no server e não tem contato nenhum com os clients. A comunicação entre as partes se dá, por exemplo, através de requisições HTTP, que no seu exemplo poderiam ser atendidas por um servidor express, no próprio app.js. O que esse servidor faria seria apenas escutar uma requisição HTTP, executar algum processamento e enviar uma resposta (que poderia ser uma view renderizada, um objeto JSON...). O arquivo app.js não é "baixado" para ser executado no client, como acontece no javascript client-side. Na verdade ele nem existe pra clients HTTP, pois não está publicado em lugar nenhum, afinal, nesse caso, ele próprio é quem define quais arquivos serão servidos.

principe...@gmail.com

unread,
May 26, 2016, 6:36:31 PM5/26/16
to nod...@googlegroups.com
Com variáveis de ambiente, por exemplo, você permite que todos utilizem a senha quando necessário mas sem necessariamente conhecê-la :)

exatamente, eu mantenho 3 bases de dados diferentes:1 pra dev, um pra teste e outro pra producao, cada um tem uma senha diferente, e cada um tem sua senha armazenada especificamente no ambiente. Ate mesmo quando o codigo sobe para o servidor de teste, ele ja entra com a senha da base de la, eu nao tenho q trocar a senha..

Fabiano Chiaretto

unread,
May 28, 2016, 4:14:32 PM5/28/16
to Node.js Brasil
Achei interessante essa ideia de deixar em uma variável de ambiente, em vez de usar o um arquivo de config.
Dá para usar essa ideia até para outras linguagens como php, por exemplo.

Obrigado a todos pelas respostas.

principe...@gmail.com

unread,
May 28, 2016, 4:32:07 PM5/28/16
to nod...@googlegroups.com
Sim, eu faço isso com php...eu geralmente seto no config do apache.

--

Diego Nascimento

unread,
May 29, 2016, 12:59:16 AM5/29/16
to nod...@googlegroups.com
a regra geral de segurança é senha sempre criptografada, e na base de
dados, nunca senha tem que estar em arquivo plano, quando eu
trabalhava como sysadmin eu usava gerenciadores de senhas
criptografados, caso alguém copiasse todos os dados do meu PC, mesmo
assim não acharia nenhuma senha dos meus servidores. Senha que circula
na rede tbm sempre criptografada, já implementei serviços de EAD (de
terceiros) no servidor e quando dava um sniffer na rede acabava
pegando todos usuários (e-mail) com senha, o que é uma falha
extremamente grave e não se deve permitir em nenhum tipo de
aplicativo, seja web ou não.

Em 28 de maio de 2016 17:32, principe...@gmail.com
<principe...@gmail.com> escreveu:

Alain Mouette

unread,
May 29, 2016, 12:43:35 PM5/29/16
to nod...@googlegroups.com
Na verdade isto não está correto.

1) Não se guarda senhas criptografadas, deve-se guardar o HASH delas, a opção moderna seria SHA256

2) Senha só deve ser enviada via uma conexão segura (HTTPS), assim sniffers simplesmente não existem. Para alta segurança você pode usar Pinning e evitar um MITM ou Oauth...

3) criptografar senha não cliente não aumenta a segurança, um sniffer pode simplesmente olhar o código que você usou para criptografar e fazer o mesmo ou até o inverso.

Regra de ouro da segurança: não invente! Nem os maiores experts conseguem prever todas as consequências de um método novo, use sempre métodos consagrados.

Alain Mouette
=== Projetos especiais: <http://lnkd.in/dEu8cNq> ===

Diego Nascimento

unread,
May 29, 2016, 1:14:23 PM5/29/16
to nod...@googlegroups.com
não entendi o que quis dizer com incorreto no que eu falei.

falei senhas salvas no PC.. senhas de servidores, serviços e tal,
senha forte e sempre criptografada e não em texto plano, é correto
isso.. quando for em banco de dados, como de um CMS, ou serviço, sim
se guarda o hash dela, que é uma opção que linguagens e que o próprio
banco de dados oferece, mas senhas como de e-mails, login em serviços
e outras, que vc precisa ter de forma plana, se guarda em arquivo
criptografado, em disco criptografado com swap criptografada, para que
caso alguém roube teu pc, não consiga acessar nenhum arquivo contendo
a senha plana para ter acesso aos teus serviços, como amazon, ssh..
essas coisas, está correto.

senha transitar pela rede criptografada se faz com 'ssl', 'ipsec' ,
'ssh' e tanto outros.. tbm não está errado, não quis dizer em enviar a
senha criptografada, mas é óbvio, enviar por um protocolo
criptografado.

o 3 eu não entendi aonde ficou tua crítica.








Em 29 de maio de 2016 13:43, Alain Mouette
<ala...@bonseletrons.com.br> escreveu:

Alain Mouette

unread,
May 29, 2016, 2:48:01 PM5/29/16
to nod...@googlegroups.com
Bom, parece que eu interpretei errado o que você falou.
Veja pelo lado bom... outros podem ter feito a mesma interpretação ;-)

Respostas abaixo:


On 29-05-2016 14:14, Diego Nascimento wrote:
falei senhas salvas no PC.. senhas de servidores, serviços e tal,
senha forte e sempre criptografada e não em texto plano, é correto
isso..
Você está correto, aliás isso é uma encrenca... se a tua máquina for invadida/roubada fica muito difícil proteger as senhas JUNTO com a senha usada para criptografar. Colocar em variável de ambiente protege só contra algumas possibilidades, mas evita erros humanos e várias coisas mais simples.


 quando for em banco de dados, como de um CMS, ou serviço, sim
se guarda o hash dela, que é uma opção que linguagens e que o próprio
banco de dados oferece,
Ok !!!


mas senhas como de e-mails, login em serviços
e outras, que vc precisa ter de forma plana, se guarda em arquivo
criptografado, em disco criptografado com swap criptografada, para que
caso alguém roube teu pc, não consiga acessar nenhum arquivo contendo
a senha plana para ter acesso aos teus serviços, como amazon, ssh..
essas coisas, está correto.
O disco criptografado precisa ter a senha em algum lugar para montar automaticamente... esse se torna o ponto fraco.
A alternativa seria fornecer pessoalmente a senha a cada reboot, seguro mas vai demorar mais e incomodar bastante


senha transitar pela rede criptografada se faz com 'ssl', 'ipsec' ,
'ssh' e tanto outros.. tbm não está errado, não quis dizer em enviar a
senha criptografada, mas é óbvio, enviar por um protocolo
criptografado.
Aí sim :) :)


o 3 eu não entendi aonde ficou tua crítica.
Minha interpretação de tuas palavras seria algo que já vi fazerem: criptografa no cliente, e manda para o servidor. So com hardware de segurança pode ficar bom.
Mas parece que ou falha na comunicação/interpretação, hehe

Alain
Em 29 de maio de 2016 13:43, Alain Mouette
<ala...@bonseletrons.com.br> escreveu:
Na verdade isto não está correto.

1) Não se guarda senhas criptografadas, deve-se guardar o HASH delas, a
opção moderna seria SHA256

2) Senha só deve ser enviada via uma conexão segura (HTTPS), assim sniffers
simplesmente não existem. Para alta segurança você pode usar Pinning e
evitar um MITM ou Oauth...

3) criptografar senha no cliente não aumenta a segurança, um sniffer pode
simplesmente olhar o código que você usou para criptografar e fazer o mesmo
ou até o inverso.

Regra de ouro da segurança: não invente! Nem os maiores experts conseguem
prever todas as consequências de um método novo, use sempre métodos
consagrados.

Alain Mouette
=== Projetos especiais: <http://lnkd.in/dEu8cNq> ===

On 29-05-2016 01:59, Diego Nascimento wrote:

a regra geral de segurança é senha sempre criptografada, e na base de
dados, nunca  senha tem que estar em arquivo plano, quando eu
trabalhava como sysadmin eu usava gerenciadores de senhas
criptografados, caso alguém copiasse todos os dados do meu PC, mesmo
assim não acharia nenhuma senha dos meus servidores. Senha que circula
na rede tbm sempre criptografada, já implementei serviços de EAD (de
terceiros) no servidor e quando dava um sniffer na rede acabava
pegando todos usuários (e-mail) com senha, o que é uma falha
extremamente grave e não se deve permitir em nenhum tipo de
aplicativo, seja web ou não.

Em 28 de maio de 2016 17:32, principe...@gmail.com

principe...@gmail.com

unread,
May 29, 2016, 5:10:12 PM5/29/16
to nod...@googlegroups.com

Alain sobre sniffers eu ja vi gente usando determinado script em python com man in the middle para quebrar o ssl.

Fabiano Chiaretto

unread,
May 29, 2016, 5:14:15 PM5/29/16
to Node.js Brasil
Diego, como vou salvar a senha do banco criptografada ? Acho que vc quer dizer a senha de usuario do sistema né ?
Estou me referindo a senha de conexão com banco, ou senha de conexão com servidor de email smtp.



Em quarta-feira, 25 de maio de 2016 02:25:36 UTC-3, Fabiano Chiaretto escreveu:

Alain Mouette

unread,
May 29, 2016, 5:46:03 PM5/29/16
to nod...@googlegroups.com
On 29-05-2016 18:10, principe...@gmail.com wrote:

Alain sobre sniffers eu ja vi gente usando determinado script em python com man in the middle para quebrar o ssl.

O Man I The Middle pode fazer sniffer, mas tem uma proteção possível. Só que do jeito que o browser funciona, pode tanto proteger como pode trancar o teu usuário para fora!

Chama-se Html Public Key Pinning - HPKP. Fuunciona bem em aplicativos: você inclui a assinatura da tua PK (usada pra obter o Certificado) na aplicação, se tiver um MITM essa assinatura não vai bater. Recomenda-se ter uma backup já instalada e uma outra KeyPair no Servidor para poder trocar sem ter problemas. Também é fácil baixar outro App com a chave atualizada...

Para Browser fizeram mer*a... Na primeira vez que você entra no site ele memoriza a PK (por prazo que o servidor define), qualquer mudança subsequente da PK bloqueia o uso até o fim desse prazo. Funciona em termos e pode criar grandes problemas.

Alain

Diego Nascimento

unread,
May 30, 2016, 2:30:08 AM5/30/16
to nod...@googlegroups.com
senha se conexão com banco, senha de conexão com smtp.. etc. sim.

Diego Nascimento

unread,
May 30, 2016, 2:59:32 AM5/30/16
to nod...@googlegroups.com
em blocos criptografado.. se for para ter a senha no pc o ideal seria,
um gerenciador de senhas com dados criptografados, ou disco
criptografado com gpg, truecrypt.. ferramentas desse tipo.

Alain Mouette

unread,
May 30, 2016, 8:32:44 AM5/30/16
to nod...@googlegroups.com
E como você esconde a senha de acesso a esse aplicativo?


-----
Alain Mouette
> --
> Você está recebendo esta mensagem porque se inscreveu no grupo "Node.js
> Brasil" dos Grupos do Google.
> Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie
> um e-mail para nodebr+un...@googlegroups.com.
> Para obter mais opções, acesse https://groups.google.com/d/optout.



Fabiano Chiaretto

unread,
May 30, 2016, 8:40:16 AM5/30/16
to nod...@googlegroups.com

É como vcs usa a senha na hora de fazer a conexão?

--
Você recebeu esta mensagem porque está inscrito em um tópico do grupo "Node.js Brasil" dos Grupos do Google.
Para cancelar inscrição nesse tópico, acesse https://groups.google.com/d/topic/nodebr/f8_imdDOPHc/unsubscribe.
Para cancelar inscrição nesse grupo e todos os seus tópicos, envie um e-mail para nodebr+un...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages