Como verificar se o seu sistema WordPress está protegido contra ataques XSS
Em todo o mundo, quase 48% de todos os sites são vulneráveis a scripts entre sites (XSS). Em todo o mundo, quase exatamente 25% de todos os sites utilizam a plataforma WordPress.
Segue-se que no diagrama de Venn de sites vulneráveis a XSS e sites que executam a plataforma WordPress, a sobreposição deve ser bastante grande.
Isso não é uma batida na plataforma em si. A equipe do WordPress tornou a segurança parte integrante de sua declaração de missão e corrige agressivamente as vulnerabilidades sempre que elas se tornam conhecidas. No entanto, isso não impede que as pessoas codifiquem temas inseguros ou instalem plug-ins inseguros. Esses problemas são as duas principais portas de entrada para ataques XSS em sites WordPress, e este artigo discutirá como pará-los.
Introdução ao Cross-Site Scripting
Primeiro, vamos discutir como os ataques XSS são executados. Há mais de um tipo de ataque XSS, então vou começar com uma definição simplificada. Geralmente, os ataques XSS começam com entradas não sanitizadas – formulários de comentários, caixas de comentários, barras de pesquisa, etc. Esses ataques variam muito em sofisticação. Na verdade, a forma mais simples de ataque XSS é vista diariamente pelos usuários do WordPress: o comentário de spam. Você sabe do que estou falando: “Obrigado pelo excelente artigo. A propósito, aqui está meu site onde ganho $ 5.000 por semana trabalhando em casa: www.only-an-idiot-would-click-this-link.co.uk."
De alguma forma, os comentários de spam são o exemplo perfeito de um ataque XSS. Uma entidade maliciosa subverte a infraestrutura do seu site (a caixa de comentários) para colocar seu conteúdo (o link malicioso) em seu site. Embora este seja um bom exemplo ilustrativo, um ataque XSS mais realista será muito mais sutil. Um comentário de spam leva cerca de cinco segundos para ser criado. Um ataque XSS é algo em que um hacker adequado gastará um pouco mais de tempo.
Um verdadeiro black hat tentará tirar proveito de todo e qualquer aspecto do seu site que envie dados para o servidor, essencialmente usando-os como um editor de texto em miniatura. Se suas entradas não estiverem protegidas, isso significa que elas podem literalmente pegar seu código e forçar seu aplicativo a executá-lo e renderizá-lo no navegador de um usuário (e isso pode incluir seu navegador). Ao contrário dos comentários de spam, apenas um exame detalhado do código modificado do seu site ou uma análise das interações do site podem revelar uma violação. Como se pode imaginar, não há fim para o número de coisas desagradáveis que podem resultar de tal violação.
Vandalismo simples é um resultado relativamente comum de ataques XSS, resultando na exibição de imagens grotescas ou propaganda política aos seus usuários no lugar do seu conteúdo. Os profissionais de marketing com poucos planos de longo prazo ou preocupações éticas os usarão para fazer propaganda para as pessoas contra sua vontade. Um ataque mais matizado e sutil pode roubar as credenciais de login de seus usuários. Se um deles tiver privilégios de administrador, qualquer informação pessoal que você armazene em seu site pode estar disponível. Como alternativa, eles podem usar o ataque XSS inicial como uma alavanca para abrir seu site e instalar malware ainda mais avançado.
Parando Ataques
Se você é um indivíduo razoavelmente experiente em código e é o único proprietário de um site WordPress relativamente pequeno, as práticas seguras de codificação provavelmente serão a melhor maneira de bloquear seu site contra ataques de script entre sites. Incluo esta ressalva porque, se você fizer parte de uma organização maior executando um aplicativo mais complexo, pode não ser humanamente possível localizar todas as áreas onde um invasor mal-intencionado pode injetar código. Os sites modernos podem ser enormes em escala e pode ser necessário contratar um profissional experiente e gastar seu tempo em outras atividades para tornar seu site ainda melhor para seus leitores.
Outro aviso é que, se você não é particularmente conhecedor de código e está fazendo com que outra pessoa construa seu site para você, não presuma que eles usaram práticas de codificação seguras. Sabe-se que até mesmo os desenvolvedores mais experientes deixam a segurança de lado ou cometem pequenos erros sem que outra pessoa verifique seu trabalho. tempo para si (apesar da falta de profissionalismo quanto a isso). Em resumo, certifique-se de contratar um profissional aclamado que não economize quando se trata de desenvolver e proteger seu site.
Essa preocupação sendo expressa, uma das primeiras e mais fáceis coisas que você pode fazer para evitar scripts entre sites é validar os dados do usuário.
Digamos que você tenha um formulário de inscrição em seu site e esse formulário peça ao usuário para inserir seu nome. Um usuário mal-intencionado pode digitar algo como:
<script>CoughUpYourPreciousData();</script>Isso pode, por exemplo, fazer com que a próxima pessoa que visitar essa página envie uma cópia de seus cookies para um invasor.
Você pode ver que neste exemplo, a string de código acima não se parece em nada com o nome de alguém. Seu servidor não sabe disso, mas usando alguns parâmetros definidos, você pode ensiná-lo. Por exemplo, você pode dizer a esse campo para rejeitar caracteres especiais, como <>,() e ; (eles não são particularmente necessários em uma seção de comentários). Você pode dizer a esse campo que o nome de uma pessoa provavelmente não contém números. Se você estiver disposto a ser um pouco draconiano, pode dizer a esse campo para rejeitar entradas com mais de quinze caracteres (ou pode alterar os valores conforme desejar). Seguir essas etapas limitará drasticamente a quantidade de dano que um invasor pode causar com um campo específico.
Mesmo com a validação de dados, pode haver formulários ou campos onde você não pode limitar de forma realista o tipo de caracteres usados, como em um formulário de contato ou campo de comentário. O que você pode fazer é higienizar os dados. Esse processo impossibilita que o HTML seja executado em um determinado campo, convertendo tudo o que pode ser reconhecido como um pedaço de código executável em caracteres não codificados. Por exemplo, um hiperlink não aparecerá onde poderia haver um.
Por fim, há casos em que seu site pode acabar exibindo dados inseguros para os usuários. Digamos que alguém escreva um comentário malicioso em uma de suas páginas, que é posteriormente indexado pela função de pesquisa do seu site. Sempre que um de seus usuários realiza uma pesquisa, esse código malicioso é executado quando o navegador carrega os resultados da pesquisa. Isso é evitado pelo escape de dados, o que garante que, quando seu site fornecer dados a um usuário, o único código executado seja o código que você deseja executar.
Para saber mais sobre validação de dados, limpeza de dados e escape de dados, o WordPress Codex tem um excelente recurso. Ele explicará os conceitos acima em detalhes, além de fornecer mais exemplos que podem ser aplicados universalmente.
Outros métodos
Grandes empresas têm sites maiores; é um fato. Talvez milhares de pessoas usem seu site por dia. Talvez em vez de formulários e campos padrão, também existam animações, vários portais, partes escritas em Java e assim por diante. Mesmo que você acompanhe tudo isso, talvez haja um dia zero em um de seus aplicativos e você não tenha como se defender.
Em uma situação como essa, se você tiver influência e orçamento para fazer isso, recomendo que invista em um Web Application Firewall (WAF). Um bom WAF terá regras de correlação que identificam e bloqueiam automaticamente as strings HTML mais comumente associadas a ataques de injeção de código. Eles também podem notificá-lo quando os aplicativos começam a exfiltrar dados quando não deveriam ou estão fazendo isso em um volume incomum, ajudando assim na defesa contra ataques de dia zero e outras ameaças avançadas. Um WAF não é uma bala de prata, mas é uma ferramenta inestimável para profissionais de segurança e proprietários de sites que desejam proteger aplicativos complexos.
Há também vários plugins que pretendem se defender contra ataques XSS. Na verdade, eu não recomendo isso. Em vez de reduzir o risco, muitos desses plug-ins representam apenas outra superfície de ataque para um hacker explorar. Mesmo um dos plugins de segurança mais conhecidos e amplamente usados, o Akismet, foi considerado vulnerável a ataques XSS no ano passado. Quando se trata de desviar ataques XSS, não confie em meias medidas. Desenvolva as habilidades necessárias e use o conjunto apropriado de ferramentas para manter seu site seguro.
Outras Aplicações Práticas
Esta informação pode ser um pouco complexa para os não iniciados, mas eu odiaria que as pessoas ficassem desencorajadas pelas potenciais complexidades desta informação. Caso ocorra um ataque XSS, você pode ter certeza de que a limpeza após tal evento será muito mais complexa do que fazer as alterações em seu site. Limpar os custos de reputação do seu site (leitores regulares fugirão do seu site com bastante facilidade) será um problema adicional com o qual você não deve se preocupar.
Mesmo se você estiver contratando outra pessoa para cuidar do desenvolvimento e da segurança do seu site, faça o possível para, pelo menos, responder a uma emergência e saber onde estão seus pontos fracos. Saber como verificar seu sistema será uma habilidade vital a longo prazo e será a base para outros tópicos de segurança e projetos de desenvolvimento de sites. Tudo está interconectado on-line e, embora os ataques XSS possam ser uma coisa dos últimos anos (por mais improvável que seja), saber os meandros do seu site nunca ficará desatualizado.
Pensamentos finais
O cenário de segurança da Internet muda constantemente. Você nunca pode estar totalmente certo de como um ataque XSS pode aparecer ou como ele pode ser utilizado contra você, mas você deve isso a si mesmo e a seus leitores para se certificar de que está fazendo tudo ao seu alcance para detê-los. Continue se informando sobre essa ameaça e verifique regularmente (recomendo pelo menos mensalmente) quaisquer desenvolvimentos relevantes no mundo da segurança cibernética.
Isso também não significa que você pode ignorar outras ameaças. O acesso à rede pública ainda requer o uso de VPN para ser seguro. Você não pode negligenciar a segurança de qualquer computador que usar para acessar seu site. As informações de login ainda precisam ser alteradas com frequência e protegidas contra ataques de força bruta. Os ataques XSS são brutais, mas não são a única ameaça a ser observada.
Também pode ser importante que você compartilhe esta informação (ou mesmo este artigo) com seus colegas e partes interessadas, a fim de espalhar a resistência contra esses tipos de ataques. Embora você não consiga fazer muito sozinho, se um número suficiente de pessoas estiver se protegendo adequadamente, poderemos ver uma diminuição geral nesses tipos de ataques, pois os hackers tentam descobrir uma maneira diferente de lucrar com os usuários pobres da Internet.
Você tem alguma ideia de como verificar se há ataques XSS, bem como se defender deles no futuro? Existem outras estratégias de detecção e remoção que você usa para combater essa ameaça? Existem ferramentas que você recomendaria a seus colegas leitores? Em caso afirmativo, deixe um comentário abaixo e continue esta importante conversa com seus colegas leitores.