Solución para permitir la entrada de JavaScript pero evitar XSS

enlace tiene que ver con el cifrado y garantiza la identidad del servidor para evitar que otras personas escuchen el tráfico. Por lo tanto, no ayuda en absoluto contra el código JavaScript malicioso dentro de los límites de la misma política de origen.

Hay una marca en las cookies llamada enlace que evita el código JavaScript simple en el navegador moderno para acceder a la cookie. Pero esto no soluciona el problema , solo hace que las explotaciones sean un poco menos simples: el código JavaScript puede activar directamente los formularios con los permisos del usuario actual. Dado que el JavaScript está en el mismo dominio, tiene acceso a los tokens CSRF . El navegador incluirá la cookie en el envío del formulario sin que el código de JavaScript necesite acceder. (Y hay una serie de errores alrededor de HttpOnly, por ejemplo, algunos navegadores permiten leer la cookie desde un objeto XMLHttpRequest).

Además, el autor de JavaScript puede reemplazar el contenido de la página actual con "Su sesión ha expirado, vuelva a iniciar sesión" y su propio formulario de inicio de sesión . Pero la forma que agrega no apunta a la URL de inicio de sesión de su servidor, sino a un servidor que controla. O incluso más sutil, puede haber una llamada Ajax entre dominios en el controlador de eventos del botón de envío.

Hay una solución bastante simple en dos pasos:

1. Filtrar todo el marcado no confiable , incluido todo JavaScript. Si está utilizando PHP, puede usar HTML-Purifier . Hay bibliotecas similares para todos los idiomas comunes.
2. Proporcione marcadores de posición inofensivos ("widgets"). Entonces, en lugar de permitir que los usuarios incorporen el código JavaScript directamente, deben escribir algo como <div id="googleadd">identifier</div> . Una pieza de código JavaScript global de confianza puede reemplazar esos fragmentos de código con el código de adición real. Asegúrese de escapar adecuadamente los parámetros de entrada. Esto limitará un poco a sus usuarios en lo que pueden hacer, pero es bastante fácil cubrir todos los casos de uso comunes.

Tiene sentido buscar un poco en Google, ya que ya existen varias bibliotecas de widgets; aunque la mayoría de ellos aún requieren llamadas de JavaScript.

HTTPS no evita el robo de cookies, HTTPOnly flag sí lo hace. Recomendaría (si es posible) tener una biblioteca de "widgets" que los usuarios puedan incluir en la página y configurar. Luego, solo puede insertar el código JavaScript con los parámetros configurados sin permitir que el usuario escriba código JavaScript.

Si permite a sus usuarios insertar su propio código JavaScript, pueden hacer cosas como actualizar el formulario de inicio de sesión de su sistema de blogs para enviar credenciales a otro servidor, de modo que si algún usuario visita la página del blog malicioso y decide iniciar sesión Para su sistema en esa página, sus credenciales podrían verse comprometidas.

No, HTTPS no detiene esta amenaza.

Si a sus usuarios se les debe permitir incluir Javascript, han escrito en la página, este es un problema muy desafiante. Lo que quieres es una especie de caja de arena de Javascript . La recomendación de Caja de @Mike Samuel es una buena elección de la tecnología de sandboxing de Javascript. Otras posibilidades en este espacio incluyen la Web Sandbox de Microsoft, AdSafe de Yahoo, FBJS de Facebook y probablemente otras que me he perdido.

Comprenda que, si bien las soluciones existen, no serán completamente triviales de implementar. Te has topado con un problema difícil en la seguridad web; la web simplemente no fue diseñada para soportar este tipo de cosas, y como resultado, las soluciones necesariamente terminan siendo una pieza de tecnología bastante compleja. Por lo tanto, probablemente necesitará el apoyo de un desarrollador capaz para implementar e integrar una de estas soluciones en su sitio web.

Enchufe descarado, pero relevante:

Desde code.google.com/p/google-caja/

  

Caja permite a los sitios web incrustar de forma segura aplicaciones web DHTML de terceros, y permite una interacción rica entre la página de incrustación y las aplicaciones integradas. Utiliza un modelo de seguridad de capacidad de objetos para permitir una amplia gama de políticas de seguridad flexibles, de modo que la página contenedora pueda controlar efectivamente el uso de los datos de usuario de las aplicaciones integradas y permitir que los dispositivos eviten la interferencia entre los elementos de la interfaz de usuario de los dispositivos.

Si permites el seguimiento de google, ya permites XSS, porque google-analitics es por definición un XSS.

Puede configurar una plantilla donde el usuario solo pegaría su ID que usted podría desinfectar adecuadamente.

Nunca puedes permitir entradas de javascript y estar seguro. Intenta trabajar con el siguiente código. ¿Crees que es seguro? ¿Tiene alguna de las palabras clave que sugieren peligro? :)

$=''|'',_=$+!"",__=_+_,___=__+_,($)[_$=($$=(_$=""+{})[__+__+_])+_$[_]+(""+_$[-__])[_]+(""+!_)[___]+($_=(_$=""+!$)[$])+_$[_]+_$[__]+$$+$_+(""+{})[_]+_$[_]][_$]((_$=""+!_)[_]+_$[__]+_$[__+__]+(_$=""+!$)[_]+_$[$]+"("+_+")")();

Spoiler: es alert(1)

Por definición, almacenar javascript y representarlo en el navegador es XSS

1) Añadir identidad

2) Agregue una política de uso: enlace

3) Estoy en contra del servidor de filtrado de listas blancas / listas negras porque es una solución al problema principal, es difícil de hacer bien y puede eliminar información que no debería eliminarse. Cuando tenga HTML5, CSS3 y JS en constante evolución, deberá seguir actualizando su lista blanca / lista negra hasta que el desinfectante en su lugar se convierta en una gran cantidad de código que permita todo y, por lo tanto, llegará a un punto que anule su propósito. , pero si insistes en esta pista OWASP HTML Sanitizer, JSoup es otro ejemplo aparte de lo mencionado anteriormente.

4) En lugar de 3) use enlace y elimine el soporte para navegadores antiguos, que es la forma correcta de corregir esto como en el servidor solo almacenaría contenido pero ejecutaría en el contexto del navegador

5) Puede agregar etiquetas de plantilla / marcadores de posición para reducir el riesgo (por ejemplo, reducción de marca), esto también ayudará a que sus herramientas de control de prueba no devuelvan el eco; alerta (1); ya que el servidor esperaría una entrada diferente para almacenar y enviar el javascript

6) Ejecute AV y fortifique el analizador de código estático en el servidor y muévalo hacia adelante

7) Integrado en la validación de errores: JSLint / JSHint / CSSHint, etc

8) Finalmente, si no confía en ninguna de las automatizaciones anteriores, agregue el factor humano para revisar y aprobar el paso antes de publicar