Evite a execução de scripts maliciosos e o roubo de informações do usuário bloqueando entradas HTML, higienizando dados, protegendo cookies e implantando firewall de aplicativos web (WAFs).
Após ler este artigo, você será capaz de:
Copiar o link do artigo
Cross-site scripting (XSS) é uma tática na qual um invasor injeta código malicioso por meio de um ou mais scripts web em um site ou aplicativo web legítimo. Quando um usuário carrega o site ou executa o aplicativo web, esses scripts são executados no navegador do usuário.
Os scripts podem executar uma variedade de ações maliciosas, como roubar os cookies HTTP dos usuários , os tokens de sessão ou outras informações confidenciais. Um invasor poderia usar essas informações para se passar por usuários e obter acesso não autorizado a contas em diferentes plataformas, como plataformas de mídia social ou sites bancários. Além disso, os scripts podem desfigurar o site, redirecionar os usuários para sites maliciosos ou extrair dados confidenciais de aplicativos web .
Para saber mais, consulte O que é cross-site scripting?
Os dois tipos mais proeminentes de ataques XSS são o XSS refletido (não persistente) e o XSS armazenado (persistente).
Ataques XSS refletidos podem ocorrer quando um site legítimo não consegue validar ou higienizar a entrada do usuário. Esses ataques geralmente começam com engenharia social, em que o invasor envia e-mails de phishing ou deixa mensagens em posts em fóruns on-line com um link que atrai os usuários para clicarem nele. Normalmente, o link inclui o URL de um site legítimo anexado com um código malicioso.
Quando um usuário clica no link, seu navegador envia uma solicitação ao site legítimo, que reflete o código injetado de volta no navegador do usuário. Como o site não higieniza adequadamente a entrada, o script malicioso é executado no navegador do usuário.
O código poderia copiar os cookies do usuário e enviá-los para o invasor. Se o invasor adquirir um cookie de sessão, ele poderá assumir o controle da sessão, o que pode permitir que ele faça compras fraudulentas, roube informações bancárias ou poste spam em plataformas de redes sociais, entre outras ações maliciosas.
Esse tipo de XSS é chamado de ataque "refletido" porque o script malicioso é refletido pelo servidor web e executado no navegador do usuário. Também é conhecido como "não persistente" porque o script opera apenas no navegador do usuário quando a página está carregada, não continuamente.
Os ataques de XSS armazenados são mais graves do que os ataques de XSS refletidos. Com o XSS armazenado, um script malicioso é armazenado permanentemente no servidor de destino.
Os invasores geralmente executam essa forma de XSS incorporando um script malicioso em um campo de formulário, como uma caixa de comentário, perfil de usuário ou qualquer campo de entrada que aceite e armazene conteúdo do usuário. Depois que a postagem, comentário ou formulário são enviados, o script é injetado no aplicativo web e salvo no banco de dados do aplicativo web. Quando outros usuários carregam a página afetada, o script armazenado é executado em seus navegadores. Assim como nos ataques XSS refletidos, o script pode roubar cookies ou outras informações do usuário, que podem ser enviadas de volta ao invasor.
Este tipo de XSS também é chamado de "persistente" porque a execução ocorre toda vez que a página é acessada. Isso é também o que torna os ataques XSS armazenados particularmente perigosos: eles podem afetar um grande número de usuários sem qualquer interação além da simples visualização de uma página web.
Os usuários individuais podem tomar várias medidas para reduzir o risco de ataques XSS:
Como muitos ataques XSS começam com esquemas de phishing ou outras táticas de engenharia social, os usuários devem aprender a identificar e-mails e mensagens suspeitas. Ao notificar as equipes apropriadas de TI ou segurança, os usuários podem ajudar a interromper os ataques XSS e resolver outras questões de segurança.
Se os usuários virem um link em um fórum on-line ou em uma postagem social de alguém que não conhecem ou confiam, devem pensar duas vezes antes de clicar nele. Mesmo que o link pareça legítimo, os usuários devem prosseguir com cautela. Muitos links que acionam ataques XSS parecem legítimos porque contêm um URL legítimo. Mas os usuários devem examinar o link completo, incluindo tudo depois do ".com", .org, .gov, ou outro sufixo. O texto inesperado após o endereço da página pode ser um código malicioso.
Os desenvolvedores podem desempenhar um papel vital na prevenção de ataques XSS, implementando algumas das principais práticas recomendadas:
Os desenvolvedores podem implementar regras que evitam que os usuários postem dados em uma página ou em um formulário, a menos que atendam a certos critérios. Por exemplo, se um formulário solicitar um número de seguro social ou um número de telefone, os desenvolvedores podem criar uma regra para que essa entrada contenha apenas números, hífens ou parênteses. Para uma prevenção de ataques mais consistente, os desenvolvedores podem definir regras de validação que rejeitem explicitamente as tags ou os caracteres comumente usados em ataques XSS, como as tags < script > .
Os desenvolvedores também podem impedir que os usuários usem HTML em comentários, postagens e entradas de formulário. O conteúdo HTML pode ser uma forma de postar scripts maliciosos ou ocultar links para URLs que incluam código malicioso.
Se as organizações quiserem permitir que os usuários publiquem conteúdo rico, como texto ou imagens formatados, elas podem incorporar o Markdown (uma linguagem de marcação leve) ou habilitar a formatação de rich text dentro de um (WYSIWYG) . Ambos os métodos são formas mais seguras de ser compatível com conteúdo rico.
Os desenvolvedores podem ajudar a evitar danos causados por ataques XSS, implementando um processo para examinar os dados depois de terem sido postados no servidor web, mas antes de serem exibidos para outro usuário. Mesmo que os desenvolvedores permitam o uso de HTML, por exemplo, eles podem higienizar todas as entradas HTML e filtrar qualquer código malicioso antes de ser executado em um navegador.
A codificação de saída e o "escaping" seguem uma abordagem semelhante. A ideia é transformar scripts maliciosos ou outros códigos encontrados na entrada do usuário em texto comum antes que qualquer coisa seja escrita em uma página. A codificação de saída converte o código em um formato diferente; o "escaping" adiciona caracteres especiais ao código (como contrabarras ou aspas). Em qualquer um dos casos, um navegador não interpretará o texto resultante como código e o executará. Enquanto a higienização filtra o código, a codificação de saída e o "escaping" preservam o código ao mesmo tempo que o tornam inofensivo.
Os desenvolvedores devem integrar a segurança em todo o desenvolvimento de aplicativos web . Por exemplo, eles devem realizar análises de código, com foco especialmente em áreas onde a entrada do usuário é aceita e exibida. Eles também devem realizar modelagem de ameaças e testes para identificar vulnerabilidades antes que o aplicativo seja lançado.
As equipes de segurança podem implementar várias práticas recomendadas para ajudar a prevenir e responder rapidamente a ataques XSS:
As equipes de segurança podem tomar várias medidas para ajudar a garantir que os servidores web estejam configurados corretamente para bloquear scripts maliciosos e evitar que o invasor roube os cookies do usuário:
Implementar uma política de segurança de conteúdo: os desenvolvedores e as equipes de segurança devem trabalhar em conjunto para definir políticas de segurança de conteúdo (CSPs) fortes para sites e aplicativos web e implementá-las em servidores web . Uma CSP é uma camada adicional de segurança que pode detectar e mitigar determinados tipos de ataques. Para evitar ataques XSS, ela restringe quais scripts podem ser executados. Os servidores web podem ser configurados para retornar cabeçalhos de resposta HTTP CSP que proíbem os navegadores de carregar scripts prejudiciais.
Cookies seguros: as equipes de segurança podem definir regras especiais de como os servidores web lidam com os cookies para reduzir a probabilidade de roubo de cookies. Por exemplo, eles podem vincular cookies a endereços de IP específicos . Como a maioria dos usuários tem um endereço de IP dinâmico, as conexões entre um endereço de IP e os cookies não duram muito. Como resultado, os invasores não conseguem roubar e usar esses cookies.
Além disso, as equipes de segurança podem bloquear completamente o JavaScript de acessar os cookies. Um meio de fazer isso é adicionar o sinalizador HttpOnly aos cookies ao gerenciá-los. O sinalizador indica que os cookies podem conter informações confidenciais do usuário, como token de sessão ou credenciais de autenticação. Um navegador que oferece suporte ao sinalizador HttpOnly não revelará essa informação.
Um firewall de aplicativos web (WAF) pode oferecer uma linha importante de defesa contra ataques XSS. Operando como um servidor proxy reverso posicionado na frente dos aplicativos web , o WAF os protege, monitorando e filtrando o tráfego HTTP entre os aplicativos e a internet. As organizações podem definir regras de WAF para inspecionar URLs em busca de scripts maliciosos e impedir que sejam refletidos para os usuários. As soluções WAF com aprendizado de máquina oferecem uma proteção ainda mais forte ao detectar tentativas de contornar regras e identificar variações em ataques conhecidos.
Como muitos ataques XSS começam com phishing, as equipes de segurança devem fortalecer as defesas contra ataques de phishing. Além de educar os usuários sobre como identificar e-mails e mensagens suspeitas, as equipes de segurança podem implementar recursos de segurança para bloquear spam de e-mail, usar um serviço de isolamento do navegador para evitar a execução de malware, instalar um gateway seguro da web (SWG) para evitar que os usuários façam download de arquivos maliciosos e implantar ferramentas de segurança de e-mail para detectar e bloquear tentativas de phishing em tempo real.
As equipes de segurança devem testar vulnerabilidades em ambientes de produção. O Teams pode executar testes de penetração manuais ou usar scanners de XSS automatizados.
Apesar dos amplos esforços de prevenção, as organizações ainda podem estar sujeitas a ataques XSS. Ter um plano de resposta a incidentes em vigor é essencial para uma recuperação rápida. Esse plano deve incluir estratégias para monitorar atividades de aplicativos web e tomar medidas quando ocorrem eventos suspeitos. As equipes devem, então, analisar as causas raízes e identificar os métodos de ataque. Quando o ataque tiver terminado, a empresa deve aplicar as lições aprendidas para aumentar os recursos de segurança, atualizar políticas e corrigir as vulnerabilidades dos aplicativos web .
A Cloudflare oferece vários produtos e recursos que podem ajudar as organizações e usuários a evitar ataques XSS:
Saiba mais sobre o Cloudflare WAF.