top of page

La Política de seguridad de contenido (CSP)

Foto del escritor: ArtistCodeArtistCode

Actualizado: 10 feb 2023



La Política de seguridad de contenido (CSP), es una capa adicional de seguridad que ayuda en la detección y mitigación de ciertos ataques, incluidos los XSS y los ataques de inyección de datos. Estos ataques son utilizados a menudo en contra de sitios web, tanto para la des configuración del mismo, como también el robo de datos.


Rechazo de ataques XSS

Los CSP fueron diseñados principalmente para rechazar/mitigar los ataques XSS, evitando el robo y la generación de desconfianza en navegadores. Los scripts o malware malicioso que son ejecutados en el navegador de la victima, sucede porque el navegador confía en la fuente de información, incluso si el contenido proviene de un externo al lugar original. CSP hace posible que los administradores reduzcan o eliminen algunos vectores de los XSS, especificando dominios donde sus scripts son considerados fiables.


Mitigación de secuencias de comandos en sitios cruzados


Uno de los principales objetivos de la CSP es mitigar e informar de los ataques XSS. Los ataques XSS explotan la confianza del navegador en el contenido recibido del servidor. Los scripts maliciosos son ejecutados por el navegador de la víctima porque el navegador confía en la fuente del contenido, incluso cuando no viene de donde parece venir. Un navegador compatible con CSP sólo ejecutará los scripts cargados en los archivos fuente recibidos de esos dominios permitidos, ignorando todos los demás scripts (incluidos los scripts en línea y los atributos HTML de gestión de eventos). Como última forma de protección, los sitios que no quieren permitir nunca que se ejecuten los scripts pueden optar por anular globalmente la ejecución de los scripts.

Mitigar los ataques de rastreo de paquetes


Además de restringir los dominios desde los que se puede cargar el contenido, el servidor puede especificar qué protocolos pueden usarse; por ejemplo (e idealmente, desde el punto de vista de la seguridad), un servidor puede especificar que todo el contenido debe cargarse mediante HTTPS. Una estrategia de seguridad de transmisión de datos completa incluye no solo hacer cumplir HTTPS para la transferencia de datos, sino también marcar todas las cookies con el atributo secure y proporcionar redireccionamientos automáticos desde las páginas HTTP a sus contrapartes HTTPS. Los sitios también pueden usar el encabezado HTTP Strict Transport-Security para garantizar que los navegadores se conecten a ellos solo a través de un canal cifrado.


Uso de CSP


La configuración de la Política de seguridad de contenido implica agregar el encabezado HTTP Content Security Policy a una página web y darle valores para controlar qué recursos puede cargar el agente de usuario para esa página. Por ejemplo, una página que carga y muestra imágenes podría permitir imágenes desde cualquier lugar, pero restringir una acción de formulario a un punto final específico. Una política de seguridad de contenido diseñada correctamente ayuda a proteger una página contra un ataque de secuencias de comandos entre sitios.


Escribir una política


Una política se describe mediante una serie de directivas de política, cada una de las cuales describe la política para un determinado tipo de recurso o área de política. Su política debe incluir una directiva de política default-src, que es una alternativa para otros tipos de recursos cuando no tienen políticas propias (para obtener una lista completa, consulte la descripción de la directiva default-src). Una política debe incluir una directiva default-src o script-src para evitar que se ejecuten scripts en línea, así como bloquear el uso de eval() . Una política debe incluir una directiva default-src o style-src para restringir la aplicación de estilos en línea desde un elemento <style> o un style atributo de estilo . Existen directivas específicas para una amplia variedad de tipos de elementos, de modo que cada tipo puede tener su propia política, incluidas fuentes, marcos, imágenes, medios de audio y video, scripts y trabajadores. Para obtener una lista completa de directivas de políticas, consulte la página de referencia del encabezado Content-Security-Policy.


Ejemplos: Casos de uso común


En esta sección se dan ejemplos de algunos escenarios comunes de política de seguridad.


Ejemplo 1


El administrador de un sitio web quiere que todo el contenido provenga del propio origen del sitio (esto excluye los subdominios).

Content-Security-Policy: default-src 'self'


Ejemplo 2


El administrador de un sitio web quiere permitir el contenido de un dominio de confianza y todos sus subdominios (no tiene que ser el mismo dominio en el que está establecido el CSP).

Content-Security-Policy: default-src 'self' example.com *.example.com


Ejemplo 3


El administrador de un sitio web quiere permitir que los usuarios de una aplicación web incluyan imágenes de cualquier origen en su propio contenido, pero restringiendo los medios de audio o vídeo a proveedores de confianza, y todas las secuencias de comandos sólo a un servidor específico que aloje código de confianza.

Content-Security-Policy: default-src 'self'; img-src *; media-src example.org example.net; script-src userscripts.example.com

En este caso, por defecto, el contenido sólo se permite desde el origen del documento, con las siguientes excepciones:

  • Las imágenes pueden cargarse desde cualquier lugar (note el comodín "*").

  • Los medios de comunicación sólo se permiten desde example.org y example.net (y no desde subdominios de esos sitios).

  • El script ejecutable sólo se permite desde userscripts.example.com.


