Angular vs. React: o risco de segurança das dependências indiretas

Escrito por

30 de outubro de 2019

0 minutos de leitura

Boas-vindas ao relatório da Snyk sobre o estado da segurança dos frameworks JavaScript em 2019.

Nesta seção, analisamos o risco de segurança das dependências indiretas de Angular e React e, em seguida, as dependências diretas, primeiro do Angular e depois do React.

Baixe o relatório aqui!

Os módulos analisados nesta parte não representam uma lista completa de módulos vulneráveis de React e Angular; alguns módulos podem seguir convenções especiais de nomenclatura (como todos os módulos com prefixo ng-, angular- ou react-, por exemplo) e, por isso, não apareceriam na busca baseada em padrões que realizamos.

O risco de segurança das dependências indiretas

Na maioria das vezes, projetos baseados em React ou Angular são gerados com uma ferramenta de scaffolding que fornece um modelo inicial para começar o desenvolvimento. Em React, a prática mais comum entre desenvolvedores é usar o pacote npm create-react-app, que cria um ponto de partida de projeto pré-configurado, incluindo, por exemplo, o framework de testes Jest, processadores de CSS e outras ferramentas integradas. Em Angular, isso é possível graças ao pacote npm @angular/cli.

Para comparar a integridade das dependências e o estado da segurança (que refletem o nível geral de risco) dos modelos iniciais de React e Angular, geramos um projeto de amostra e obtivemos uma boa notícia: ambos incluem dependências de desenvolvimento com vulnerabilidades, mas nenhum apresenta problemas de segurança em dependências de produção.

Estas são as vulnerabilidades de segurança que já chegam ao seu código quando você inicia um projeto usando o modelo inicial do Angular ou do React:

Modelo inicial	Módulo vulnerável	Vulnerabilidade indireta	Gravidade da vulnerabilidade indireta	Downloads anuais do módulo	Há correção?
Angular	jasmine-core	ReDoS	baixa	94,559,055	✅
Angular	useragent	ReDoS	alta	70,181,373	❌
React	lodash	Poluição de protótipo	alta	1,005,518,049	✅
React	mdn-data	Problema com a licença MPL-2.0	alta	89,291,454	❌
React	mixin-deep	Poluição de protótipo	alta	328,052,052	✅
React	set-value	Poluição de protótipo	alta	629,781,760	✅

Vale observar que o Angular depende de 952 dependências, que contêm duas vulnerabilidades no total; o React depende de 1.257 dependências, com três vulnerabilidades e um possível problema de compatibilidade de licença.

Uma observação sobre licenças de software de código aberto

Em relação ao licenciamento, consideramos a conformidade com as licenças um fator importante para a integridade geral das dependências, além dos problemas de segurança. Por isso, também incluímos verificações de licença nas nossas análises. Os resultados obtidos se baseiam nas configurações padrão definidas para nossas políticas de licença antes da análise.

Com base nesses resultados, vemos que o projeto React gerado depende do pacote mdn-data, que, por sua vez, usa a licença copyleft MPL-2.0 da Mozilla. Se você pretende distribuir sua aplicação React em instalações locais ou em configurações semelhantes que incluam a dependência mdn-data, verifique os requisitos de licenciamento para garantir que seu projeto esteja em conformidade.

Além disso, recomendamos que você analise seus projetos de acordo com as orientações das políticas específicas da sua organização, que podem ou não sinalizar outras dependências indiretas do React.

Corrigindo caminhos vulneráveis

Um caminho descreve como uma dependência de código aberto é introduzida no seu projeto. Por exemplo, imagine que você tenha duas dependências diretas chamadas Projeto A e Projeto B. Ambas introduzem uma dependência, o Projeto C. O Projeto C passa a estar associado a dois caminhos diferentes, pois é instalado tanto pelo Projeto A quanto pelo Projeto B. Se o Projeto C tiver vulnerabilidades, o desenvolvedor precisará considerar os dois caminhos para corrigi-las.

No React, as três vulnerabilidades se distribuem por 16.293 caminhos vulneráveis. Corrigi-las por meio de atualizações de pacotes se torna uma tarefa difícil, pois muitos pacotes na cadeia de dependências precisam ser atualizados. Em contrapartida, as duas vulnerabilidades do Angular são corrigidas facilmente por apenas dois caminhos vulneráveis.

A imagem a seguir foi extraída de um relatório de análise de segurança de agosto de 2019 de um projeto gerado com o pacote npm create-react-app do React. O relatório revela o problema na cadeia de dependências que precisa ser resolvido para uma única vulnerabilidade de segurança.

Relatório do Snyk Test mostrando uma vulnerabilidade de alta gravidade de poluição de protótipo na dependência npm lodash

Para corrigir a vulnerabilidade, é preciso obter novas versões do lodash de cada um dos pacotes afetados em toda a cadeia de dependências.

