VOLTAR
É preciso admitir que, em termos das bibliotecas Javascript mais populares, na sua história de desenvolvimento (9, 6 e 5 anos para Angular, React e Vue, respetivamente), muitas coisas boas aconteceram em termos de segurança, especialmente relacionadas com a vulnerabilidade a ataques XSS. No entanto, este artigo abordará as pequenas armadilhas e os princípios a que os programadores ainda devem estar atentos.
Vivemos na era das frameworks, não das linguagens. Isto implica que os programadores devem poder preocupar-se menos com muitos aspectos do desenvolvimento, incluindo a segurança. A maioria das actuais estruturas de backend implementa módulos de segurança, que estão a ser testados por empresas externas especializadas e grandes sociedades. Por conseguinte, diminuição da sensibilização para a segurança pode ser evidente, por exemplo, entre os jovens programadores, que assumem mais responsabilidade pelos produtos, especialmente em termos de freelancing.
Um dos ataques comuns ao lado do cliente da aplicação é o XSS (Cross-Site Scripting). Este ataque é realizado através da injeção de scripts executáveis do lado do cliente em aplicações Web [1] e utiliza métodos de renderização HTML implementados ou Javascript código avaliadores que o executam. O XSS é relativamente lucrativo, uma vez que podem ser recolhidos muitos dados diferentes, incluindo cookies de sessão ou dados do utilizador, e pode instalar uma aplicação de rastreio, como um keylogger, o que o torna perigoso tanto para os utilizadores como para os proprietários de empresas. Por vezes, são efectuadas outras formas de ataque para permitir o XSS na página, tais como Injeção de SQL.
O formulário de início de sessão na página apresenta o parâmetro loginName enviado no pedido GET na introdução do nome de início de sessão. O valor não é processado nem pelo servidor nem pelo lado do cliente da aplicação. Ao solicitar: http://localhost:8080/login?name=<script>alert(document.cookies)</script>
o código está a ser executado e os dados estão expostos
Este é um exemplo de um ataque XSS refletidoem que os scripts são injectados através de um endereço URL especialmente preparado apresentado à vítima e refletido na resposta do servidor. Outras formas conhecidas de ataques populares são as seguintes:
Para as versões actuais React/Vue, foram detectados dois grandes problemas que ainda não foram oficialmente corrigidos. A primeira vulnerabilidade tem a mesma natureza para todas as estruturas e está relacionada com os métodos que permitem a renderização de HTML em bruto nos modelos: v-html e perigosamenteSetInnerHTML, respetivamente, para Vue e React. Cada documentação [2] informa os leitores de que uma utilização imprudente pode expor os utilizadores a um ataque XSS. Se não existirem outras opções para resolver o problema, certifique-se de que os dados são filtrada e escapado. Embora sejam perigosos, não se deve esperar que esses métodos sejam corrigidos. Utilize-os por sua própria conta e risco.
No primeiro trimestre de 2018, foi detectado um grande erro no React, que permitia a execução direta de código através da definição da propriedade do elemento da etiqueta. Passar código de exemplo dentro de atributos, como javascript:alert(1) e a execução de um link renderizado executará o código. Este problema [4] ainda está em aberto e nenhuma correção foi preparada e combinada, por isso certifique-se de que o seu código é seguro. Os exemplos propostos na discussão oficial sugerem algumas formas de ultrapassar este problema.
Se não for possível atualizar para as versões mais recentes, certifique-se de que os problemas antigos não lhe causam problemas, garantindo que o seu código não está exposto:
Não se esqueça que, para além das próprias estruturas ou bibliotecas, o Javascript, enquanto linguagem, tem algumas funções perigosas, que devem ser evitadas ou utilizadas com precaução. Estas funções estão geralmente relacionadas com a manipulação do DOM ou com a execução de scripts. eval() representa funções emblemáticas deste tipo e é extremamente perigosa porque executa diretamente um determinado código em cadeia [9]. Além disso, dê uma vista de olhos ao seu código quando encontrar uma destas funções:
Neste caso, a utilização de linters com um conjunto de regras adequado pode ser útil para encontrar esses pontos vulneráveis. Existem também muitos analisadores de código abertos ou comerciais que podem ajudá-lo a detetar falhas de segurança no código desenvolvido.
Independentemente da biblioteca/framework escolhida, temos de nos lembrar dos princípios básicos relacionados com o desenvolvimento front-end. Em primeiro lugar, certifique-se sempre de que o código externo que injecta provém de uma fonte fidedigna. Auditoria suas dependências e escolha-as com sabedoria. Algumas podem conter vulnerabilidades graves, expondo o seu código mesmo que tudo esteja bem com o próprio código. Pode ler mais sobre a segurança das dependências aqui:
https://thecodest.co/blog/security-in-javascript-packages/
Então... ainda se deve preocupar?
Sim - e encorajo vivamente toda a gente a nunca confiar em bibliotecas externas ou em si próprio em termos de segurança. Não importa o quão seguro espera que o seu software seja, faça sempre um esforço para o testar tanto quanto possível em termos de formas de ataque comuns [10].
Ler mais:
5 erros que devem ser evitados na manutenção de um projeto em PHP
Desenvolvimento PHP. Componente de Consola Symfony - Dicas e Truques
Porque é que precisamos do Symfony Polyfill (... e porque é que não devemos)
Portuguese 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Japanese 
Spanish 
Dutch 
Estonian 
Greek 
Czech