Problemas comunes de integración front-end Content Security Policy (CSP) parte 2

CSP esta aquí

Hola, bienvenido a otra mini publicación, se trata de CSP, con el concepto de CSP.

Content Security Policy (CSP) - HTTP | MDN

Es una capa de seguridad basada en la mitigación de los ataques XSS y la inyección de datos.

Para activar CSP, debe realizar un ajuste en la configuración de su servidor para agregar este encabezado

Content-Security-Policy

en versiones antiguas de browsers se usaba:

X-Content-Security-Policy
or
X-WebKit-CSP

o lo podemos definir con un meta tag en el head de el html de la siguiente manera:

<meta http-equiv="Content-Security-Policy" content="">

Pero más importante, ¿qué podemos delimitar con un CSP?

Podemos establecer políticas basadas en estas directivas:

• default-src: esta directiva establece una lista de fuentes predeterminada para todas las demás directivas.
• script-src: esta directiva restringe qué scripts puede ejecutar el recurso protegido. La directiva también controla otros recursos, como las hojas de estilo XSLT [XSLT], que pueden hacer que el agente de usuario ejecute un script.
• style-src: esta directiva restringe los estilos que el usuario aplica al recurso protegido.
• img-src: esta directiva restringe desde qué URI el recurso protegido puede cargar imágenes.
• font-src: esta directiva restringe desde qué URI el recurso protegido puede cargar fuentes. Esto se aplica al procesar la regla CSS @ font-face
• connect-src: esta directiva restringe qué URI puede cargar el recurso protegido mediante interfaces de script. Esto se aplica al método open () de un objeto XMLHttpRequest, el constructor WebSocket y el constructor EventSource.
• media-src: esta directiva restringe desde qué URI el recurso protegido puede cargar video y audio. Esto se aplica a los datos de un clip de video o audio, como cuando se procesa el atributo src de un elemento de video, audio, fuente o pista.
• object-src: esta directiva restringe desde qué URI el recurso protegido puede cargar complementos. Esto se aplica al atributo de datos de un elemento de objeto, el atributo src de los elementos incrustados o los atributos de código o archivo de un elemento de subprograma. Los datos de cualquier objeto, incrustación o elemento de subprograma deben coincidir con las fuentes de objeto permitidas para poder ser recuperados.
• frame-src: esta directiva restringe desde dónde el recurso protegido puede incrustar marcos.
• report-uri: este URI debe usar el mismo puerto y protocolo que el recurso protegido y debe recibir una solicitud posterior
  Los valores que podemos establecer para estas directivas son básicamente estos:
• none: denegar todo el acceso
• *: Comodín en todos los accesos
• Self: el URI debe tener el mismo esquema, host y puerto que el URI del recurso protegido
• Data: datos incrustados, como una imagen codificada en base64
• Host: este es el último elemento donde podemos establecer URI aceptables para inyectar contenido y por ejemplo, si queremos establecer una política predeterminada para aceptar recursos de la URL propia y base64 y solo de los datos de https://giorgiosaud.com, podemos establecer la política de esta manera:

Content-Security-Policy: "default-src 'self' data: https://giorgiosaud.com"

en el caso de las directivas script-src y style-src, tenemos valores adicionales para establecer como estos:

• inline: entidades inline html como:

<script>alert(‘Hola ;)’)</script> or
<!-- en caso de estilos --!>
<style>h1{color:red}</style>

y en el caso del script, podemos limitar la ejecución de eval:
con la Directiva Eval

Vamos a complementar el último ejemplo de la política que permite css y js en línea y permitir eval en js, el resultado es:

Content-Security-Policy: "default-src 'self' data: https://giorgiosaud.com; script-src 'unsafe-inline' 'unsafe-eval'; style-src 'unsafe-inline'"

podemos establecer directivas especiales para cualquiera de ellos superponiendo las default-src o establecer solo las directivas deseadas que necesitamos, y eso es todo.

Espero que sepa un poco más sobre CSP, nos vemos más tarde en otra publicación y aquí hay otra publicación interesante sobre CORS y Solicitud de verificación previa

Problemas comunes de integración desde el front end parte 1 (CORS + Solicitud de verificación…