Devido ao uso disseminado do lodash em todo o ecossistema, sua versão vulnerável acaba sendo usada em milhares de caminhos de dependência.

Vulnerabilidades no ecossistema de módulos do Angular

No ecossistema Angular, as vulnerabilidades em módulos se manifestam em três áreas:

Módulos do ecossistema Angular
Versões maliciosas de módulos
Ferramentas de desenvolvimento. Ao analisar o ecossistema de módulos do Angular, vemos que os seguintes módulos se destacam pelo número de downloads e pelas vulnerabilidades associadas:

Nome do módulo	Tipo de vulnerabilidade	Número de vulnerabilidades	Gravidade da vulnerabilidade	Downloads anuais do módulo	Há correção?
ngx-bootstrap	Cross-Site Scripting (XSS)	1	média	6,275,854	❌
ag-grid-community	Cross-Site Scripting (XSS)	1	média	2,710,764	✅
ag-grid	Cross-Site Scripting (XSS)	3	média	2,203,913	✅
ng-dialog	Negação de serviço (DoS)	1	média	580,674	❌
angular-gettext	Cross-Site Scripting (XSS)	1	média	514,937	✅
angular-jwt	Desvio de restrição de acesso	1	média	514,470	✅
textangular	Cross-Site Scripting (XSS)	2	média	104,436	✅
angular-froala	Cross-Site Scripting (XSS)	1	média	104,436	❌
angular-redactor	Cross-Site Scripting (XSS)	1	média	64,094	✅
i18n-node-angular	Negação de serviço (DoS)	1	alta	4229	✅

Quando organizamos os tipos de vulnerabilidade de acordo com o número de downloads dos módulos que as contêm, fica claro que as vulnerabilidades XSS aparecem no topo do gráfico, como também indica o OWASP Top 10 riscos de segurança na web que você deve conhecer:

Gráfico de rosca mostrando a distribuição das vulnerabilidades por número de downloads do módulo: cross-site scripting, 92%; bypass de restrição de acesso, 4%; e negação de serviço, 4%.

Módulos maliciosos do Angular

No total, identificamos três versões maliciosas publicadas para os seguintes módulos do Angular: angular-bmap, ng-ui-library, ngx-pica.

O angular-bmap talvez seja o menos interessante, como se pode observar na sua página de integridade das dependências: ele tem oito versões publicadas, todas de setembro de 2017. Ainda assim, foi publicada a versão 0.0.9 do angular-bmap, que contém código malicioso capaz de exfiltrar informações confidenciais sobre senhas e cartões de crédito de formulários e enviá-las para a URL controlada pelo invasor https://js-metrics.com/minjs.php?pl=. Essa versão maliciosa 0.0.9 foi removida do registro npm.

Ao contrário do módulo Angular bmap, o ng-ui-library continua sendo mantido e tem mais de 150 versões publicadas, sete delas somente em 2019. No entanto, descobriu-se que a versão 1.0.987 do ng-ui-library contém o mesmo código malicioso encontrado no angular-bmap. O ng-ui-library ainda recebe entre 400 e 3.000 downloads por mês.

Juntando-se ao código malicioso que coleta informações de cartões de crédito está uma versão maliciosa do ngx-pica, um módulo compatível com Angular v5 e Angular v7 para redimensionar imagens no navegador, com cerca de 800 downloads mensais.

Curiosamente, todas essas versões maliciosas só foram encontradas recentemente. A divulgação de todas ocorreu em junho de 2019, embora o código malicioso tivesse sido incluído em uma versão lançada um mês antes.

Ferramentas de desenvolvimento do Angular

Entre as descobertas sobre o ecossistema de módulos, identificamos um módulo usado como servidor HTTP de uso geral para disponibilizar recursos de aplicações de página única em projetos criados com Angular, React, Vue e outros.

O módulo angular-http-server foi identificado como vulnerável a traversal de diretório — duas vezes. As duas versões vulneráveis têm um ano, e já foram publicadas cerca de meia dúzia de versões mais recentes. Embora o responsável pela manutenção do módulo deixe claro que não recomenda usar essa ferramenta como serviço pronto para produção, o número de downloads aumentou este ano, chegando a 20.670 em maio de 2019.

Com a crescente adoção dessa ferramenta de desenvolvimento, o servidor HTTP do Angular, vale destacar que há uma exploração pública para essa vulnerabilidade.

Vulnerabilidades no ecossistema de módulos do React

Assim como no Angular, descobrimos que o ecossistema React inclui vários módulos maliciosos publicados em algum momento. A seguir, mostramos a distribuição dos tipos de vulnerabilidade e suas quantidades em todos os módulos vulneráveis que identificamos, com destaque para quatro pacotes maliciosos: react-datepicker- plus, react-dates-sc, awesome_react_utility, react- server-native.

