O XSS armazenado (Cross-Site Scripting) ocorre quando scripts maliciosos são armazenados permanentemente nos servidores alvo e, mais tarde, exibidos aos usuários que acessam as páginas afetadas. Esse tipo de XSS é especialmente perigoso porque afeta todos os visitantes da página comprometida. A prevenção exige validação adequada de entradas, codificação de saídas e content security policies.
O cross-site scripting armazenado, também chamado de XSS persistente, ocorre quando uma aplicação aceita conteúdo fornecido pelo invasor, o salva e depois o serve a outros usuários sem a devida codificação. O script malicioso é escrito uma única vez, em um campo de comentário, uma avaliação de produto, um post de fórum, um perfil de usuário ou um ticket de suporte, e então é executado no navegador de todo visitante que carrega a página afetada. Diferente do XSS refletido, não é necessário nenhum link criado sob medida nem engenharia social por vítima; o payload aguarda no servidor e dispara automaticamente. Como a marcação injetada passa a fazer parte do conteúdo normal da página, ela pode persistir enquanto o registro existir e continuar infectando novos visualizadores.
O XSS armazenado é a variante mais perigosa de XSS porque se autopropaga e atinge todos que visualizam a página envenenada. Um payload colocado em um tópico popular ou em um perfil compartilhado pode rodar em milhares de sessões, e se cair em algum lugar que um administrador visualize, pode escalar até a tomada total da conta ou da aplicação. Rodando sob a origem do site, o script pode roubar tokens de sessão e cookies sem HttpOnly, capturar teclas digitadas e dados de formulários, agir como a vítima ou se replicar em mais registros. Os históricos worms de XSS se espalharam exatamente assim, acrescentando-se a cada perfil que tocavam e infectando novos usuários a cada visualização.
A defesa é principalmente do lado do servidor e do código: valide e sanitize a entrada na chegada, codifique a saída para o contexto exato na saída e limpe qualquer HTML rico com um sanitizador confiável antes que ele chegue ao DOM. Uma Content Security Policy limita o que um script injetado pode fazer, mesmo que algum escape. A cside não substitui esses controles no código da sua própria aplicação. Onde ela ajuda é na camada de runtime do navegador: ela roteia os scripts de terceiros por um método Script, analisa o payload JavaScript que de fato roda, consegue bloquear comportamentos maliciosos, como a exfiltração de dados, em tempo real, e mantém registros forenses que atendem à PCI DSS 6.4.3 e 11.6.1.
Porque o payload é salvo no lado do servidor e servido a todos que abrem a página afetada, sem precisar de um link ou clique por vítima. Uma única injeção pode rodar na sessão de cada visitante, e se um administrador a visualizar o invasor pode ganhar acesso elevado, o que dá ao XSS armazenado um raio de impacto muito maior.
Não. A vulnerabilidade tem a ver com como o conteúdo é renderizado, não com onde ele é guardado. Se os dados armazenados forem depois inseridos em uma página como HTML sem codificação ou sanitização, eles serão executados. O Markdown pode até acrescentar risco se permitir HTML bruto ou links inseguros, então a saída ainda precisa ser sanitizada.
We answer client-side security questions every day. Bring yours.