shoucheng3/nahsra__antisamy_cve-2022-29577_1-6-6-1Biblioteca Java para limpeza rápida e configurável de HTML não confiável para prevenir ataques de cross-site scripting (XSS). Utiliza varredura baseada em políticas para sanitizar marcação fornecida pelo usuário.
Uma biblioteca para realizar limpeza rápida e configurável de HTML proveniente de fontes não confiáveis. Suporta Java 7+.
Outra forma de dizer isso seria: é uma API que ajuda a garantir que os clientes não forneçam código malicioso no HTML que enviam para seus perfis, comentários, etc., que são persistidos no servidor. O termo "código malicioso" em relação a aplicações web geralmente significa "JavaScript". Na maioria das vezes, as Folhas de Estilo em Cascata (CSS) só são consideradas maliciosas quando invocam JavaScript. No entanto, existem muitas situações em que HTML e CSS "normais" podem ser usados de forma maliciosa.
Primeiro, adicione a dependência do Maven:
<dependency>
<groupId>org.owasp.antisamy</groupId>
<artifactId>antisamy</artifactId>
<version>LATEST_VERSION</version>
</dependency>
É provável que o caso de uso do seu site para o AntiSamy seja pelo menos aproximadamente comparável a um dos arquivos de política predefinidos. Cada um representa um cenário "típico" para permitir que os usuários forneçam formatação HTML (e possivelmente CSS). Vamos analisar os diferentes arquivos de política:
Slashdot é um site de notícias de tecnologia que permite que os usuários respondam anonimamente a postagens de notícias com marcação HTML muito limitada. Slashdot não é apenas um dos sites mais legais por aí, como também foi alvo de muitos ataques bem-sucedidos. As regras para o Slashdot são bastante rígidas: os usuários só podem enviar as seguintes tags HTML e nenhum CSS: , , , , .
<b><u><i><a><blockquote>Dessa forma, construímos um arquivo de política que permite funcionalidades bastante semelhantes. Todas as tags de formatação de texto que operam diretamente na fonte, cor ou ênfase foram permitidas.
eBay é o site de leilões online mais popular do universo, pelo que posso dizer. É um site público, então qualquer pessoa pode publicar listagens com conteúdo HTML rico. Não é surpreendente que, dada a atratividade do eBay como alvo, ele tenha sido alvo de alguns ataques XSS complexos. As listagens podem conter conteúdo muito mais rico do que, digamos, o Slashdot — portanto, sua superfície de ataque é consideravelmente maior.
O MySpace era, na época em que este projeto nasceu, o site de rede social mais popular. Os usuários podiam enviar praticamente todo o HTML e CSS que quisessem — desde que não contivesse JavaScript. O MySpace usava uma lista negra de palavras para validar o HTML dos usuários, razão pela qual foi alvo do infame worm Samy. O worm Samy, que usava ataques de fragmentação combinados com uma palavra que deveria ter sido bloqueada (eval), foi a inspiração para este projeto.
Não conheço um caso de uso possível para este arquivo de política. Se você quisesse permitir todos os elementos HTML e CSS válidos (mas sem JavaScript ou ataques de phishing relacionados a CSS), você pode usar este arquivo de política. Nem mesmo o MySpace era tão louco assim. No entanto, ele serve como uma boa referência porque contém regras básicas para cada elemento, então você pode usá-lo como base de conhecimento ao personalizar os outros arquivos de política.
Enquanto trabalhávamos em algumas melhorias na Definição do Schema XML (XSD) do AntiSamy para arquivos de política, notamos que o AntiSamy NÃO estava realmente aplicando o XSD. Portanto, MUDAMOS o comportamento padrão a partir do AntiSamy 1.6.0 para aplicar o schema e não continuar se a política do AntiSamy for inválida. No entanto...
reconhecemos que pode não ser possível para os desenvolvedores corrigirem suas políticas do AntiSamy imediatamente se elas não estiverem em conformidade, mas ainda assim desejarem atualizar o AntiSamy para obter melhorias de segurança, novos recursos e correções de bugs. Dessa forma, fornecemos duas maneiras de desabilitar (temporariamente!) a validação do schema:
Defina a propriedade de sistema Java: owasp.validator.validateschema como false. Isso pode ser feito na linha de comando (ex.: -Dowasp.validator.validateschema=false) ou através do arquivo de propriedades do sistema Java. Nenhuma alteração de código é necessária.
Altere o código que usa o AntiSamy para invocar: Policy.setSchemaValidation(false) antes de carregar a política do AntiSamy. Esta é uma chamada estática, portanto, uma vez desabilitada, fica desabilitada para todas as novas instâncias de Policy.
Para incentivar os usuários do AntiSamy a usar apenas políticas compatíveis com XSD, o AntiSamy sempre registrará algum tipo de aviso quando a validação do schema estiver desabilitada. Ele irá AVISAR que a política não está em conformidade para que possa ser corrigida, ou AVISAR que a política está em conformidade, mas a validação do schema está DESLIGADA, portanto, a validação deve ser reativada (ou seja, parar de desabilitá-la). Também adicionamos registro em nível INFO quando os schemas do AntiSamy são carregados e validados.
A capacidade de desabilitar o novo recurso de validação do schema é temporária, para suavizar a transição para arquivos de política do AntiSamy devidamente válidos. Planejamos remover esse recurso na próxima versão principal. Estimamos que isso ocorrerá em meados/finais de 2022, então não tão cedo. A ideia é dar às equipes de desenvolvimento que usam o AntiSamy diretamente ou através de outras bibliotecas como ESAPI tempo suficiente para que seus arquivos de política estejam em conformidade com o schema antes que a validação do schema se torne obrigatória.
Isso foi rapidamente corrigido no 1.6.1 para usar apenas APIs slf4j. O AntiSamy agora inclui a biblioteca slf4j-simple para seu log, mas os usuários do AntiSamy podem importar e usar uma biblioteca de log alternativa compatível com slf4j, se preferirem. Eles também podem, se quiserem, excluir slf4j-simple.
AVISO: O uso do slf4j-simple pelo AntiSamy, sem nenhum arquivo de configuração, registra mensagens de forma bufferizada na saída padrão. Como tal, algumas ou todas essas mensagens de log podem ser perdidas se uma Exceção, como uma PolicyException, for lançada. Isso provavelmente pode ser corrigido configurando o slf4j-simple para registrar no erro padrão, ou usando um logger slf4j alternativo que faça isso.
Você pode querer implantar o AntiSamy em uma configuração padrão, mas é igualmente provável que um site queira ter regras estritas, orientadas pelo negócio, sobre o que os usuários podem permitir. A discussão que decide a personalização também deve considerar a superfície de ataque — que cresce em proporção relativa ao arquivo de política.
Usar o AntiSamy é fácil. Aqui está um exemplo de invocação do AntiSamy com um arquivo de política:
import org.owasp.validator.html.*;
Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);
MyUserDAO.storeUserProfile(cr.getCleanHTML()); // alguma função personalizada
Existem algumas maneiras de criar um objeto Policy. O método getInstance() pode receber qualquer um dos seguintes:
String com o nome do arquivoFileInputStreamAntiSamy#scan(), como mostram os exemplos a seguir:AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);
Finalmente, arquivos de política também podem ser referenciados diretamente por objetos File no segundo parâmetro:
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));
O objeto CleanResults fornece muitas coisas úteis.
getErrorMessages() - uma lista de mensagens de erro do tipo String -- se retornar 0, isso não significa que não houve ataques!getCleanHTML() - a saída HTML limpa e seguragetCleanXMLDocumentFragment() - o XMLDocumentFragment limpo e seguro que é refletido em getCleanHTML()getScanTime() - retorna o tempo de varredura em segundosNota Importante: Houve muita confusão sobre o método getErrorMessages(). O método getErrorMessages() não responde sutilmente à pergunta "esta entrada é segura?" de forma afirmativa se retornar uma lista vazia. Você deve sempre usar a entrada sanitizada e não há como ter certeza de que a entrada passada não continha ataques.
O processo de serialização e desserialização que é crítico para a eficácia do sanitizador é propositalmente com perdas e filtrará ataques por meio de vários vetores de ataque. Infelizmente, uma das desvantagens dessa estratégia é que nem sempre sabemos retrospectivamente que um ataque foi visto. Assim, a API getErrorMessages() existe para ajudar os usuários a entender se sua entrada bem-intencionada atende aos requisitos do sistema, e não para ajudar um desenvolvedor a detectar se um ataque estava presente.
Documentação adicional está disponível na página wiki deste projeto no Github: https://github.com/nahsra/antisamy/wiki e na Página do Projeto OWASP AntiSamy: https://owasp.org/www-project-antisamy/
Se você encontrou um bug, crie uma issue no repositório do AntiSamy: https://github.com/nahsra/antisamy/issues
Se você encontrou uma vulnerabilidade no AntiSamy, primeiro pesquise na lista de issues (veja acima) para ver se já foi relatada. Se não foi, entre em contato diretamente com Dave Wichers (dave.wichers at owasp.org). Por favor, não relate vulnerabilidades via issues do GitHub, pois desejamos manter nossos usuários seguros enquanto um patch é implementado e implantado. Se você deseja ser reconhecido por ter encontrado a vulnerabilidade, siga este processo.
Mais detalhes estão disponíveis no arquivo: SECURITY.md.
Você pode compilar e testar a partir do código fonte facilmente:
$ git clone https://github.com/nahsra/antisamy
$ cd antisamy
$ mvn package
Lançado sob a licença BSD-3-Clause conforme especificado aqui: LICENSE.