shoucheng3/nahsra__antisamy_cve-2017-14735_1-5-6Biblioteca Java para sanitização rápida e configurável de HTML de fontes não confiáveis. Utiliza varredura orientada por políticas para remover JavaScript e CSS maliciosos, prevenindo ataques XSS em aplicações web.
Uma biblioteca para realizar limpeza rápida e configurável de HTML proveniente de fontes não confiáveis. Suporta Java 8+.
Outra forma de dizer isso poderia ser: é uma API que ajuda você a garantir que os clientes não forneçam código malicioso no HTML que eles fornecem 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 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.
Ao longo do desenvolvimento da série 1.6.x, identificamos e descontinuamos vários recursos e APIs. Todos esses itens descontinuados foram removidos na versão 1.7.0. Essas mudanças foram todas registradas na issue: https://github.com/nahsra/antisamy/issues/195. Cada uma das mudanças está descrita abaixo:
CssHandler tinha 2 construtores que removiam o parâmetro LinkedList<URI> embeddedStyleSheets. Ambos os construtores agora criam um LinkedList<URI> interno vazio e o método getImportedStylesheetsURIList() pode ser usado para obter uma referência a ele, se necessário. Esse recurso é raramente utilizado e, de fato, a invocação direta desses construtores também é rara, portanto, essa mudança provavelmente não afetará a maioria dos usuários do AntiSamy. Quando usado, normalmente uma lista vazia é passada como valor desse parâmetro e essa lista nunca mais é usada.
A assinatura CssHandler(Policy, LinkedList<URI>, List<String>, ResourceBundle) foi removida
CssHandler(Policy, List<String>, ResourceBundle)A assinatura CssHandler(Policy, LinkedList<URI>, List<String>, String, ResourceBundle) foi removida
CssHandler(Policy, List<String>, ResourceBundle, String). NOTA: A ordem dos últimos 2 parâmetros deste método foi invertida.O suporte para XHTML foi removido. O AntiSamy agora suporta apenas HTML. Como acreditamos que esse era um recurso raramente utilizado, não esperamos que isso afete muitos usuários do AntiSamy.
A validação de esquema XML agora é obrigatória nos arquivos de política do AntiSamy e não pode ser desabilitada. Você deve tornar seu arquivo de política compatível com o esquema para usá-lo com o AntiSamy.
A diretiva de política noopenerAndNoreferrerAnchors agora está ATIVADA por padrão. Se estiver desabilitada, o AntiSamy emite um aviso, incentivando você a ativá-la.
Ao longo do ciclo de vida de atualização do AntiSamy, a dependência do analisador HTML sofreu alterações, levando a algumas diferenças na saída que podem surgir dependendo do caso de uso. Considere isso se você estava usando certas versões e obtém saídas diferentes após a atualização.
Isso também pode se aplicar ao serializador de saída que transforma a representação HTML interna na saída final de texto da ferramenta.
A equipe do AntiSamy decidiu que suportar a capacidade de permitir CSS remoto incorporado é perigoso e, portanto, estamos descontinuando esse recurso e ele será removido em uma versão futura. Espera-se que haja muito poucos, se é que existem, usuários desse recurso.
Adicionamos um aviso (WARN) no log se esse recurso for invocado. Se você estiver usando, desabilite/remova esse recurso trocando para o construtor primário CssScanner que não habilita esse recurso.
Primeiro, adicione a dependência do Maven:
<dependency>
<groupId>org.owasp.antisamy</groupId>
<artifactId>antisamy</artifactId>
<version>LATEST_VERSION</version>
</dependency>
Provavelmente, o caso de uso do seu site para AntiSamy é 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. Agora, Slashdot não é apenas um dos sites mais legais por aí, mas também um que foi alvo de muitos ataques bem-sucedidos diferentes. As regras para Slashdot são bastante rigorosas: os usuários só podem enviar as seguintes tags HTML e nenhum CSS: <b>, <u>, <i>, <a>, <blockquote>.
Consequentemente, 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 podemos dizer. É um site público, então qualquer um pode postar 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, Slashdot — portanto, sua superfície de ataque é consideravelmente maior.
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, e é por isso que 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 conhecemos um possível caso de uso 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 óbvios relacionados a CSS), você pode usar este arquivo de política. Nem mesmo o MySpace era tão louco. No entanto, ele serve como uma boa referência porque contém regras base para cada elemento, então você pode usá-lo como uma base de conhecimento ao personalizar os outros arquivos de política.
O AntiSamy agora inclui a biblioteca slf4j-simple para seu logging, mas os usuários do AntiSamy podem importar e usar uma biblioteca de logging alternativa compatível com slf4j, se preferirem. Eles também podem excluir slf4j-simple, se desejarem.
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 Exception, como uma PolicyException, for lançada. Isso pode provavelmente ser corrigido configurando 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 rigorosas, orientadas por negócios, 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.
Políticas de exemplo podem ser adaptadas e testadas com base nos requisitos de cada tag. As ações de tag suportadas que podem ser especificadas são:
filter: remove tags, mas mantém o conteúdo.validate: mantém o conteúdo desde que passe nas regras.remove: remove a tag e o conteúdo.truncate: remove os atributos da tag e todas as tags filhas, exceto seu conteúdo de texto, se houver.encode: semelhante a filter, mas codifica a tag para HTML para preservá-la como texto bruto e seus filhos são movidos um nível acima na hierarquia.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 arquivoFileInputStreamPolicy também podem ser referenciados pelo nome do arquivo passando um segundo argumento para o método AntiSamy#scan(), como mostram os exemplos a seguir:AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);
Finalmente, os arquivos de política também podem ser referenciados por objetos File diretamente no segundo parâmetro:
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));
O objeto CleanResults fornece muitas informações úteis.
getCleanHTML() - a saída HTML limpa e seguragetCleanXMLDocumentFragment() - o XMLDocumentFragment limpo e seguro que é refletido em getCleanHTML()getErrorMessages() - uma lista de mensagens de erro do tipo String — se retornar 0, isso não significa que não houve ataques!getNumberOfErrors() - o número de mensagens de erro — Novamente, 0 não significa que a entrada era segura!getScanTime() - retorna o tempo de digitalização em segundosNota Importante: Tem havido muita confusão sobre o método getErrorMessages(). O método getErrorMessages() (nem getNumberOfErrors()) 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 perda de informações e filtrará ataques por meio de vários vetores de ataque. Infelizmente, uma das desvantagens dessa estratégia é que o AntiSamy nem sempre sabe em retrospecto que um ataque foi visto. Assim, as APIs getErrorMessages() e getNumberOfErrors() existem 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, entre em contato diretamente com Dave Wichers (dave.wichers at owasp.org). Por favor, não relate vulnerabilidades através de issues do GitHub, pois queremos manter nossos usuários seguros enquanto um patch é implementado e implantado. Se você deseja ser reconhecido por encontrar a vulnerabilidade, siga este processo.
Mais detalhes estão disponíveis no arquivo: SECURITY.md.
Você pode construir 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.