Segurança em JavaScript

Como acontece com quase toda linguagem de programação, JavaScript também está sujeito a possíveis brechas de segurança. A exploração de vulnerabilidades em JavaScript pode permitir manipular dados, redirecionar sessões, modificar e roubar informações, entre outras ações. Embora JavaScript seja geralmente associado a aplicações do lado do cliente, problemas de segurança nessa linguagem também podem afetar ambientes do lado do servidor.

A melhor forma de se proteger contra vulnerabilidades comuns em JavaScript é conhecê-las e implementar os controles adequados para reduzir a exposição.

Neste artigo, vamos conhecer as vulnerabilidades mais comuns em JavaScript e como evitá-las com abordagens modernas de segurança e ferramentas de teste populares (por exemplo, ferramentas de auditoria e análise de código, scanner de vulnerabilidades para JavaScript etc.).

O que é segurança em JavaScript?

A segurança em JavaScript envolve investigar, prevenir, proteger contra e resolver problemas de segurança em aplicações que usam essa linguagem.

JavaScript é uma tecnologia fundamental para criar aplicações web e também é muito usada no desenvolvimento de aplicações para servidores, computadores e até dispositivos móveis. Sua popularidade, no entanto, também faz dela um alvo frequente de hackers, que exploram diferentes vetores de ataque. Como JavaScript é usada principalmente no front-end, faz sentido começar pelos problemas de segurança em JavaScript nos navegadores.

Os fornecedores de software também reconheceram esses problemas de segurança em JavaScript e responderam com softwares de verificação de segurança e diversas ferramentas de teste que tornam as aplicações mais seguras e reduzem consideravelmente os riscos. Experimente nosso verificador de código JavaScript para encontrar vulnerabilidades no seu código.

Quais são as vulnerabilidades mais comuns em JavaScript?

Entre os vetores de ataque mais comuns em JavaScript estão executar scripts maliciosos, roubar dados de uma sessão já estabelecida pelo usuário ou informações do localStorage do navegador, induzir usuários a realizar ações não intencionais e explorar vulnerabilidades no código-fonte de aplicações web.

É claro que esta lista não é completa; ela se concentra mais no aspecto de front-end das aplicações web.

8 vulnerabilidades de segurança em JavaScript

8 vulnerabilidades de segurança em JavaScript

1. Vulnerabilidades no código-fonte

Muitas vezes, vulnerabilidades no código-fonte se combinam com outras brechas de segurança em JavaScript — às vezes, várias delas. Infelizmente, nesses casos, usar apenas a ofuscação de JavaScript não é suficiente para evitar ou ocultar esse tipo de vulnerabilidade. Como JavaScript é uma linguagem interpretada, e não compilada, seria praticamente impossível proteger o código da aplicação contra a análise de possíveis hackers com esse método. Ainda assim, a ofuscação é uma boa prática, pois dificulta a engenharia reversa feita por hackers.

Outra causa de brechas de segurança no código-fonte é o uso generalizado de pacotes e bibliotecas públicos. O NPM, um dos principais participantes do ecossistema JavaScript, oferece mais de um milhão de pacotes em seu registro. Essa variedade é, sem dúvida, uma vantagem, mas também significa que pode haver um grande número de vulnerabilidades ocultas nesses pacotes instalados em projetos de aplicações web.

Além disso, muitas vezes os desenvolvedores instalam pacotes até para tarefas simples, aumentando as dependências do projeto. Isso pode, é claro, gerar problemas de segurança e outras consequências de longo alcance.

Monitorar e corrigir todas as possíveis vulnerabilidades nas dependências de uma aplicação pode exigir muito tempo e trabalho. As ferramentas de auditoria ajudam a automatizar e, assim, agilizar esse processo.

Uma abordagem abrangente para prevenir problemas de segurança em JavaScript no código-fonte deve incluir:

• Aumentar a conscientização dos desenvolvedores sobre as boas práticas

• Auditar adequadamente o código da aplicação para detectar possíveis vulnerabilidades

• Escrever testes unitários não apenas para garantir que o código funcione como esperado, mas também que seja executado com segurança

