Herramientas de desarrollo · Editor HTML WYSIWYG
Desinfección de HTML pegado: qué eliminar antes de que llegue a su CMS o correo electrónico
· Cómo funciona
html seguridad limpieza de texto
Explica lo que hace un desinfectante HTML, desde etiquetas y atributos incluidos en la lista permitida hasta scripts eliminados y URL neutralizadas, y cómo inspeccionar primero el marcado hace que las reglas del desinfectante sean más fáciles de escribir.
El fragmento pegado que contenía un clic: se abre con el riesgo oculto en la entrada de texto enriquecido
Un ancla pegada puede ocultar un clic al lado de un destino inocente. ToolAcre pone en minúsculas cada nombre de atributo y mantiene solo los atributos enumerados explícitamente para el elemento aceptado, por lo que onclick desaparece incluso cuando se modifica su mayúscula. El informe de eliminación identifica ese controlador de eventos en lugar de presentar silenciosamente la fuente sin cambios.
Este límite opera antes de insertar el pegado enriquecido, cuando la fuente vuelve al modo visual, antes de copiar, antes de la extracción de texto sin formato y nuevamente mientras se crean documentos de vista previa. La repetición reduce la omisión accidental entre acciones, pero el proyecto aún se niega a llamar al tokenizador escrito a mano un filtro XSS de uso general.
Por qué las listas permitidas superan a las listas bloqueadas: explica que nombrar lo que está permitido es más seguro que intentar enumerar todas las construcciones peligrosas
Una lista de permitidos comienza nombrando la estructura permitida: párrafos, encabezados, elementos semánticos en línea, listas, listas de descripción, citas, elementos tipo código y anclajes. Un contenedor ordinario desconocido pierde su etiqueta pero conserva el texto. Un contenedor peligroso como script, style, iframe, form, SVG o MathML también pierde su contenido.
Una lista de bloqueo debería anticipar cada construcción peligrosa o sin soporte. La lista de permitidos rechaza lo que no entiende. Esta es una buena opción para la salida restringida de un editor, pero sigue estando limitada por su tokenizador. La recuperación de errores HTML5 del navegador puede producir un árbol diferente a partir de un analizador más pequeño cuando se trata de una entrada deliberadamente mal formada.
Etiquetas, atributos y esquemas de URL: cubre las tres capas que filtra un desinfectante, con decisiones típicas para cada una.
El filtrado se produce en tres capas. Los elementos deciden el vocabulario estructural. Los atributos por elemento permiten sólo unos pocos valores, como href y título del enlace, cita de cita, título de abreviatura e inicio y tipo de lista ordenada. Luego, la inspección de URL decodifica entidades, elimina controles y espacios en blanco de una sonda y verifica el esquema resultante.
Los esquemas aceptados son http, https, mailto, tel y ftp, además de formularios relativos sin un esquema explícito. JavaScript, datos, archivos, blobs, vbscript y ejemplos relacionados se rechazan en las pruebas. Los enlaces supervivientes obtienen valores rel, pero esa adición no sustituye a la política de destino ni a la revisión de enlaces.
Estilos: eliminar, permitir o reescribir: analiza el manejo de estilos en línea y por qué muchos sistemas lo eliminan por completo.
Los atributos de estilo se eliminan al por mayor. El módulo no intenta analizar declaraciones, retener un subconjunto seguro ni reescribir tokens de diseño. Esa política elimina la apariencia copiada y las superficies de solicitud basadas en CSS juntas. Los atributos de clase, identificación y datos también desaparecen, lo que produce un marcado portátil pero deliberadamente menos expresivo.
Los sistemas con un requisito de estilo genuino necesitan una política revisada diferente. Agregar estilo a esta lista de permitidos sin un desinfectante CSS cambiaría materialmente su superficie de seguridad. La implementación actual evita ese problema en lugar de pretender resolver la seguridad de CSS para fragmentos hostiles arbitrarios.
Ejemplo resuelto: derivar la regla de la lista de permitidos documentada de ToolAcre, no de un dispositivo específico de Word
Comience con `<div class="WordSection"><p style="color:red" onclick="x()">Notice <strong>today</strong></p></div>`. El div se desenvuelve, la clase y el estilo no pueden sobrevivir, se elimina el clic y el párrafo más el elemento fuerte permanecen. El resultado sigue una política genérica sin afirmar qué aplicación produjo el contenedor.
Agregue un href de JavaScript y un bloque de script. El ancla mantiene sus palabras visibles pero pierde href; El guión y el cuerpo desaparecen. Lea los motivos informados. Este ejercicio ayuda a definir una política de servidor, pero copiar a ciegas el subconjunto exacto de ToolAcre puede omitir elementos que su aplicación requiere o permitir URL que su modelo de amenaza prohíbe.
Desinfección del lado del servidor versus del lado del cliente: explica por qué el servidor debe desinfectarse incluso si el navegador ya lo hizo
El filtrado de clientes mejora la redacción local, pero un servidor que recibe solicitudes controladas por el usuario no puede confiar en él. Los atacantes pueden omitir la página, llamar directamente a un punto final o aprovechar una diferencia del analizador. El servidor debe analizar y desinfectar nuevamente con una implementación compatible con HTML5 mantenida y configurada para su contexto de representación.
La codificación de salida también permanece separada. La plantilla debe utilizar como escape el HTML pensado como texto en lugar de insertarlo como marcado. Un fragmento renderizado intencionalmente como HTML necesita desinfección antes de almacenarse o generarse de acuerdo con la arquitectura. Una vista previa en el espacio aislado solo demuestra que esta vista previa no otorga scripts, formularios ni acceso del mismo origen.
Qué cubre esta herramienta: filtrado limitado de resultados del editor, no desinfección general de entradas hostiles
ToolAcre filtra su propia superficie de salida, contrariamente a la afirmación del libro de que es simplemente una herramienta de inspección. La corrección exacta es más limitada: no es un desinfectante XSS de uso general para entradas hostiles arbitrarias. La fuente dice esto explícitamente y documenta un posible diferencial de analizador.
El iframe es una defensa en profundidad para el renderizado dentro de ToolAcre. Su atributo de zona de pruebas vacía no otorga ejecución de script, envío de formularios ni acceso del mismo origen, y la política de referencia es sin referencia. Una vez que se copia HTML en otro lugar, ese marco ya no lo protege. La seguridad de la publicación pertenece al sistema receptor.
Conclusión: inspeccionar localmente, desinfectar en el servidor: resume el flujo de trabajo y cómo el editor le ayuda a ver a qué se enfrentará un desinfectante
Inspeccionar localmente, desinfectar en el servidor y renderizar según el contexto. Esos son tres pasos distintos. ToolAcre ayuda a revelar el equipaje pegado y ofrece un subconjunto de borradores conservador, mientras que los avisos de eliminación hacen visibles los efectos de las políticas antes de que un fragmento llegue a un CMS o flujo de trabajo de correo electrónico.
No comercialice una vista previa exitosa como prueba contra XSS. Utilice cargas útiles de prueba solo en contenido desechable, conserve la fuente sin procesar por separado cuando la investigación sea importante y verifique la desinfección del destino de forma independiente. Las afirmaciones de seguridad deben terminar exactamente donde terminan el código y el límite de representación.