Hay muchas preguntas desbordamiento de pila (por ejemplo Whitelisting, preventing XSS with WMD control in C# y WMD Markdown and server-side) acerca de cómo hacer lavado del lado del servidor de Markdown producido por el editor de armas de destrucción masiva para asegurar el HTML generado no contiene código malicioso, como esto:alineado en vista previa del editor de armas de destrucción masiva HTML con HTML de validación del lado del servidor (por ejemplo, no hay código JavaScript incrustado)
<img onload="alert('haha');"
src="http://www.google.com/intl/en_ALL/images/srpr/logo1w.png" />
Pero no me pareció una buena manera de tapar el agujero en el lado del cliente también. La validación del cliente no es un reemplazo para la depuración de validación en el servidor, por supuesto, ya que cualquiera puede pretender ser un cliente y PUBLICAR un desagradable Markdown. Y si está limpiando el HTML en el servidor, un atacante no puede guardar el HTML incorrecto para que nadie más pueda verlo más tarde y sus secuencias de comandos incorrectas le roben las cookies o las sesiones. Por lo tanto, hay un caso válido que puede que no valga la pena aplicar las reglas sin guiones también en el panel de vista previa de WMD.
Pero imagine que un atacante encontró la forma de obtener un Markdown malicioso en el servidor (por ejemplo, un feed comprometido de otro sitio o contenido agregado antes de que se solucionara un error de XSS). La lista blanca del lado del servidor que se aplicó al traducir el marcado a HTML normalmente evitaría que el Mal marcado se muestre a los usuarios. Pero si el atacante logra que alguien edite la página (por ejemplo, publicando otra entrada que dice que la entrada maliciosa tiene un enlace roto y le pide a alguien que la solucione), cualquiera que edite la página obtiene sus cookies secuestradas. Es cierto que es un caso de esquina, pero aún puede valer la pena defenderse.
Además, probablemente sea una mala idea permitir que la ventana de vista previa del cliente permita diferentes HTML de los que permita su servidor.
El equipo de Stack Overflow ha conectado este agujero haciendo cambios a WMD. ¿Cómo lo hicieron?
[NOTA: Ya me di cuenta de esto, pero se requería una depuración de JavaScript complicada, así que estoy respondiendo mi propia pregunta aquí para ayudar a otros que quieran hacer lo mismo].
No estoy seguro de que esto sea algo que deba solucionarse. Parece una solución en busca de un problema. Quizás la razón por la que no ve este código en la versión de StackOverflow de WMD es porque no existe, porque no es necesario. –
Sí, no estoy convencido de que sea necesario tampoco. Dicho esto, los chicos de StackOverflow.com implementaron esto con el fin de garantizar que la vista previa nunca generara HTML que su validador del lado del servidor no aceptaría. Parece razonable, aunque no estoy muy de acuerdo. Consulte http://meta.stackexchange.com/questions/1227/preview-should-match-the-posted-view para obtener más detalles sobre por qué SO lo hizo. Por cierto, acabo de editar mi pregunta para alinearla con la razón real por la que SO quería hacer esto. –
Podría AJAX publicar el HTML y recuperar el HTML desinfectado del servidor, para obtener una vista previa perfecta. – ceejayoz