Os quatro módulos maliciosos contêm o mesmo código nocivo, que coleta informações de cartões de crédito e outros dados confidenciais. Esse ataque também comprometeu módulos do ecossistema React.

Isso reforça que, para quem mantém um projeto de código aberto, é essencial habilitar a autenticação multifator, como o suporte a 2FA oferecido pelo registro de pacotes npm, para evitar expor os usuários ao risco de alguém comprometer sua conta e publicar versões maliciosas do pacote.

Gráfico de barras que mostra os tipos de vulnerabilidade nos módulos do ecossistema React, com destaque para cross-site scripting, com 5 ocorrências, e pacotes maliciosos, com 4.

Se ainda não fez isso, recomendamos que você habilite a 2FA na sua conta de desenvolvedor do npmjs.org e siga outras práticas recomendadas de segurança do npm.

Módulos vulneráveis de destaque que identificamos no ecossistema React:

Uma vulnerabilidade XSS de alta gravidade no react-marked-markdown, sem correção disponível. Ainda assim, esse wrapper de componente React para a biblioteca JavaScript Markdown marked continua recebendo milhares de downloads: foram 65.790 nos últimos 12 meses.
Para quem usa preact, a biblioteca preact-render-to-string é vulnerável a Cross-Site Scripting em todas as versões anteriores à 3.7.2. O uso dessa biblioteca aumentou nos últimos 12 meses, período em que ela somou 3.228.049 downloads.
Se você usa dicas de ferramentas na aplicação React de front-end, talvez também use o react-tooltip, que chegou perto de um milhão de downloads (994.903) somente em julho de 2019. No entanto, essa biblioteca é vulnerável a ataques de Cross-Site Scripting em todas as versões anteriores à 3.8.1, conforme divulgado em setembro de 2018.
Se você trabalha bastante com SVGs, é bem provável que use o react-svg, que teve 1.446.442 downloads nos últimos 12 meses. Em abril de 2018, o pesquisador de segurança Ron Perris divulgou uma vulnerabilidade de Cross-Site Scripting de alta gravidade que afetava todas as versões anteriores à 2.2.18.
Uma vulnerabilidade de injeção de CSV no mui-datatables foi divulgada em março de 2019. Essa biblioteca React oferece um componente de interface para dados tabulares baseado no framework Material UI e teve mais de 350.000 downloads nos últimos 12 meses.

Ao acompanhar todos os módulos vulneráveis de React que identificamos, contabilizamos oito vulnerabilidades de segurança nos últimos três anos: duas em 2017, seis em 2018 e duas até agosto de 2019. Isso reforça a importância de usar código aberto com responsabilidade e identificar e corrigir vulnerabilidades o mais rápido possível.

Em destaque: vulnerabilidades de segurança do Next.js

Next.js é o popular framework React desenvolvido pela ZEIT, que permite aos desenvolvedores web aproveitar seus conhecimentos de React para criar aplicações web otimizadas para SEO, aplicações com renderização no servidor, Progressive Web Apps (PWA) e até aplicações baseadas em Electron, todas usando o framework Next.js.

O Next.js continua conquistando a preferência dos desenvolvedores, com 8.414.925 downloads nos últimos 12 meses. À medida que o projeto cresce, é cada vez mais importante analisar sua situação de segurança.

Ao longo de 2017 e 2018, identificamos três vulnerabilidades graves de Directory Traversal e duas vulnerabilidades de gravidade média de Cross-Site Scripting que afetaram o framework React Next.js. Também vale destacar que a equipe de segurança da ZEIT corrigiu rapidamente as cinco vulnerabilidades e disponibilizou uma atualização para o framework Next.js em menos de uma semana.

De modo geral, a ZEIT adota boas práticas de segurança que outros projetos de código aberto deveriam seguir. Entre os destaques estão:

A equipe responde rapidamente às divulgações de vulnerabilidades, lançando correções de segurança em tempo hábil. Isso reduz o período em que há um risco real de segurança; a ZEIT também disponibiliza uma atualização para que os usuários possam corrigir rapidamente a vulnerabilidade.
Para evitar regressões de segurança, a equipe criou testes unitários de segurança para garantir que os mesmos erros não se repitam.
As notas de versão comunicam com clareza as informações relacionadas à segurança, seus impactos e as etapas que os usuários precisam seguir para manter os sistemas atualizados com as correções de segurança.
O projeto mantém uma lista de e-mails dedicada a relatos de problemas de segurança, uma política de divulgação responsável e um endereço de e-mail exclusivo para o envio de relatos.

A ZEIT e a forma como gerencia o framework Next.js são um ótimo exemplo de boas políticas de segurança para projetos de código aberto. A ZEIT leva o assunto a sério e demonstra um compromisso genuíno com a segurança dos usuários, com políticas e ações que outros projetos deveriam adotar.