Política de seguridad de contenidos

La Política de Seguridad de Contenido ( CSP ) es un estándar de seguridad informática introducido para prevenir ataques de secuencias de comandos entre sitios (XSS), clickjacking y otros ataques de inyección de código resultantes de la ejecución de contenido malicioso en el contexto de una página web de confianza . ^[1] Es una Recomendación Candidata del grupo de trabajo del W3C sobre Seguridad de Aplicaciones Web, ^[2] ampliamente respaldada por los navegadores web modernos . ^[3] La CSP proporciona un método estándar para que los propietarios de sitios web declaren los orígenes aprobados del contenido que los navegadores deberían poder cargar en ese sitio web; los tipos cubiertos son JavaScript , CSS , marcos HTML , trabajadores web , fuentes , imágenes, objetos integrables como subprogramas Java , ActiveX , archivos de audio y video y otras características HTML5 .

El estándar, originalmente llamado Restricciones de contenido, fue propuesto por Robert Hansen en 2004, ^[4] implementado por primera vez en Firefox 4 y rápidamente adoptado por otros navegadores. La versión 1 del estándar se publicó en 2012 como recomendación candidata del W3C ^[5] y rápidamente con versiones posteriores (Nivel 2) publicadas en 2014. A partir de 2023 ^[actualizar], se está desarrollando el borrador del Nivel 3 y las nuevas características están siendo adoptadas rápidamente por los navegadores web. ^[6]

Los siguientes nombres de encabezado se utilizan como parte de implementaciones experimentales de CSP: ^[3]

• Content-Security-Policy– nombre de encabezado estándar propuesto por el documento W3C. Google Chrome lo admite a partir de la versión 25. ^[7] Firefox lo admite a partir de la versión 23, ^[8] publicada el 6 de agosto de 2013. ^[9] WebKit lo admite a partir de la versión 528 (compilación nocturna). ^{[10] La compatibilidad con} Microsoft Edge basada en Chromium es similar a la de Chrome. ^[11]
• X-WebKit-CSP– encabezado experimental obsoleto introducido en Google Chrome , Safari y otros navegadores web basados ​​en WebKit en 2011. ^[12]
• X-Content-Security-Policy– encabezado experimental obsoleto introducido en navegadores basados ​​en Gecko 2 (Firefox 4 a Firefox 22, Thunderbird 3.3, SeaMonkey 2.1). ^[13]

Un sitio web puede declarar varios encabezados CSP, incluso los de cumplimiento y los de solo informes. El navegador procesará cada encabezado por separado.

El CSP también se puede entregar dentro del código HTML utilizando una etiqueta meta , aunque en este caso su efectividad será limitada. ^[14]

Internet Explorer 10 e Internet Explorer 11 también admiten CSP, pero solo la directiva sandbox, utilizando el encabezado experimental X-Content-Security-Policy. ^[15]

Varios marcos de aplicaciones web admiten CSP, por ejemplo AngularJS ^[16] (de forma nativa) y Django (middleware). ^[17] GitHub ha publicado instrucciones para Ruby on Rails . ^[18] Sin embargo, la compatibilidad con marcos web solo es necesaria si el contenido de CSP depende de alguna manera del estado de la aplicación web, como el uso del origen. De lo contrario, el CSP es bastante estático y se puede entregar desde niveles de aplicación web por encima de la aplicación, por ejemplo, en el balanceador de carga o el servidor web .nonce

En diciembre de 2015 ^[19] y diciembre de 2016 ^[20] se publicaron algunos métodos para eludir 'nonce'la inclusión en listas blancas de orígenes. En enero de 2016 ^[21] se publicó otro método que aprovecha la inclusión en listas blancas de CSP en todo el servidor para explotar versiones antiguas y vulnerables de bibliotecas de JavaScript alojadas en el mismo servidor (caso frecuente con servidores CDN). En mayo de 2017 ^[22] se publicó un método más para eludir la inclusión en listas blancas de CSP utilizando el código de los marcos de aplicaciones web.

Si el Content-Security-Policyencabezado está presente en la respuesta del servidor, un cliente que cumple con las normas aplica la política de lista blanca declarativa. Un ejemplo de objetivo de una política es un modo de ejecución más estricto para JavaScript con el fin de evitar ciertos ataques de secuencias de comandos entre sitios. En la práctica, esto significa que una serie de funciones están deshabilitadas de forma predeterminada:

• Código JavaScript en línea ^[a]
  • <script>bloques, ^[b]
  • Controladores de eventos DOM como atributos HTML (por ejemplo, onclick)
  • Los javascript:enlaces
• Sentencias CSS en línea
  • <style>bloque ^[b]
  • styleatribuido a elementos HTML
