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 que são vulneráveis ​​a XSS e sites que executam a plataforma WordPress, a sobreposição deve ser bastante grande.

Esta não é uma batida na plataforma em si. A equipe do WordPress fez da segurança uma parte integral de sua 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 plugins inseguros. Esses problemas são as duas principais portas de entrada para ataques XSS em sites WordPress, e este artigo discutirá como detê-los.

Introdução ao script entre sites

Primeiro, vamos discutir como os ataques XSS são realizados. 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 limpas – 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 pelos usuários do WordPress todos os dias: o comentário de spam. Você sabe do que estou falando: “ Obrigado pelo excelente artigo. A propósito, aqui está o meu site onde eu ganho $ 5.000 por semana trabalhando em casa: www.only-an-idiot-would-click-this-link.co.uk. ”

De alguma forma, 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 todos e quaisquer aspectos do seu site que enviam dados ao servidor, essencialmente usando-os como um editor de texto em miniatura. Se suas entradas não forem defendidas, isso significa que eles 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 vasculhar as interações do site pode 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.

O vandalismo simples é um resultado relativamente comum de ataques XSS, resultando na exibição de imagens grotescas ou propaganda política para seus usuários no lugar do seu conteúdo. Profissionais de marketing com poucos planos de longo prazo ou preocupações éticas os usarão para anunciar para as pessoas contra a vontade delas. Um ataque mais sutil e sutil pode roubar as credenciais de login de seus usuários. Se um deles tiver privilégios de administrador, qualquer informação pessoal armazenada 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 conhecedor de códigos e é o único proprietário de um site WordPress relativamente pequeno, as práticas de codificação seguras provavelmente serão a melhor maneira de bloquear seu site contra ataques de script entre sites. Incluo essa advertência porque, se você faz parte de uma organização maior executando um aplicativo mais complexo, pode não ser humanamente possível encontrar todas as áreas em que um invasor mal-intencionado possa injetar código. Sites modernos podem ser enormes em escala, e pode ser conveniente 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ódigos e está fazendo com que outra pessoa construa seu site para você, não assuma que eles usaram práticas de codificação seguras. Mesmo os desenvolvedores mais experientes são conhecidos por deixar a segurança de lado ou cometer pequenos erros sem que alguém verifique seu trabalho. Outros desenvolvedores podem simplesmente não saber o que estão fazendo em termos de segurança, e outros ainda ignoram a segurança para economizar tempo para si (apesar da falta de profissionalismo quando se trata disso). Em resumo, certifique-se de contratar um profissional aclamado que não faça cortes quando se trata de desenvolver e proteger seu site.

Com essa preocupação 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 solicite que o usuário insira seu nome. Um usuário mal-intencionado pode digitar algo como:

[xhtml]
<script>CoughUpYourPreciousData();</script>
[/xhtml]

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 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, você pode dizer a esse campo para rejeitar entradas com mais de quinze caracteres (ou você pode alterar os valores conforme desejar). Tomar essas medidas limitará drasticamente a quantidade de dano que um invasor pode causar em um campo específico.

Mesmo com validação de dados, pode haver formulários ou campos em que você não pode limitar realisticamente o tipo de caracteres que está sendo usado, 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 reconhecível como um pedaço de código executável em caracteres não codificados. Por exemplo, um hiperlink não aparecerá onde, caso contrário, poderia haver um.

Por fim, há casos em que seu site pode acabar exibindo dados que não são seguros 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 com o escape de dados, o que garante que, quando seu site entregar 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 irá explicar os conceitos acima em detalhes, bem como dar 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 a influência e o orçamento para isso, eu recomendo que você 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 a se defender 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 se propõem a se defender contra ataques XSS. Na verdade, eu não recomendo estes. Em vez de reduzir o risco, muitos desses plugins representam apenas mais uma 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 de 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

Essas informações podem ser um pouco complexas para os não iniciados, mas eu odiaria que as pessoas ficassem desencorajadas pelas possíveis complexidades dessas informações. Caso ocorra um ataque de XSS, você pode ter certeza de que limpar as consequências de tal evento será muito mais complexo 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 quer se preocupar.

Mesmo se você estiver recebendo alguém para lidar com o desenvolvimento e a segurança do seu site para você, faça o que puder para pelo menos ser capaz de 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), conhecer os detalhes do seu site nunca ficará desatualizado.

Pensamentos finais

O cenário de segurança da Internet muda constantemente. Você nunca pode ter certeza 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 ter certeza de que está fazendo tudo ao seu alcance para detê-los. Continue se informando sobre essa ameaça e verifique regularmente (eu recomendaria 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 você usa para acessar seu site. As informações de login ainda precisam ser alteradas com frequência e estar 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 conveniente compartilhar essas informações (ou mesmo este artigo) com seus colegas e partes interessadas para 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, à medida que os hackers tentam descobrir uma maneira diferente de lucrar com os usuários pobres da Internet.

Você tem alguma ideia sobre como verificar se há ataques XSS, bem como se defender contra eles 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 aos seus colegas leitores? Se sim, por favor, deixe um comentário abaixo e continue esta importante conversa com seus colegas leitores.