Ferramentas para desenvolvedores · Editor HTML WYSIWYG
Sanitizante colado HTML: O que remover antes que chegue ao seu CMS ou e-mail
· Como funciona
HTML segurança limpeza de texto
Explica o que um higienizador HTML faz, desde tags e atributos permitidos até scripts removidos e URLs neutralizados, e como inspecionar a marcação primeiro torna as regras do higienizador mais fáceis de escrever.
O snippet colado que continha um onclick — abre com o risco oculto na entrada de rich text
Uma âncora colada pode ocultar um clique ao lado de um destino inocente. ToolAcre coloca todos os nomes de atributos em letras minúsculas e mantém apenas os atributos explicitamente listados para o elemento aceito, portanto, onclick desaparece mesmo quando sua caixa é alterada. O relatório de remoção identifica esse manipulador de eventos em vez de apresentar silenciosamente a fonte inalterada.
Esse limite opera antes da inserção do rich paste, quando a fonte retorna ao modo visual, antes da cópia, antes da extração de texto simples e novamente durante a construção de documentos de visualização. A repetição reduz o desvio acidental entre as ações, mas o projeto ainda se recusa a chamar o tokenizador manuscrito de filtro XSS de uso geral.
Por que as listas de permissão superam as listas de bloqueio — explica que nomear o que é permitido é mais seguro do que tentar listar todas as construções perigosas
Uma lista de permissões começa nomeando a estrutura permitida: parágrafos, títulos, elementos semânticos embutidos, listas, listas de descrição, citações, elementos semelhantes a código e âncoras. Um wrapper comum desconhecido perde sua tag enquanto retém o texto. Um contêiner perigoso como script, estilo, iframe, formulário, SVG ou MathML também perde seu conteúdo.
Uma lista de bloqueios precisaria antecipar todas as construções perigosas ou sem suporte. A lista de permissões rejeita o que não entende. Essa é uma escolha forte para a saída restrita de um editor, mas permanece limitada pelo seu tokenizador. A recuperação de erros do navegador HTML5 pode produzir uma árvore diferente de um analisador menor quando uma entrada deliberadamente malformada está envolvida.
Tags, atributos e esquemas URL — cobrem as três camadas que um desinfetante filtra, com decisões típicas para cada uma
A filtragem ocorre em três camadas. Os elementos decidem o vocabulário estrutural. Os atributos por elemento permitem apenas alguns valores, como link href e título, citação de citação, título de abreviatura e início e tipo de lista ordenada. A inspeção URL então decodifica entidades, remove controles e espaços em branco de uma sonda e verifica o esquema resultante.
Os esquemas aceitos são http, https, mailto, tel e ftp, além de formulários relativos sem esquema explícito. JavaScript, dados, arquivo, blob, vbscript e exemplos about são recusados nos testes. Os links sobreviventes ganham valores rel, mas essa adição não substitui a política de destino ou a revisão do link.
Estilos: remover, permitir ou reescrever — discute o tratamento de estilo in-line e por que muitos sistemas o abandonam completamente
Os atributos de estilo são removidos em massa. O módulo não tenta analisar declarações, reter um subconjunto seguro ou reescrever tokens de design. Essa política remove a aparência copiada e as superfícies de solicitação baseadas em CSS juntas. Os atributos de classe, id e dados também desaparecem, produzindo uma marcação portátil, mas deliberadamente menos expressiva.
Sistemas com requisitos de estilo genuínos precisam de uma política revisada diferente. Adicionar estilo a esta lista de permissões sem um desinfetante CSS alteraria materialmente sua superfície de segurança. A implementação atual evita esse problema em vez de pretender resolver a segurança CSS para fragmentos hostis arbitrários.
Exemplo resolvido: derivar a regra da lista de permissões documentada de ToolAcre, não de um acessório específico do Word
Comece com `<div class="WordSection"><p style="color:red" onclick="x()">Notice <strong>today</strong></p></div>`. O div é desembrulhado, a classe e o estilo não podem sobreviver, o onclick é removido e o parágrafo mais o elemento forte permanecem. O resultado segue uma política genérica sem afirmar qual aplicativo produziu o wrapper.
Adicione um href javascript e um bloco de script. A âncora mantém suas palavras visíveis, mas perde href; o roteiro e o corpo desaparecem. Leia os motivos relatados. Este exercício ajuda a definir uma política de servidor, mas copiar cegamente o subconjunto exato de ToolAcre pode omitir elementos que seu aplicativo exige ou permitir URLs que seu modelo de ameaça proíbe.
Sanitização do lado do servidor versus do lado do cliente – explica por que o servidor deve higienizar mesmo que o navegador já tenha feito isso
A filtragem do cliente melhora o desenho local, mas não pode ser confiável para um servidor que recebe solicitações controladas pelo usuário. Os invasores podem ignorar a página, chamar um endpoint diretamente ou explorar uma diferença de analisador. O servidor deve analisar e higienizar novamente com uma implementação mantida com reconhecimento de HTML5 configurada para seu contexto de renderização.
A codificação de saída também permanece separada. HTML pretendido como texto deve ser escapado pelo modelo em vez de inserido como marcação. Um fragmento renderizado intencionalmente como HTML precisa de sanitização antes do armazenamento ou saída de acordo com a arquitetura. Uma visualização em área restrita prova apenas que essa visualização não concede scripts, formulários ou acesso à mesma origem.
O que esta ferramenta cobre – filtragem restrita de saída do editor, não limpeza geral de entrada hostil
ToolAcre filtra sua própria superfície de saída, ao contrário da afirmação da pasta de trabalho de que é apenas uma ferramenta de inspeção. A correção precisa é mais restrita: não é um desinfetante XSS de uso geral para entradas hostis arbitrárias. A fonte diz isso explicitamente e documenta um possível diferencial do analisador.
O iframe é uma defesa profunda para renderização dentro de ToolAcre. Seu atributo sandbox vazio não concede execução de script, envio de formulário ou acesso à mesma origem, e a política de referência não é de referência. Depois que HTML for copiado em outro lugar, esse quadro não o protegerá mais. A segurança da publicação pertence ao sistema receptor.
Conclusão: inspecionar localmente, higienizar no servidor — resume o fluxo de trabalho e como o editor ajuda você a ver o que um desinfetante enfrentará
Inspecione localmente, higienize no servidor e renderize de acordo com o contexto. Essas são três etapas distintas. ToolAcre ajuda a revelar a bagagem colada e oferece um subconjunto conservador de rascunhos, enquanto os avisos de remoção tornam os efeitos da política visíveis antes que um fragmento chegue a um CMS ou fluxo de trabalho de e-mail.
Não comercialize uma visualização bem-sucedida como prova contra XSS. Use cargas de teste apenas em conteúdo descartável, preserve a fonte bruta separadamente quando a investigação for importante e verifique a higienização do destino de forma independente. As reivindicações de segurança devem parar exatamente onde o código e o limite de renderização param.