A codificação HTML impedirá todos os tipos de ataques XSS?

Question

Não estou preocupado com outros tipos de ataques.Só quero saber se o HTML Encode pode impedir todos os tipos de ataques XSS.

Existe alguma maneira de fazer um ataque XSS mesmo se o HTML Encode for usado?

Answer 1

Não.

Deixando de lado o assunto de permitir algumas tags (não é realmente o objetivo da questão), o HtmlEncode simplesmente NÃO cobre todos os ataques XSS.

Por exemplo, considere o javascript do lado do cliente gerado pelo servidor - o servidor gera dinamicamente valores codificados em html diretamente no javascript do lado do cliente, o htmlencode irá não pare script injetado seja executado.

A seguir, considere o seguinte pseudocódigo:

<input value=<%= HtmlEncode(somevar) %> id=textbox>

Agora, caso não seja imediatamente óbvio, se somevar (enviado pelo usuário, é claro) estiver definido, por exemplo, para

a onclick=alert(document.cookie)

a saída resultante é

<input value=a onclick=alert(document.cookie) id=textbox>

o que claramente funcionaria.Obviamente, este pode ser (quase) qualquer outro script...e HtmlEncode não ajudaria muito.

Existem alguns vetores adicionais a serem considerados...incluindo o terceiro tipo de XSS, chamado XSS baseado em DOM (em que o script malicioso é gerado dinamicamente no cliente, por ex.com base em # valores).

Também não se esqueça dos ataques do tipo UTF-7 - onde o ataque se parece

+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-

Não há muito para codificar lá ...

A solução, é claro (além da validação de entrada da lista branca adequada e restritiva), é realizar sensível ao contexto codificação:HtmlEncoding é ótimo SE o contexto de saída for HTML, ou talvez você precise de JavaScriptEncoding, ou VBScriptEncoding, ou AttributeValueEncoding, ou...etc.

Se estiver usando o MS ASP.NET, você pode usar a biblioteca Anti-XSS, que fornece todos os métodos de codificação de contexto necessários.

Observe que toda codificação não deve ser restrita à entrada do usuário, mas também a valores armazenados do banco de dados, arquivos de texto, etc.

Ah, e não se esqueça de definir explicitamente o conjunto de caracteres, tanto no cabeçalho HTTP quanto na tag META, caso contrário você ainda terá vulnerabilidades UTF-7...

Mais algumas informações e uma lista bastante definitiva (constantemente atualizada), confira a folha de dicas do RSnake: http://ha.ckers.org/xss.html

Answer 2

Se você codificar sistematicamente todas as entradas do usuário antes de exibir então sim, você está seguro você ainda não está 100% seguro.
(Veja a postagem de @Avid para mais detalhes)

Além disso, surgem problemas quando você precisa deixar alguns as tags ficam sem codificação para que você permita que os usuários postem imagens ou texto em negrito ou qualquer recurso que exija que a entrada do usuário seja processada como (ou convertida em) marcação não codificada.

Você terá que configurar um sistema de tomada de decisão para decidir quais tags são permitidas e quais não são, e sempre é possível que alguém descubra uma maneira de permitir a passagem de uma tag não permitida.

Ajuda se você seguir o conselho de Joel de Fazendo o código errado parecer errado ou se sua língua ajuda você avisando/não compilando quando você está gerando dados de usuário não processados ​​(digitação estática).

Answer 3

Se você codificar tudo, isso acontecerá.(dependendo da sua plataforma e da implementação do htmlencode) Mas qualquer aplicativo da web útil é tão complexo que é fácil esquecer de verificar cada parte dele.Ou talvez um componente de terceiros não seja seguro.Ou talvez algum caminho de código que você tenha codificado não tenha feito isso, então você o esqueceu em outro lugar.

Portanto, você também pode querer verificar as coisas no lado da entrada.E você pode querer verificar o que leu no banco de dados.

Answer 4

Como mencionado por todos os outros, você estará seguro contanto que codifique todos entrada do usuário antes de exibi-la.Isso inclui todos os parâmetros de solicitação e dados recuperados do banco de dados que podem ser alterados pela entrada do usuário.

Como mencionado por Pat às vezes você desejará exibir algumas tags, mas não todas as tags.Uma maneira comum de fazer isso é usar uma linguagem de marcação como Têxtil, Remarcação, ou Código BBC.No entanto, mesmo as linguagens de marcação podem ser vulneráveis ​​ao XSS, apenas esteja ciente.

# Markup example
[foo](javascript:alert\('bar'\);)

Se você decidir permitir a passagem de tags "seguras", recomendo encontrar alguma biblioteca existente para analisar e higienizar seu código antes da saída.Há muitos vetores XSS por aí que você teria que detectar antes que seu desinfetante fosse razoavelmente seguro.

Answer 5

Segui o conselho do metavida para encontrar uma biblioteca de terceiros para lidar com a filtragem de saída.Neutralizar caracteres HTML é uma boa abordagem para impedir ataques XSS.No entanto, o código usado para transformar metacaracteres pode ser vulnerável a ataques de evasão;por exemplo, se não lidar adequadamente com Unicode e internacionalização.

Um erro clássico e simples que os filtros de saída do homebrew cometem é capturar apenas < e >, mas perder coisas como ", que pode dividir a saída controlada pelo usuário no espaço de atributos de uma tag HTML, onde o Javascript pode ser anexado ao DOM.

Answer 6

Não, apenas codificar tokens HTML comuns NÃO protege completamente o seu site contra ataques XSS.Veja, por exemplo, esta vulnerabilidade XSS encontrada em google.com:

http://www.securiteam.com/securitynews/6Z00L0AEUE.html

O importante sobre esse tipo de vulnerabilidade é que o invasor é capaz de codificar sua carga útil XSS usando UTF-7 e, se você não tiver especificado uma codificação de caracteres diferente em sua página, o navegador do usuário poderá interpretar a carga útil UTF-7 e execute o script de ataque.

Answer 7

Outra coisa que você precisa verificar é de onde vem sua opinião.Você pode usar a string de referência (na maioria das vezes) para verificar se é da sua própria página, mas colocar um número aleatório oculto ou algo assim em seu formulário e depois verificá-lo (talvez com uma variável de conjunto de sessão) também ajuda a saber que o a entrada vem do seu próprio site e não de algum site de phishing.

Answer 8

Eu gostaria de sugerir HTML Purifier (http://htmlpurifier.org/) Ele não apenas filtra o html, basicamente o tokeniza e o recompila.É verdadeiramente de força industrial.

Ele tem o benefício adicional de permitir que você garanta uma saída HTML/xhtml válida.

Também não é nada têxtil, é uma ótima ferramenta e eu a uso o tempo todo, mas também usaria um purificador de HTML.

Acho que você não entendeu o que eu quis dizer com tokens.O HTML Purifier não apenas 'filtra', ele realmente reconstrói o html. http://htmlpurifier.org/comparison.html

Answer 9

Eu não acredito nisso.Html Encode converte todos os caracteres funcionais (caracteres que podem ser interpretados pelo navegador como código) em referências de entidade que não podem ser analisadas pelo navegador e, portanto, não podem ser executadas.

<script/>

Não há como o acima ser executado pelo navegador.

**A menos que seja um bug no navegador, é claro.*