Segurança no desenvolvimento front-end de aplicações web
A segurança é um aspeto fundamental para se ter em consideração quando se desenvolve qualquer tipo de aplicação. Este aspeto torna-se ainda mais importante quando vamos desenvolver uma aplicação que vai estar ao dispor de qualquer utilizador do mundo, uma vez que não sabemos as intenções de todos os utilizadores.
Uma falácia bastante comum é que os desenvolvedores associam que a segurança deve ser aplicada ao back-end, esquecendo-se desta forma da preocupação que devem ter em relação a segurança no front-end. Pode-se afirmar que a informação que é guardada no back-end é mais sensível do que a informação que é guardada no front-end, contudo, isto não é desculpa para não se aplicar medidas de segurança no front-end¹.
Não é ao acaso que na lista dos 10 ataques mais críticos de aplicações web de 2021 (OWASP Top 10 — https://owasp.org/www-project-top-ten/)², logo na terceira posição está a categoria de ataques Injection que é onde está inserido o ataque XSS (Cross-Site Scripting) que está diretamente relacionado com o front-end e iremos abordar mais à frente.
Neste artigo, vão ser apresentados os principais ataques informáticos realizados a aplicações web, e como é que nós, desenvolvedores, nos podemos prevenir que aconteçam.
XSS — Cross-Site Scripting
O ataque XSS baseia-se no atacante inserir código malicioso na aplicação web, e consequentemente, esse código é executado pelos utilizadores quando acedem a aplicação, permitindo ao atacante ter acesso a informações sensíveis das suas vítimas. Existem diversas variantes deste tipo de ataque, que podem ser exploradas³:
Persistent (Stored) XSS
Considerado o mais perigoso¹¹, este ataque acontece quando uma aplicação guarda um determinado valor de input, nos seus servidores, e apresenta esse valor na página para outros utilizadores. Caso este valor de input não seja propriamente verificado antes de ser guardado nos servidores, permite que seja injetado código na aplicação que vai ser executado por outros utilizadores.
Reflected XSS
Num ataque Reflected XSS, ao invés do código malicioso ser guardado persistente no servidor, é guardado “apenas” numa resposta HTTP, ou seja, não é executado por todos os utilizadores que acedem à aplicação, apenas é executado quando um utilizador acede à aplicação através de um determinado link previamente criado pelo atacante. Neste ataque, o servidor obtém um determinado valor recebido pelo atacante, que faz com que seja renderizada uma página que contenha código malicioso que irá ser executado pelo cliente. Este tipo de ataque é o mais comum do mundo.¹²
DOM Based XSS
Diversos estudos chegaram à conclusão que cerca de 50% dos sites são vulneráveis a este tipo de ataques.¹³ Neste ataque, o código malicioso é executado ao modificar o DOM do cliente, enquadrando-se nas aplicações onde o DOM é modificado dinamicamente. Para o atacante conseguir realizar este ataque, é necessário que o código javascript obtenha o valor de um input que pode ser controlado pelo atacante, como por exemplo através de um parâmetro do URL, em que neste caso, o atacante iria enviar um URL específico à sua vítima.
Ao contrário dos ataques de Stored e Reflected XSS que acontecem devido a vulnerabilidades presentes no front-end e back-end, este ataque acontece exclusivamente devido a vulnerabilidades no front-end.
Como prevenir:
- Filtrar todos os inputs ou parâmetros que são utilizados pela aplicação. Por exemplo, quando temos um input onde é suposto o utilizador escrever um número, o primeiro passo que devemos fazer é a verificação que o valor que o utilizador inseriu é efetivamente um número antes de prosseguir com o processamento.
- Utilizar métodos apropriados para alterar o conteúdo da página. Por exemplo, para alterar o conteúdo de uma div ao invés de utilizar o innerHTML, utilizar o innerText que faz filtragem do conteúdo.
CSRF — Cross-Site Request Forgery
CSRF trata-se de um ataque que força um utilizador a executar ações indesejadas numa aplicação onde estão autenticados. Exemplificando, assumindo que a nossa aplicação web tem um mecanismo de autenticação, e que um utilizador está autenticado, para todos os pedidos que esse utilizador realiza, vão ser colocados automaticamente pelo browser os cookies da sessão do utilizador, o endereço IP, etc. Posto isto, um atacante pode-nos enviar um endereço que assim que o acedermos, é realizado automaticamente um pedido para efetuar uma ação na nossa aplicação, pelo que o nosso back-end não vai conseguir distinguir os pedidos legítimos, dos pedidos maliciosos.
Como prevenir:
Para cada sessão do utilizador, o servidor gera um token (CSRF Token) e envia-o para o cliente. Este token trata-se de um valor único, secreto e imprevísivel para prevenir que atacantes o descubram. Quando o cliente faz qualquer pedido ao servidor, deve incluir no seu pedido, um Header com este token. O servidor, por sua vez, para os pedidos realizados, verifica se o token existe e se é válido, e caso uma destas não se verifique, o servidor protege o cliente não realizando o pedido. Um exemplo bastante utilizado para implementar este mecanismo de prevenção é o JWT Token⁵.
DoS — Denial of Service — Negação de Serviço
Um ataque de negação de serviço é quando um atacante pretende tornar um serviço/aplicação indisponível através da realização de imensos pedidos para esse serviço/aplicação num curto espaço de tempo com o objetivo de sobrecarregar o mesmo, fazendo com que este se torne indisponível para utilizadores legítimos.
Existe uma variante deste ataque mais perigoso chamado DDoS — Distributed Denial of Service, em que o processo é o mesmo, a diferença é que são vários computadores a atacarem o mesmo serviço/aplicação.
Como prevenir:
- Utilizar o Captcha em formulários da aplicação com o objetivo de distinguir humanos de bots⁴. Um serviço que disponibiliza esta funcionalidade é, por exemplo, o reCaptcha da Google⁶.
- Configurar firewalls para bloquear pedidos que sejam suspeitos. Por exemplo aplicar limites de pedidos por utilizador. Outros serviços como a CloudFlare⁷ são capazes também de filtrar pedidos deste tipo de ataques prevenindo que estes cheguem sequer ao alvo¹.
Utilização de Frameworks para proteção — React
A utilização de frameworks no desenvolvimento front-end está cada vez mais presente devido às facilidades que as mesmas nos fornecem relativamente nos processos de debugging do código, reutilização de código, e desenvolvimento rápido. E devido às qualidades que proporciona à nossa aplicação, particularmente na eficiência do código e melhorias da segurança.¹⁰ Apesar das frameworks fornecerem melhorias de segurança, estas também podem ser vistas como um ponto negativo, uma vez que caso exista uma falha de segurança numa framework, todas as aplicações que foram desenvolvidas com essa framework, vão estar vulneráveis a essa falha de segurança⁸. Por isso, é importante utilizar uma framework que seja moderna e que seja constantemente atualizada com as devidas correções de falhas e eventuais novas funcionalidades.
Uma destas frameworks é o React, e de seguida vamos analisá-la consoante algumas das medidas de segurança que implementa para prevenir ataques XSS.
A forma como o React previne ataques de XSS é bastante interessante por duas razões:
- Quando colocamos uma variável para ser mostrada no código HTML, o React converte todos os caractéres especiais para string associada ao adicionar “\”. Por exemplo, no seguinte código vai ser renderizada da seguinte forma:
export default function App() {
var message = "<img onerror='alert(\"hello!\");' src='invalid-image' />";
return <div>{message}</div>;
}
- Apesar dos ataques XSS serem protegidos através da razão anterior, o React permite à mesma não realizar a transformação das strings como referido no ponto anterior. A forma interessante como o React permite é que utiliza o nome do atributo como
dangerouslySetInnerHTMLavisando desta forma o desenvolvedor que está a fazer uma operação perigosa e propícia a ataques XSS. Tendo em conta o exemplo anterior, a página iria executar o script e criar um alerta com a mensagem “hello!”:
export default function App() {
var message = "<img onerror='alert(\"hello!\");' src='invalid-image' />";
return <div dangerouslySetInnerHTML={ { __html: message} }></div>;
}
Apesar destas medidas, o React também é vulnerável a ataques XSS por via do atributo a.href⁹:
export default function App() {
var url = "javascript:alert('hello!');";
return <a href={url}>My Website</a>;
}
Assim que o utilizador clica no link “My Website” o código javascript é executado.
Uma forma de prevenir este ataque é através da filtragem do conteúdo da variável message⁹:
function validateURL(url) {
const parsed = new URL(url)
return ['https:', 'http:'].includes(parsed.protocol)
}
export default function App() {
var url = "javascript:alert('hello!');";
return <a href={validateURL(url) ? url : ''}>My Website</a>;
}Com esta implementação, independentemente do valor da variável url, esta seria apenas colocada no atributo href caso fosse efetivamente um url.
Conclusão
A associação da segurança exclusivamente ao back-end tem que deixar de existir quando desenvolvemos uma aplicação web devido aos diversos ataques e riscos que os utilizadores podem estar sujeitos por vulnerabilidades no front-end. A escolha de uma framework deve ser ponderada devido aos mecanismos de segurança que estas podem fornecer, contudo, não podemos garantir que a nossa aplicação é segura simplesmente por utilizarmos uma framework, devemos à mesma saber como utilizar a framework de forma segura. Por fim, independemente de como vamos desenvolver, devemos sempre colocar a segurança em primeiro lugar quando desenvolvemos qualquer tipo de aplicação web.
Referências
[1]: Chris Odogwu. (23 de Setembro de 2021) 6 Frontend Security Risks and How to Prevent Them https://www.makeuseof.com/prevent-frontend-security-risks/
[2]: The OWASP Foundation. 2021 OWASP Top Ten https://owasp.org/www-project-top-ten/
[3]: Alexander Zlatkov. (20 de Janeiro de 2021) How JavaScript works: 5 types of XSS attacks + tips on preventing them https://blog.sessionstack.com/how-javascript-works-5-types-of-xss-attacks-tips-on-preventing-them-e6e28327748a
[4]: Manoj Singh. (9 de Novembro de 2019) Understanding Frontend Security https://medium.com/@manojsingh047/understanding-frontend-security-ff6585395534
[5]: JWT Token. https://jwt.io/
[6]: reCaptcha, Google. https://www.google.com/recaptcha/about/
[7]: CloudFlare. https://www.cloudflare.com/
[8]: Esteban Borges. (25 de Fevereiro de 2022) Front-End Security: 10 Popular Types of Attacks and Best Practices to Prevent Them https://securitytrails.com/blog/frontend-security-best-practices#content-5-using-modern-frameworks
[9]: Ron Perris, Liran Tal. (18 de Julho de 2022) 10 React security best practices https://snyk.io/blog/10-react-security-best-practices/
[10]: Anirudh Bhardwaj. (6 de Abril de 2021) Web Development Using Frameworks: Why Does It Matter? https://erpsolutions.oodles.io/blog/web-development-frameworks-benefits/
[11]: Nedim Maric. (3 de Dezembro de 2021) What is Persistent (Stored) XSS and How it works https://brightsec.com/blog/cross-site-scripting-persistent/
[12]: Oliver Moradov. (16 de Março de 2022) Reflected XSS: Examples, Testing, and Prevention https://brightsec.com/blog/reflected-xss/
[13]: Nera Besic. (2 de Junho de 2022) How DOM Based XSS Attacks work https://brightsec.com/blog/dom-based-xss/
