XSS refletido ocorre quando scripts maliciosos sao incluidos em URLs e imediatamente refletidos de volta aos usuarios sem sanitizacao adequada. Esses ataques tipicamente requerem engenharia social para convencer usuarios a clicar em links maliciosos. A prevencao envolve validacao de entrada, codificacao de saida e implementacao de cabecalhos de Content Security Policy.
O cross-site scripting refletido acontece quando uma aplicação web recebe dados de uma requisição, geralmente um parâmetro de consulta na URL, um termo de busca ou um campo de formulário, e os devolve diretamente na resposta HTML sem codificá-los. Se um invasor cria um link cujo parâmetro contém um script, o servidor reflete esse script na página e o navegador da vítima o executa como se o próprio site o tivesse escrito. O payload não fica armazenado em lugar nenhum; ele existe apenas naquela única requisição, então cada ataque precisa de um novo link malicioso. Um vetor típico é uma página de resultados de busca que imprime a sua consulta literalmente, ou uma página de erro que repete um valor não escapado retirado da URL.
Como o script injetado roda no navegador da vítima sob a própria origem do site, ele herda a confiança dessa origem. Ele pode ler cookies sem a flag HttpOnly, tokens de sessão e o conteúdo da página, enviar formulários ou reescrever o que o usuário vê, o que possibilita sequestro de sessão, roubo de credenciais e phishing que aparenta vir do domínio real. O XSS refletido normalmente depende de engenharia social: o invasor precisa fazer a vítima clicar em um link armadilhado vindo de e-mail, chat ou de um anúncio malicioso, por isso costuma atingir usuários logados de bancos, webmail ou painéis administrativos. Um único parâmetro vulnerável pode comprometer qualquer conta cujo dono abra o link.
As defesas centrais estão do lado do desenvolvedor: valide a entrada e aplique codificação de saída sensível ao contexto, para que os valores refletidos sejam renderizados como texto, nunca como marcação ou script. Uma Content Security Policy adiciona uma segunda camada ao restringir quais scripts podem rodar, e o auto-escaping dos frameworks resolve a maioria dos casos por padrão. A cside não substitui a codificação de saída; seu foco são os scripts de terceiros que uma página carrega. Quando um ponto de apoio de XSS ou um script de fornecedor comprometido tenta carregar ou exfiltrar dados através do navegador, o proxy híbrido da cside inspeciona o payload JavaScript real, consegue bloquear esse comportamento em tempo real e mantém um registro forense, o que também atende aos requisitos de monitoramento de scripts da PCI DSS 6.4.3 e 11.6.1.
Seu raio de impacto costuma ser menor, porque o payload não é salvo no servidor, então ele afeta apenas os usuários que abrem um link específico criado pelo invasor, em vez de todos que visualizam uma página. Mas as capacidades dentro do navegador são idênticas, e contra um alvo logado de alto valor um único clique pode bastar para sequestrar uma conta.
Não. A flag HttpOnly apenas esconde um cookie do JavaScript, então ela limita o roubo de tokens, mas um script refletido ainda pode agir dentro da sessão, ler dados da página, enviar requisições e desfigurar a interface. HttpOnly é uma mitigação útil, não uma solução; você ainda precisa de codificação de saída e de uma CSP robusta.
We answer client-side security questions every day. Bring yours.