Ejemplo 4


El administrador de un sitio web de banca online quiere asegurarse de que todo su contenido se carga utilizando TLS,para evitar que los atacantes puedan espiar las peticiones. Content-Security-Policy: default-src https://onlinebanking.example.com

El servidor sólo permite el acceso a los documentos que se cargan específicamente sobre HTTPS a través del origen único onlinebanking.example.com.


Ejemplo 5


El administrador de un sitio web de correo electrónico quiere permitir HTML en el correo electrónico, así como imágenes cargadas desde cualquier lugar, pero no JavaScript u otro contenido potencialmente peligroso.

Content-Security-Policy: default-src 'self' *.example.com; img-src *

Tenga en cuenta que este ejemplo no especifica un script-src; con el ejemplo de CSP, este sitio utiliza la configuración especificada por la directiva default-src , lo que significa que los scripts solo se pueden cargar desde el servidor de origen.


Probando su política


Para facilitar el despliegue, CSP puede ser desplegado en el modo de reporte solamente. La política no se aplica, pero cualquier violación se informa a un URI proporcionado. Además, un encabezado de sólo informe puede utilizarse para probar una futura revisión de una política sin desplegarla realmente. Puede usar el encabezado HTTP Content-Security-Policy-Report-Only para especificar su política, así:


Content-Security-Policy-Report-Only: policy

Si tanto un Content-Security-Policy-Report-Only como un encabezado Content-Security-Policy están presentes en la misma respuesta, ambas políticas se cumplen. La política especificada en los Content-Security-Policy se aplica mientras que la Content-Security-Policy-Report-Only genera informes, pero no se aplica.


Habilitar los Reportes


De forma predeterminada, los informes de infracción no se envían. Para habilitar los informes de infracciones, debe especificar la directiva de política report-uri , proporcionando al menos un URI al que entregar los informes:

Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi

A continuación, debe configurar su servidor para que reciba los informes; puede almacenarlos o procesarlos de la manera que usted determine.


Sintaxis del informe de la violación


El informe del objeto JSON contiene los siguientes datos:

blocked-uri

El URI del recurso cuya carga fue bloqueada por la Política de seguridad de contenido. Si el URI bloqueado es de un origen diferente al del document-uri, entonces el URI bloqueado se trunca para contener solo el esquema, el host y el puerto.


disposition

"enforce" Hacer cumplir" o "report" dependiendo de si se utiliza el encabezado Content-Security-Policy-Report-Only o el encabezado Content-Security-Policy.


document-uri


La URI del documento en el que se produjo la violación.


effective-directive

La directiva cuya ejecución causó la violación. Algunos navegadores pueden proporcionar valores diferentes, como Chrome, que proporciona style-src-elem / style-src-attr, incluso cuando la directiva realmente aplicada era style-src.


original-policy

La política original según lo especificado por el encabezado HTTP Content-Security-Policy.


referrer Deprecated Non-standard

El remitente del documento en el que se produjo la violación.


script-sample

Los primeros 40 caracteres de la secuencia de comandos en línea, el controlador de eventos o el estilo que causaron la infracción. Solo se aplica a las violaciones de script-src* y style-src* , cuando contienen el 'report-sample'.


status-code


El código de estado HTTP del recurso en el que se instanció el objeto global.


violated-directive


El nombre de la sección de política que fue violada.


Muestra de informe de violación


Consideremos una página ubicada en http://example.com/signup.html. Utiliza la siguiente política y no permite todo excepto las hojas de estilo de cdn.example.com.

Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports

El HTML de signup.html se ve así:

<!DOCTYPE html>

<html lang="en-US">

<head>

<meta charset="UTF-8" />

<title>Sign Up</title>

<link rel="stylesheet" href="css/style.css" />

</head>

<body> Here be content. </body>

</html> ¿Puedes detectar el error? Las cdn.example.com de estilo solo pueden cargarse desde cdn.example.com, pero el sitio web intenta cargar una desde su propio origen ( http://example.com ). Un navegador capaz de hacer cumplir CSP enviaría el siguiente informe de infracción como una solicitud POST a http://example.com/_/csp-reports, cuando se visita el documento:

{

"csp-report": {

"document-uri":"http://example.com/signup.html",

"referrer": "",

"blocked-uri": "http://example.com/css/style.css",

"violated-directive": "style-src cdn.example.com",

"original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports"

}

}

Como puede ver, el informe incluye la ruta completa al recurso blocked-uri . Este no es siempre el caso. Por ejemplo, si signup.html intenta cargar CSS desde http://anothercdn.example.com/stylesheet.css, el navegador no incluiría la ruta completa, sino solo el origen ( http://anothercdn.example.com ). La especificación CSP da una explicación de este comportamiento extraño. En resumen, esto se hace para evitar la filtración de información confidencial sobre recursos de origen cruzado.


¿Quieres saber más?


558 visualizaciones0 comentarios

Entradas recientes

Ver todo

Comments


bottom of page