Qual é a diferença entre AntiXss.HtmlEncode e HttpUtility.HtmlEncode?

Question

Eu corri através de uma pergunta com uma resposta sugerindo a biblioteca AntiXSS para evitar cross site scripting. Pareceu interessante, lendo o msdn blogue , parece apenas fornecer um HtmlEncode () método. Mas eu já usam HttpUtility.HtmlEncode ().

Por que eu iria querer usar AntiXss.HtmlEncode sobre HttpUtility.HtmlEncode?

Na verdade, eu não sou o primeiro a fazer esta pergunta. E, de fato, o Google vira para cima alguns responde principalmente

• A-lista branca em vez de abordagem black-list
• A 0,1ms melhoria de desempenho

Bem, isso é bom, mas o que isso significa para mim? Eu não me importo tanto com o desempenho de 0,1 ms e eu realmente não sinto como fazer o download e adicionando outra dependência biblioteca para a funcionalidade que eu já tenho.

Existem exemplos de casos em que a implementação AntiXSS impeçam um ataque que o HttpUtility implementação não gostaria?

Se eu continuar a usar a implementação HttpUtility, estou em risco? E sobre esta 'bug' ?

Answer 1

Eu não tenho uma resposta especificamente à sua pergunta, mas eu gostaria de salientar que a lista branca vs abordagem lista negra não apenas "nice". É importante. Muito importante. Quando se trata de segurança, cada pequena coisa é importante. Lembre-se que, com cross-site scripting e cross-site request forgery , mesmo se o site não está mostrando dados sensíveis, um hacker pode infectar o seu site através da injeção de javascript e usá-lo para obter dados confidenciais a partir de outro site. Então, fazendo a coisa certa é fundamental.

diretrizes

OWASP especificar utilizando uma abordagem de lista branca . diretrizes PCI Compliance também especificar isso em padrões de codificação (uma vez que eles se referem tot ele OWASP diretrizes).

Além disso, a versão mais recente da biblioteca AntiXSS tem um bom nova função:. .GetSafeHtmlFragment () que é bom para os casos em que você deseja armazenar HTML no banco de dados e apresentá-lo para o usuário como HTML

Além disso, como para o "bug", se você está programando corretamente e seguindo todas as diretrizes de segurança, você está usando procedimentos armazenados parametrizados, por isso as aspas simples serão tratados corretamente, Se você não está de codificação corretamente, não fora a biblioteca prateleira vai protegê-lo totalmente. A biblioteca AntiXSS pretende ser uma ferramenta a ser utilizada, não um substituto para o conhecimento. Baseando-se na biblioteca para fazer o certo para você estaria esperando um bom pincel para vir boas pinturas sem um bom artista.

Editar - Adicionado

Como solicitado na pergunta, um exemplo de onde o anti XSS irá proteger você e HttpUtility não:

HttpUtility.HtmlEncode e Server. HtmlEncode não impedem Cross Site Scripting

Isso de acordo com o autor, no entanto. Eu não testei isso pessoalmente.

---

Parece que você está fazendo em suas diretrizes de segurança, por isso pode não ser algo que eu preciso te dizer, mas apenas no caso de um desenvolvedor menos experiente é lá fora lendo isto, a razão de eu dizer que a lista branca abordagem é fundamental é esta.

Agora, hoje, HttpUtility.HtmlEncode podem bloquear com sucesso todos os ataques lá fora, simplesmente removendo / codificação < e >, além de alguns outros "conhecido potencialmente inseguro" personagens, mas alguém está sempre tentando pensar em novas formas de arrombando. Permitindo (lista branca) conteúdo apenas conhecido de segurança é muito mais fácil do que tentar pensar em cada bocado inseguro possível de entrada de um atacante poderia atirar em você (abordagem black-list).

Answer 2

Em termos de por que você usaria um sobre o outro, consideram que a biblioteca AntiXSS fica liberado mais frequentemente do que o framework ASP.NET - já que, como David Stratton diz 'alguém está sempre tentando pensar em novas maneiras de quebrar in', quando alguém vem com uma biblioteca AntiXSS é muito mais provável para obter uma versão atualizada para se defender contra ele.

Answer 3

O que se segue são as diferenças entre os métodos e Microsoft.Security.Application.AntiXss.HtmlEncode System.Web.HttpUtility.HtmlEncode:

1. Anti-XSS utiliza a técnica à lista branca, por vezes referido como o princípio de inclusões, para fornecer proteção contra ataques de cross-site scripting (XSS). Esta abordagem funciona através da definição de um conjunto válido ou permitido de caracteres, e codifica qualquer coisa fora deste conjunto (caracteres inválidos ou ataques potenciais). System.Web.HttpUtility.HtmlEncode e outros métodos de codificação em que o princípio use namespace de exclusões e codificar apenas determinados caracteres designados como potencialmente perigosa, como <,> caracteres, & e '.

2. lista de caracteres brancos (ou seguro) de O Anti-XSS Biblioteca suportar mais de uma dúzia de idiomas (gregos e coptas, cirílico, cirílico do suplemento, armênios, hebraico, árabe, siríaco, Suplemento Árabe, Thaana, Nko e more)

3. biblioteca

   Anti-XSS foi projetado especialmente para mitigar ataques XSS enquanto que os métodos HttpUtility codificação são criados para garantir que a saída ASP.NET não quebra HTML.

4. Performance - o delta média entre AntiXss.HtmlEncode() e HttpUtility.HtmlEncode() é +0,1 milissegundos por transação.

5. Anti-XSS Versão 3.0 fornece um equipamento de teste que permite aos desenvolvedores executar tanto a validação XSS e testes de desempenho.

Answer 4

vulnerabilidades mais XSS (qualquer tipo de vulnerabilidade, na verdade) são puramente baseado no fato de que a segurança existente não "espera" que certas coisas aconteçam. Whitelist somente abordagens são mais aptos a lidar com esses cenários por padrão.

Answer 5

Nós usamos a abordagem de lista branca para sites Windows Live da Microsoft. Tenho certeza de que há uma série de ataques de segurança que não tenha pensado ainda, então eu estou mais confortável com a abordagem paranóica. Eu suspeito que tem havido casos em que a lista negra vulnerabilidades que a lista de White não expostos, mas eu não poderia dizer-lhe os detalhes.