• Evaluación dinámica de código JavaScript ^[c]
  • eval()
  • argumentos de cadena para funciones setTimeoutysetInterval
  • new Function()constructor
• Sentencias CSS dinámicas
  • CSSStyleSheet.insertRule()método

Si bien el uso de CSP en una nueva aplicación puede ser bastante sencillo, especialmente con un marco de JavaScript compatible con CSP , ^[d] las aplicaciones existentes pueden requerir cierta refactorización o flexibilización de la política. La práctica de codificación recomendada para aplicaciones web compatibles con CSP es cargar código desde archivos de origen externos ( <script src>), analizar JSON en lugar de evaluarlo y usarlo EventTarget.addEventListener()para configurar controladores de eventos. ^[23]

Cada vez que un recurso solicitado o la ejecución de un script viola la política, el navegador enviará una POSTsolicitud al valor especificado en report-uri^[24] o report-to^[25] que contiene detalles de la violación.

Los informes CSP son estructuras JSON estándar y pueden capturarse mediante la propia API de la aplicación ^[26] o mediante receptores de informes CSP públicos. ^{[ cita requerida ]}

En 2018, los investigadores de seguridad demostraron cómo enviar informes de falsos positivos al receptor designado especificado en report-uri. Esto permite a los atacantes potenciales activar arbitrariamente esas alarmas y podría hacerlas menos útiles en caso de un ataque real. ^[27] Este comportamiento es intencional y no se puede corregir, ya que el navegador (cliente) es el que envía los informes.

Según el modelo de procesamiento original de CSP (1.0) (2012-2013), ^[28] CSP no debería interferir con el funcionamiento de los complementos o extensiones del navegador instalados por el usuario. Esta característica de CSP habría permitido efectivamente que cualquier complemento, extensión o Bookmarklet inyectara secuencias de comandos en sitios web, independientemente del origen de dichas secuencias de comandos, y por lo tanto estaría exento de las políticas de CSP.

Sin embargo, esta política ha sido modificada desde entonces (a partir de la versión 1.1 de la CSP ^[29] ) con la siguiente redacción. Obsérvese el uso de la palabra "puede" en lugar de la expresión absoluta anterior "debería (no)":

Nota: Los agentes de usuario pueden permitir a los usuarios modificar o eludir la aplicación de políticas a través de preferencias de usuario, marcadores, adiciones de terceros al agente de usuario y otros mecanismos similares.

Los usuarios de los navegadores utilizaban la expresión "debería" para solicitar/exigir el cumplimiento de la política y la instalación de cambios en los navegadores más populares (Firefox, Chrome, Safari) para respaldarla. Esto fue particularmente polémico cuando sitios como Twitter y GitHub comenzaron a utilizar políticas CSP estrictas que "rompieron" el uso de Bookmarklets. ^[30]

El Grupo de Trabajo de Seguridad de Aplicaciones Web del W3C considera que dicho script es parte de la Base de Computación Confiable implementada por el navegador; sin embargo, un representante de Cox Communications argumentó ante el grupo de trabajo que esta exención es un potencial agujero de seguridad que podría ser explotado por complementos o extensiones maliciosos o comprometidos. ^{[31] [32]}

A partir de 2015, ^[actualizar]el W3C ha propuesto una serie de nuevos estándares de seguridad de navegadores, la mayoría de ellos complementarios a CSP: ^[33]

• Integridad de subrecursos ( SRI ), para garantizar que solo se carguen archivos de recursos conocidos y confiables (normalmente JavaScript , CSS ) desde servidores de terceros (normalmente CDN )
• Contenido mixto , para aclarar la política del navegador previsto sobre páginas cargadas a través de HTTPS y contenido vinculado a través de HTTP de texto sin formato
• Actualización de solicitudes inseguras , que indica a los navegadores cómo manejar los enlaces heredados en las páginas migradas a HTTPS
• Gestión de credenciales , una API de JavaScript unificada para acceder a las credenciales del usuario y facilitar esquemas de inicio de sesión complejos.
• Política de referencia , extensión CSP para avisar al navegador sobre la generación de los encabezados de referencia . ^[33]

• Política del mismo origen
• NoScript – protección anti-XSS y Application Boundaries Enforcer (ABE), extensión para Firefox ^{[34] [35]}
• HTTP Switchboard : reglas CSP definidas por el usuario, extensión para Google Chrome ^[36] y Opera ^[37]
• Seguridad de transporte estricta HTTP
• Fijación de clave pública HTTP

• Borrador de trabajo del W3C sobre la política de seguridad de contenidos
• Directrices de codificación segura para la política de seguridad de contenidos
• Política de seguridad de contenido (CSP) en MDN Web Docs