Política de seguridad de contenido

La Política de Seguridad de Contenido ( CSP ) es un estándar de seguridad informática introducido para prevenir el cross-site scripting (XSS), el clickjacking y otros ataques de inyección de código que resultan 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 orígenes aprobados del contenido que los navegadores deben tener permitido cargar en ese sitio web; los tipos cubiertos son JavaScript , CSS , marcos HTML , web workers , fuentes , imágenes, objetos incrustables como applets de Java , ActiveX , archivos de audio y video, y otras características de HTML5 .

El estándar, originalmente llamado Restricciones de Contenido, fue propuesto por Robert Hansen en 2004, ^{[ 4 ]} se implementó por primera vez en Firefox 4 y fue 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 se publicaron versiones posteriores (Nivel 2) en 2014. A partir de 2023, el borrador del Nivel 3 se encuentra en desarrollo y las nuevas características están siendo rápidamente adoptadas 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 del W3C. Google Chrome lo admite desde la versión 25. ^{[ 7 ]} Firefox lo admite desde la versión 23, ^{[ 8 ]} publicada el 6 de agosto de 2013. ^{[ 9 ]} WebKit lo admite desde la versión 528 (compilación nocturna). ^{[ 10 ]} La compatibilidad de Microsoft Edge basado 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 múltiples encabezados CSP, combinando aquellos que aplican políticas de privacidad con los que solo informan sobre ellas. Cada encabezado será procesado por separado por el navegador.

La CSP también se puede entregar dentro del código HTML usando 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 X-Content-Security-Policyencabezado experimental. ^{[ 15 ]}

Varios frameworks 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 frameworks 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 puede ser entregado desde capas de la aplicación web superiores a la aplicación, por ejemplo, en un balanceador de carga o un servidor web . nonce

En diciembre de 2015 ^{[ 19 ]} y diciembre de 2016, ^{[ 20 ]}'nonce' se publicaron algunos métodos para eludir los orígenes de la lista de permitidos. En enero de 2016, ^{[ 21 ]} se publicó otro método que aprovecha la lista de permitidos de CSP a nivel de servidor para explotar versiones antiguas y vulnerables de bibliotecas 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 CSP utilizando código de marcos de aplicaciones web.

Si el Content-Security-Policyencabezado está presente en la respuesta del servidor, un cliente compatible aplica la política de lista de permitidos declarativa. Un ejemplo del objetivo de una política es un modo de ejecución más estricto para JavaScript con el fin de prevenir ciertos ataques de secuencias de comandos entre sitios (XSS). En la práctica, esto significa que varias 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
• Declaraciones CSS en línea
  • <style>bloque ^{[ b ]}
  • styleatribuidos a elementos HTML
• Evaluación dinámica de código JavaScript ^{[ c ]}
  • eval()
  • argumentos de cadena para funciones setTimeoutysetInterval
  • new Function()constructor
• Declaraciones CSS dinámicas
  • CSSStyleSheet.insertRule()método

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

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

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

En 2018, 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 quien 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 recomendado permitir que cualquier complemento, extensión o bookmarklet inyectara scripts en sitios web, independientemente del origen de dichos scripts, y por lo tanto quedara exento de las políticas de CSP.

Sin embargo, esta política ha sido modificada desde entonces (a partir de CSP 1.1) ^{[ 29 ]} con la siguiente redacción. Nótese el uso de la palabra "puede" en lugar de la recomendación anterior "debería":

Nota: Los agentes de usuario pueden permitir a los usuarios modificar o eludir la aplicación de las políticas mediante preferencias de usuario, marcadores, complementos de terceros para el agente de usuario y otros mecanismos similares.

La recomendación "debería" estaba siendo utilizada por los usuarios de navegadores para solicitar 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, lo que "rompió" el uso de Bookmarklets. ^{[ 30 ]}

El Grupo de Trabajo de Seguridad de Aplicaciones Web del W3C considera que dicho script forma 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 constituye una posible vulnerabilidad de seguridad que podría ser explotada por complementos o extensiones maliciosos o comprometidos. ^{[ 31 ] [ 32 ]}

A partir de 2015 , el W3C está proponiendo una serie de nuevos estándares de seguridad para 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 enlaces a contenido a través de HTTP sin formato.
• Actualizar las solicitudes inseguras , indicando a los navegadores cómo manejar los enlaces heredados en las páginas migradas a HTTPS.
• Gestión de credenciales , una API JavaScript unificada para acceder a las credenciales del usuario y facilitar esquemas de inicio de sesión complejos.
• Referrer Policy , extensión CSP para indicar al navegador la generación de los encabezados Referer . ^{[ 33 ]}

• Política de 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 contenido
• Política de seguridad de contenido (CSP) en MDN Web Docs