Não persistente (aka reflexivo)

O artigo da wikipedia faz-lhe grande justiça:

A vulnerabilidade de scripts cross-site não persistente (ou refletida) é de longe o tipo mais comum. Esses furos aparecem quando os dados fornecidos por um cliente da Web, mais comumente em parâmetros de consulta http ou em submissões de formulário HTML, são usados imediatamente por scripts do lado do servidor para gerar uma página de resultados para esse usuário, sem higienizar adequadamente a solicitação.

Como os documentos HTML têm um plano, a estrutura serial que mistura as instruções de controle, a formatação e o conteúdo real, quaisquer dados fornecidos pelo usuário não validados incluídos na página resultante sem codificação HTML adequada, podem levar à injeção de marcação. Um exemplo clássico de um vetor potencial é um mecanismo de pesquisa de site: se um procura por uma seqüência de caracteres, a seqüência de caracteres de pesquisa normalmente será reexibida textualmente na página de resultado para indicar o que foi pesquisado. Se essa resposta não escapar corretamente ou rejeitar caracteres de controle HTML, uma falha de script de cross-site irá resultar.

Um ataque refletido é tipicamente entregue via e-mail ou um site neutro. A isca é uma URL de aparência inocente, apontando para um site confiável, mas que contém o vetor XSS. Se o site confiável for vulnerável ao vetor, clicando no link pode fazer com que o navegador da vítima execute o script injetado.

...

Não persistente (aka reflexivo):

Alice muitas vezes visita um site particular, que é hospedado por Bob. O site de Bob permite que Alice efetue login com um par de nome de usuário/senha e armazena dados confidenciais, como informações de faturamento.

Mallory observa que o site de Bob contém uma vulnerabilidade de XSS refletida.

Mallory Crafts uma URL para explorar a vulnerabilidade, e envia Alice um e-mail, seduzindo-a a clicar em um link para a URL falsos pretextos. Esta URL irá apontar para o site de Bob (seja diretamente ou através de um iframe ou Ajax), mas conterá o código malicioso de Mallory, que o site irá refletir.

Alice visita a URL fornecida por Mallory enquanto logado no site de Bob.

O script malicioso incorporado na URL é executado no navegador de Alice como se ele veio diretamente do servidor de Bob (esta é a vulnerabilidade de XSS real). O script pode ser usado para enviar cookie de sessão de Alice para Mallory. Mallory pode então usar o cookie de sessão para roubar informações confidenciais disponíveis para Alice (credenciais de autenticação, informações de faturamento, etc.) sem o conhecimento de Alice.

Tem alguma pergunta sobre isso?

O trabalho de defesa padrão é higienizar entrada de usuário não confiável; por exemplo, apenas deixá-los inserir um pequeno subconjunto de HTML (a partir de uma linguagem de marcação segura limitada) ou passar por um bom sanitizer HTML/purificador, não use padrões inseguros em scripts (por exemplo, eval em JavaScript na entrada do usuário), idealmente usar um navegador com CSP e Sandboxing, etc.