<
e >
são codificados como +ADw-
e +AD4-
em UTF-7 . Agora imagine o seguinte:
-
Alguém envia
+ADw-script+AD4-alert(+ACI-Hello+ACI-)+ADw-/script+AD4-
como texto de comentário. Ele vai passar todo o saneamento sem escape. -
O banco de dados espera e trata todos os dados recebidos como UTF-8. Como todos os fluxos UTF-7 também são válidos para UTF-8, isso nunca resultará em erro de SQL e
mysql_real_escape
ouhtmlspecialchars
não tocarão nele. -
WordPress envia um cabeçalho
text/html;charset=utf-7
. -
WordPress exibe o comentário, esperando dados com escape. Mas como isso é tratado como UTF-7 pelo navegador, o JavaScript será executado.
Então, sim, é um problema de segurança.
O UTF-7 não é suportado por todos os navegadores, a maioria renderiza o texto como Windows-1252 (ou qualquer que seja a codificação padrão em seu sistema operacional) ou como UTF-8. O principal problema é: escapar não funcionará mais.
Apenas alterar o valor de codificação de volta não é uma solução. Um visitante regular nunca pode mudá-lo, então você tem para encontrar a porta aberta.