• Implementar ferramentas para analisar aplicações dinamicamente e identificar problemas de segurança em JavaScript em pacotes e bibliotecas de terceiros

2. Execução não intencional de scripts

A maioria dos ataques que envolvem a execução não intencional de scripts usa cross-site scripting (XSS). Uma preocupação específica em JavaScript é a forma como ela interage com o Document Object Model (DOM) de uma página web, permitindo que scripts sejam inseridos e executados nos computadores dos clientes pela web. Portanto, embora existam vários tipos de ataques XSS, todos têm em comum o fato de fazer um script não confiável aparecer e ser executado no navegador do usuário.

Um dos cenários mais básicos de ataque XSS é comum em fóruns, onde os usuários podem ver as mensagens uns dos outros na página. Se o HTML ou o JavaScript de uma mensagem não for codificado corretamente, usuários mal-intencionados poderão publicar um script no fórum.

Ao publicar esse script, o invasor transforma cada usuário final em uma vítima que, sem querer, facilita o ataque ao simplesmente executar a aplicação. O código malicioso aparece como se fizesse parte da página web.

Para prevenir ataques XSS, os desenvolvedores devem sanitizar os dados — combinando escape, filtragem e validação de strings — ao processar dados enviados pelo usuário e dados recebidos do servidor.

3. Escape e codificação de dados inseridos pelo usuário

Os ataques XSS dependem do envio de dados com determinados caracteres especiais usados no HTML, no JavaScript ou no CSS de uma página web. Quando o navegador renderiza a página e encontra esses caracteres, ele os interpreta como parte do código da página, em vez de exibi-los como valores. Isso permite que o invasor saia de um campo de texto e insira código adicional executado no navegador.

Para evitar isso, sempre que dados fornecidos pelo navegador forem incluídos em uma resposta — seja imediatamente ou após serem recuperados de um banco de dados —, esses caracteres especiais devem ser substituídos por códigos de escape correspondentes.

Por exemplo, os caracteres < e >, usados para delimitar entidades HTML, podem ser substituídos por < e >. Assim, o navegador exibe esses caracteres em vez de interpretá-los como entidades HTML. Se os dados fornecidos pelo navegador forem inseridos em um contexto JavaScript, os caracteres não alfanuméricos devem ser escapados usando xNN, em que NN é o valor hexadecimal ASCII do caractere.

4. Filtragem de dados de entrada

Em alguns casos, pode ser melhor simplesmente remover os caracteres perigosos dos dados recebidos. Isso oferece certo nível de proteção, mas não deve ser a única medida para evitar a manipulação de dados. Há várias técnicas que os invasores podem usar para contornar esses filtros.

5. Validação de dados de entrada

Sempre que possível, os dados de entrada fornecidos pelo navegador devem ser validados para garantir que contenham apenas os caracteres esperados. Por exemplo, campos de número de telefone devem aceitar apenas números e, talvez, hífens ou parênteses. Dados de entrada com caracteres fora do conjunto esperado devem ser rejeitados imediatamente. Configure os filtros para aceitar os caracteres válidos e rejeitar todos os demais.

6. Confiar apenas na validação do lado do cliente

Embora todos os métodos mencionados acima sejam eficazes nos navegadores, hackers podem usar ferramentas especiais para enviar dados diretamente ao servidor, contornando as validações do lado do cliente. Isso permitiria enviar ao servidor dados potencialmente maliciosos ou não verificados. Sem validação adicional do lado do servidor, os dados armazenados poderiam ser corrompidos ou substituídos por informações incorretas.

A boa prática recomendada para prevenir esse tipo de situação é implementar a validação tanto no lado do cliente quanto no lado do servidor. Essa abordagem reduz o risco de dados incorretos e mantém as validações no cliente, que melhoram a experiência do usuário final.

Validar apenas no servidor pode ser inconveniente para o usuário, pois talvez seja necessário preencher formulários online várias vezes até que todas as validações sejam aprovadas. A validação em JavaScript deve informar o usuário imediatamente sobre problemas nos dados inseridos, enquanto a validação no servidor garante que apenas os dados esperados cheguem à aplicação.

