La Política de seguridad de contenido ( CSP ) es un estándar de seguridad informática introducido para evitar 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 confiable . [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] CSP proporciona un método estándar para que los propietarios de sitios web declaren los orígenes aprobados del contenido que los navegadores deben poder cargar en ese sitio web; los tipos cubiertos son JavaScript , CSS , marcos HTML , trabajadores web , fuentes , imágenes y objetos incrustables como Java. subprogramas , ActiveX , archivos de audio y vídeo y otras funciones 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 se publicaron versiones adicionales (Nivel 2) en 2014. A partir de 2023 [actualizar], el borrador del Nivel 3 se está desarrollando y las nuevas características están siendo adoptadas rápidamente por el navegadores web. [6]
Los siguientes nombres de encabezado se utilizan como parte de implementaciones CSP experimentales: [3]
Content-Security-Policy– nombre de encabezado estándar propuesto por el documento W3C. Google Chrome admite esto a partir de la versión 25. [7] Firefox admite esto a partir de la versión 23, [8] lanzada el 6 de agosto de 2013. [9] WebKit admite esto a partir de la versión 528 (compilación nocturna). [10] La compatibilidad con 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 los 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 también encabezados de cumplimiento y de solo informe. El navegador procesará cada encabezado por separado.
CSP también se puede entregar dentro del código HTML utilizando una etiqueta META HTML , aunque en este caso su efectividad será limitada. [14]
Internet Explorer 10 e Internet Explorer 11 también admiten CSP, pero solo con la directiva sandbox, utilizando el X-Content-Security-Policyencabezado experimental. [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, el soporte del marco web solo es necesario si el contenido del 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 entregarse desde niveles de aplicación web superiores a la aplicación, por ejemplo, en un equilibrador 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 las listas permitidas. En enero de 2016, [21] se publicó otro método, que aprovecha la lista permitida de CSP en todo el 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 evitar 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 declarativa de lista permitida. Un objetivo de ejemplo 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 desactivadas de forma predeterminada:
<script>bloques, [b]onclick.)javascript:enlaces<style>Bloque B]styleatribuido a elementos HTMLeval()setTimeoutysetIntervalnew Function()constructorCSSStyleSheet.insertRule()métodoSi bien usar CSP en una nueva aplicación puede ser bastante sencillo, especialmente con un marco 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 fuente externos ( <script src>), analizar JSON en lugar de evaluarlo y usarlo EventTarget.addEventListener()para configurar controladores de eventos. [23]
'unsafe-inline'declaración especial.<script><style>noncehash'unsafe-eval'declaración especial.<html ng-app ng-csp>Cada vez que un recurso solicitado o la ejecución de un script viola la política, el navegador activará 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 ser capturados por la propia API de la aplicación [26] o por receptores públicos de informes CSP. [ cita necesaria ]
En 2018, los investigadores de seguridad demostraron cómo enviar informes de falsos positivos al receptor designado especificado en report-uri. Esto permite a posibles atacantes activar esas alarmas de forma arbitraria y podría hacerlas menos útiles en caso de un ataque real. [27] Este comportamiento es intencionado y no se puede solucionar, ya que el navegador (cliente) envía los informes.
Según el modelo de procesamiento CSP (1.0) original (2012-2013), [28] CSP no debe 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 scripts en sitios web, independientemente del origen de ese script, 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 CSP 1.1 [29] ) con la siguiente redacción. Tenga en cuenta el uso de la palabra "puede" en lugar de la anterior redacción absoluta "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 navegadores utilizaban la redacción absoluta de "debería" para solicitar/exigir el cumplimiento de la política e instalar cambios en los navegadores populares (Firefox, Chrome, Safari) para respaldarla. Esto fue particularmente polémico cuando sitios como Twitter y GitHub comenzaron a utilizar políticas estrictas de CSP, que "rompieron" el uso de Bookmarklets. [30]
El Grupo de Trabajo de Seguridad de Aplicaciones Web del W3C considera que dicho script forma parte de la Trusted Computing Base implementada por el navegador; sin embargo, un representante de Cox Communications ha argumentado ante el grupo de trabajo que esta exención es un agujero de seguridad potencial que podría ser explotado por complementos o extensiones maliciosos o comprometidos. [31] [32]
A partir de 2015, [actualizar]el W3C propone una serie de nuevos estándares de seguridad para navegadores, la mayoría de ellos complementarios a CSP: [33]
La Política de seguridad de contenido tiene como objetivo ayudar a los diseñadores web o administradores de servidores a especificar cómo interactúa el contenido en sus sitios web. Ayuda a mitigar y detectar tipos de ataques como XSS e inyección de datos.
Restricciones de contenido: una forma para que los sitios web le indiquen al navegador que aumente su seguridad en las páginas donde el sitio sabe que el contenido fue enviado por el usuario y, por lo tanto, potencialmente peligroso.