Introdução

Quando pensamos em um ataque hacker, muitas pessoas imaginam alguém invadindo um servidor, quebrando senhas ou explorando uma falha diretamente na infraestrutura.

Porém, alguns dos ataques mais perigosos acontecem de uma forma diferente: o próprio sistema vulnerável acaba ajudando o atacante.

Esse é o caso do Stored Cross-Site Scripting (Stored XSS), uma vulnerabilidade onde uma aplicação web armazena conteúdo malicioso enviado por um usuário e, posteriormente, entrega esse conteúdo para outras pessoas.

Em outras palavras:

O site não é invadido diretamente. Ele é transformado em um meio involuntário de distribuição de código malicioso.

O que é XSS?

XSS significa Cross-Site Scripting.

O problema acontece quando uma aplicação permite que um usuário envie conteúdo que será interpretado pelo navegador de outra pessoa como código executável.

Imagine um site com uma área de comentários.

O comportamento esperado seria:

Usuário escreve:
"Excelente artigo!"

Servidor salva:
"Excelente artigo!"

Navegador exibe:
Excelente artigo!

O problema aparece quando o sistema não diferencia corretamente:

• texto comum;
• código que deve ser interpretado pelo navegador.

A história de João e Maria

Para entender melhor, imagine três personagens:

• João: atacante mal-intencionado;
• Maria: usuária comum;
• ssminojhonso.com: aplicação vulnerável.

O site possui uma área de comentários.

Maria utiliza normalmente:

"Gostei muito dessa publicação."

Mas João decide testar se o sistema aceita qualquer tipo de conteúdo.

Ele envia algo diferente:

<script>
código malicioso
</script>

O site deveria tratar isso como texto.

Porém, devido a uma falha, ele salva esse conteúdo no banco de dados.

O site virou um distribuidor sem saber

O grande detalhe do Stored XSS está aqui.

João não precisa invadir o servidor.

Ele apenas utiliza uma funcionalidade legítima:

Enviar comentário

O fluxo fica assim:

     João
      ↓
 envia conteúdo malicioso
↓
Servidor
salva no banco de dados
↓
Banco de dados
↓
devolve junto com a página
↓
Maria acessa o site
|
↓
Navegador interpreta o código

Por que o navegador executa esse código?

Essa é uma das partes mais importantes.

O navegador não sabe quem escreveu aquele conteúdo.

Para ele, tudo veio do mesmo lugar:

ssminojhonso.com

Quando recebe uma página HTML, ele confia que aquele conteúdo faz parte da aplicação.

Então ele pensa:

"O site enviou este código, então provavelmente devo executar."

O problema é que aquele trecho foi criado por João, não pelo desenvolvedor do sistema.

É uma quebra de confiança entre:

Usuário
 ↓
Aplicação
 ↓
Navegador

O servidor foi hackeado?

Não necessariamente.

Essa é uma confusão comum.

No Stored XSS:

• o servidor normalmente continua funcionando;
• o banco continua funcionando;
• a aplicação continua online.

O problema é que ela passa a entregar conteúdo perigoso aos usuários.

Uma analogia:

Imagine um mural de avisos de uma empresa.

João coloca um aviso falso no mural.

O prédio não foi invadido.

Mas todas as pessoas que passam pelo mural podem ser enganadas.

O site funciona como esse mural.

Quem é a vítima?

A vítima normalmente é quem acessa a página contaminada.

No nosso exemplo:

João → cria o conteúdo malicioso

ssminojhonso.com → armazena e distribui

Maria → acessa e é afetada

Por isso o Stored XSS é considerado perigoso.

Um único conteúdo armazenado pode atingir:

• visitantes;
• usuários autenticados;
• moderadores;
• administradores.

Por que administradores são alvos importantes?

Imagine que um administrador abre a página vulnerável.

Ele possui permissões maiores dentro da aplicação.

Então o impacto pode ser maior, pois o ataque acontece dentro de uma sessão com mais privilégios.

Por isso, vulnerabilidades XSS são frequentemente consideradas críticas em sistemas que possuem:

• painéis administrativos;
• sistemas financeiros;
• plataformas corporativas;
• redes sociais.

Como a segurança impede o Stored XSS?

Existem várias camadas de proteção.

1. Tratamento correto de saída

A aplicação deve transformar caracteres especiais em texto comum.

Por exemplo:

Em vez de interpretar:

<script>

o sistema deve exibir como texto:

<script>

Assim o navegador entende:

"isso é apenas uma mensagem".

2. Validação de entrada

O sistema deve verificar quais dados são permitidos.

Exemplo:

Um campo de nome provavelmente precisa aceitar:

João Silva

Mas não precisa aceitar código HTML.

3. Content Security Policy (CSP)

A CSP funciona como uma lista de permissões para o navegador.

Ela informa:

"Somente execute recursos vindos de locais confiáveis."

É uma camada adicional de proteção contra diversos ataques XSS.

Ferramentas usadas por profissionais

Em ambientes autorizados, profissionais de segurança utilizam ferramentas como:

• Burp Suite;
• OWASP ZAP;
• XSStrike;
• DalFox.

Essas ferramentas ajudam a encontrar pontos vulneráveis e validar se uma aplicação está protegida.

O objetivo de um profissional de segurança não é explorar sistemas, mas encontrar problemas antes que atacantes reais encontrem.

Conclusão

O Stored XSS mostra que segurança não depende apenas de proteger servidores.

Uma simples área de comentários pode se tornar uma porta de entrada para ataques quando a aplicação não trata corretamente os dados enviados pelos usuários.

O maior aprendizado é:

Todo dado vindo de um usuário deve ser tratado como potencialmente perigoso até que seja validado.

O navegador confia no site.

O desenvolvedor precisa garantir que essa confiança não seja usada contra os próprios usuários.