Desde v3.3.0.beta1, Discourse implementa una Política de Seguridad de Contenido (CSP) ‘strict-dynamic’. Esto eliminará la necesidad de configuración manual de CSP y mejorará en gran medida la compatibilidad con herramientas externas como gestores de etiquetas y publicidad.
Como administrador del sitio, no necesitas hacer nada. El cambio surtirá efecto automáticamente y los scripts externos que estés utilizando seguirán funcionando.
No se requieren cambios para los temas. Un pequeño número de plugins [1] pueden necesitar un pequeño ajuste para ser compatibles con este cambio (por ejemplo, 1, 2).
Los foros que anteriormente deshabilitaron CSP por compatibilidad con scripts externos ahora deberían poder volver a habilitarlo sin problemas ni esfuerzo de configuración.
Para los detalles técnicos, consulta este tema:
Por ahora, todavía es posible volver al sistema anterior deshabilitando la configuración del sitio ‘content security policy strict dynamic’. Si tienes alguna razón para hacerlo, ¡háznoslo saber!
Desde v3.3.0.beta3, hemos hecho que la palabra clave ‘strict-dynamic’ sea una parte obligatoria de nuestra CSP. Se ha eliminado la configuración del sitio ‘content security policy strict dynamic’ y la configuración del sitio ‘content security policy script src’ se ha actualizado para almacenar solo valores válidos.
Para los administradores, deberían poder encontrar el valor anterior de la configuración del sitio ‘content security policy script src’ en los Registros de Acciones del Personal de su sitio (https://<url_del_sitio>/admin/logs/staff_action_logs?filters=%7B%22action_name%22%3A%22change_site_setting%22%2C%22action_id%22%3A3%2C%22subject%22%3A%22content_security_policy_script_src%22%7D - Reemplace <url_del_sitio> con la URL base de su sitio).
técnicamente: aquellos que introducen elementos <script> a través de register_html_builder o una plantilla erb↩︎
Vi que la descripción de la configuración content security script src indica que habilitar content_security_policy_strict_dynamic ignorará esta configuración, así que vine aquí para consultar.
Las fuentes de host se ignorarán cuando content_security_policy_strict_dynamic esté habilitado.
La parte importante ahí es “Fuentes de host”. ‘unsafe-inline’ no es una fuente de host, por lo que todavía se admite.
Dicho esto, estoy totalmente de acuerdo en que esto es confuso. Dado el éxito de la implementación de strict-dynamic, planeamos eliminar el sistema antiguo. Una vez que lo hagamos, podremos eliminar automáticamente todas las fuentes de host de la lista, y las cosas serán mucho más sencillas para los administradores.
Este nuevo sistema presumiblemente funciona bien con:
scripts en línea
fuentes de script completas alojadas localmente
Pero, ¿qué pasa con el caso en que se invocaron scripts remotos con “loadScript” y la URL remota completa?
Corrígeme si me equivoco, pero ¿no creo que haya una buena manera de manejar ese caso?
Entonces, ¿eso significa que para esos casos necesitamos depender en cambio de:
mover esa invocación a un script en línea O
descargar la fuente completa como un activo del tema?
Para el primer caso de script en línea, ¿supongo que no hay forma de garantizar que el script se cargue antes de usar elementos de él? (Como podrías hacerlo dentro de un .then después de un loadScript)
strict-dynamic debería funcionar con scripts remotos cargados a través de loadScript. De hecho, esa fue la razón principal del cambio: ya no necesitamos enumerar todas las URL de scripts externos por adelantado. Eso es especialmente bueno para las personas que ejecutan anuncios, que a menudo incorporan una gran cantidad de scripts remotos.
Estaba viendo algunos errores, pero podría no ser por esta razón. Déjame ver si puedo encontrar un ejemplo.
Principalmente me estaba preparando para una actualización estable que sé que involucra loadScript y scripts remotos.
¿Puedes complacerme y explicar cómo los scripts remotos que se invocan aleatoriamente dentro del código con loadScript terminan siendo “autorizados” por la CSP del modo dinámico? ¿Está sucediendo alguna magia?
La expresión de origen 'strict-dynamic' especifica que la confianza dada explícitamente a un script presente en el marcado, al acompañarlo con un nonce o un hash, se propagará a todos los scripts cargados por ese script raíz.
Por lo tanto, siempre que el script original sea confiable (a través de un nonce), el navegador permitirá que cargue cualquier otro script sin restricciones. Y luego, como esos scripts son confiables, ¡pueden cargar más!
Hay una advertencia, y es que los scripts no pueden ser ‘insertados por el analizador’. Esto evita que strict-dynamic sea explotado para ataques XSS.
Por lo tanto, por ejemplo, esto sería ‘insertado por el analizador’ y sería bloqueado:
Pero, construir el elemento script programáticamente no implica el análisis de HTML, es mucho menos probable que sea un vector XSS, y por lo tanto se permite:
No, el nonce solo se incluye en la etiqueta de script original renderizada por Rails (por ejemplo, scripts principales, de complementos o de temas).
Eso significa que el código principal/complemento/tema es confiable y se le permite insertar cualquier otro script. No se requiere nonce aquí: el navegador sabe qué script realizó la inserción y, mágicamente, sabe que se puede confiar en él.