7. Roubo de dados da sessão

Scripts executados no navegador do cliente podem ser muito poderosos, pois têm acesso a todo o conteúdo que uma aplicação web envia ao navegador. Isso inclui cookies que podem conter dados confidenciais, como IDs de sessão do usuário. Na verdade, um tipo comum de exploração de ataques XSS é enviar os tokens de ID da sessão do usuário ao invasor, permitindo que ele sequestre a sessão.

Para evitar isso, a maioria dos navegadores já oferece suporte ao atributo Http-Only em cookies. Quando o servidor define um cookie no navegador, o atributo Http-Only impede que o DOM acesse esse cookie. Isso evita que ataques baseados em scripts do lado do cliente acessem os dados confidenciais armazenados nesses cookies.

Também é possível roubar dados do armazenamento local e de sessão do navegador dessa maneira, mas não é possível protegê-los por meio do acesso ao DOM. Portanto, é melhor evitar armazenar informações confidenciais, como tokens, no armazenamento do navegador, a menos que isso seja necessário por causa de recursos específicos da arquitetura da aplicação web.

8. Induzir usuários a realizar ações não intencionais

Ataques de cross-site request forgery (CSRF) tentam induzir o navegador a executar solicitações maliciosas em sites nos quais o usuário já está conectado, mesmo que o site não esteja aberto naquele momento. Se as sessões do site-alvo forem baseadas em cookies, as solicitações para esse site poderão receber automaticamente os cookies de autorização.

Hackers também podem criar páginas web que fazem solicitações maliciosas a outros sites em segundo plano quando o usuário as abre. Eles também podem usar redes sociais, fóruns e outras plataformas para publicar links ou conteúdos maliciosos que fazem os navegadores chamar outros sites sem que o usuário perceba, usando os cookies da sessão.

A técnica geral para evitar essa vulnerabilidade é implementar tokens na comunicação entre cliente e servidor. Um token adicional, que não fica armazenado em cookies, é incluído na comunicação. Os tokens devem ser gerados para cada formulário do site durante o estabelecimento da sessão e enviados junto com cada solicitação enquanto o usuário estiver no site.

Como lidar com problemas de segurança em JavaScript?

É possível proteger aplicações e servidores contra vulnerabilidades em JavaScript adotando boas práticas de segurança em JavaScript e usando sofisticadas ferramentas de análise.

No desenvolvimento web, os engenheiros de software precisam estar sempre atentos aos novos riscos de segurança em JavaScript. Testar a funcionalidade das aplicações é importante, mas também é essencial usar ferramentas de teste de segurança em JavaScript regularmente para prevenir vulnerabilidades. Por fim, seguir algumas boas práticas simples e conhecidas certamente aumenta a resiliência das aplicações.

As boas práticas de segurança em JavaScript a seguir podem reduzir esse risco.

• Evite**eval()**: não use esse comando no código, pois ele simplesmente executa o argumento recebido se ele for uma expressão JavaScript. Isso significa que, se o hacker conseguir manipular o valor de entrada, poderá executar qualquer script que quiser. Em vez disso, opte por alternativas mais seguras.

• Criptografe: use HTTPS/SSL para criptografar os dados trocados entre o cliente e o servidor.

• Configure cookies seguros: para garantir o uso de SSL/HTTPS, marque seus cookies como “secure”. Assim, eles só poderão ser usados em páginas web seguras.

• Configure chaves de acesso à API: atribua tokens individuais a cada usuário final. Se os tokens não corresponderem, o acesso poderá ser negado ou revogado.

• Use métodos seguros de manipulação do DOM: métodos como innerHTML são poderosos e potencialmente perigosos, pois não limitam, escapam nem codificam os valores passados a eles. Usar um método como innerText, por outro lado, garante por padrão o escape de conteúdo potencialmente perigoso. Isso é especialmente útil para evitar ataques XSS baseados no DOM.

Identificar possíveis problemas de segurança em JavaScript é um primeiro passo essencial para evitar vulnerabilidades no desenvolvimento de aplicações. Teste seu código com um scanner de vulnerabilidades de código aberto.